From isms-bounces@ietf.org Mon Nov 3 16:45:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B42728C497; Mon, 3 Nov 2008 16:45:06 -0800 (PST) X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D551628C415; Mon, 3 Nov 2008 16:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081104004501.D551628C415@core3.amsl.com> Date: Mon, 3 Nov 2008 16:45:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-13.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: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Transport Model for SNMP Author(s) : D. Harrington, et al. Filename : draft-ietf-isms-secshell-13.txt Pages : 44 Date : 2008-11-03 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-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03164449.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@ietf.org Mon Nov 3 17:07:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EA228C4DB; Mon, 3 Nov 2008 17:07:15 -0800 (PST) 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 4CDE328C4DB for ; Mon, 3 Nov 2008 17:07:14 -0800 (PST) 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=[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 7wVqjAvxMXGg for ; Mon, 3 Nov 2008 17:07:13 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 1B26428C479 for ; Mon, 3 Nov 2008 17:07:13 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA01.westchester.pa.mail.comcast.net with comcast id ajXm1a00j0cZkys51p7BAm; Tue, 04 Nov 2008 01:07:11 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id ap791a0034HwxpC3Wp79q5; Tue, 04 Nov 2008 01:07:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=XxWqqn07OZwA:10 a=NkQHSlNpAIcA:10 a=48vgC7mUAAAA:8 a=jkGS2QTF7-AetAzyrsoA:9 a=tzMgp3OPgtYqdH6-_FMA:7 a=_lephyQ3IBlEktZtNoWNeAs8THYA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=AS2qOMRp86rjtdQmkNcA:9 a=6FcIhOzNwPoFESOCtoIryYtJWowA:4 a=6bqG61NMjcsA:10 a=szx7-YYUsi9d2_irBZEA:9 a=7F9QkGe2kHsZBMWqEQEEwUXg1HYA:4 a=61tZBHfzjhcA:10 From: "David Harrington" To: Date: Mon, 3 Nov 2008 20:07:09 -0500 Message-ID: <064901c93e19$a9779220$0500a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_064A_01C93DEF.C0A18A20" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ack+FpXJqVdz11MXQoS3B10DxkkWNAAAT38g Subject: [Isms] FW: I-D Action:draft-ietf-isms-secshell-13.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: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_064A_01C93DEF.C0A18A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This update represents almost all the issues discussed since -10-, and almost all the comments we received since -11- and -12-. Dave Shield, we didn't get all your latest comments in; we were too busy getting all your comments from August addressed, and the dealine loomed. ;-) I did not update the Open Issues section. The Change Log is incomplete. There are still a few issues that don't feel quite closed. I think the "Open issues" are still open, but less so than before these updates. And I have a few stockpiled emails that may no longer be relevant, but I wasn't quite satisfied had been fully addressed by WG consensus. I strongly ask everybody to review all three documents to see that anything you thought was supposed to be addressed was. And of course, we remain open to suggestions for improvements. Juergen wants a WGLC on all three docs, so please read all three thorughly rather than just looking ta diffs. We need to be sure these specs have no major gaffs. Thanks, dbh and wes and joe -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, November 03, 2008 7:45 PM To: i-d-announce@ietf.org Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-13.txt 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-13.txt Pages : 44 Date : 2008-11-03 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-13.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_000_064A_01C93DEF.C0A18A20 Content-Type: Message/External-body; name="draft-ietf-isms-secshell-13.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-isms-secshell-13.txt" Content-Type: text/plain Content-ID: <2008-11-03164449.I-D@ietf.org> ------=_NextPart_000_064A_01C93DEF.C0A18A20 Content-Type: text/plain; name="ATT01538.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01538.txt" _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_064A_01C93DEF.C0A18A20 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_064A_01C93DEF.C0A18A20-- From isms-bounces@ietf.org Tue Nov 4 00:13:31 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E3B3A695D; Tue, 4 Nov 2008 00:13:31 -0800 (PST) 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 711C73A6931 for ; Tue, 4 Nov 2008 00:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 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 dELM4nQNCt-R for ; Tue, 4 Nov 2008 00:13:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A4EEA3A684A for ; Tue, 4 Nov 2008 00:13:28 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 545B4C0033 for ; Tue, 4 Nov 2008 09:13:26 +0100 (CET) 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 PgqP9Hs5M2Rd; Tue, 4 Nov 2008 09:13:21 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B83AC0055; Tue, 4 Nov 2008 09:13:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AF1D98424C2; Tue, 4 Nov 2008 09:13:20 +0100 (CET) Date: Tue, 4 Nov 2008 09:13:20 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20081104081320.GA26802@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Isms] wg last call on isms document set X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This message starts the working group last call on the ISMS documents: [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) [2] Transport Security Model for SNMP [3] Secure Shell Transport Model for SNMP [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models The authors and the chair think that these documents are mature enough for last call. Since the next IETF meeting is coming up, the last call period is not two weeks as usual, but extends until the the end of the IETF week. However, I like to encourage people to review these documents before the ISMS meeting in Minneapolis (currently scheduled for Monday November 17) so that the WG meeting time can be used to resolve any issues that might come up during document review. Please do review the documents and post your comments on this list until November 23, 2008. Please also post to the list if you have read the documents and you are fine with them. It is very useful to know how many people have read the documents. /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 isms-bounces@ietf.org Tue Nov 4 00:20:21 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D033A6985; Tue, 4 Nov 2008 00:20:21 -0800 (PST) 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 1B29D3A6985 for ; Tue, 4 Nov 2008 00:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 Kwfl7j5yKHH4 for ; Tue, 4 Nov 2008 00:20:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 132783A684A for ; Tue, 4 Nov 2008 00:20:20 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DED0CC0058 for ; Tue, 4 Nov 2008 09:20:17 +0100 (CET) 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 yZcYc23i90VR; Tue, 4 Nov 2008 09:20:12 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A2F1C0055; Tue, 4 Nov 2008 09:20:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D0851842503; Tue, 4 Nov 2008 09:20:11 +0100 (CET) Date: Tue, 4 Nov 2008 09:20:11 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20081104082011.GB26802@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Isms] isms meeting agenda X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the proposed ISMS WG meeting agenda for Minneapolis. Since I won't be able to attend the Minneapolis meeting in person, I asked Bert Wijnen to chair the meeting and to take care of the meeting logistics. I will join via jabber and listen to the audio channel. I originally requested a one hour slot and we have meanwhile scheduled in a two hour slot. Since agenda changes might still happen, I continue to plan for a one hour meeting. The main purpose of the meeting is to resolve non-editorial WG last call comments. At the end, we might have some time to discuss some individual submissions related to our chartered work items - but note that work on our chartered work items has priority. If you like to request changes to the meeting agenda, please contact me quickly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-agenda.txt" ============================================================= Integrated Security Model for SNMP WG (isms) IETF #73, Minneapolis MONDAY, November 17, 2008, 1300-1500, Room Salon E ============================================================= WG CHAIR: Juergen Schoenwaelder MEETING CHAIR: Bert Wijnen AGENDA: 1) Agenda bashing, WG status ( 5 min) (Bert Wijnen) 2) Last call comment resolution (40 min) (David Harrington, David Nelson) - Transport Subsystem for SNMP [1] - Transport Security Model for SNMP [2] - Secure Shell Transport Model for SNMP [3] - RADIUS Usage for SNMP SSH Security Model [4] 3) Discussion of related drafts (10 min) (Wes Hardaker?, Chunxiu Li?) 6) Wrap up ( 5 min) (Bert Wijnen) - review of action points WG INTERNET DRAFTS: [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) [2] Transport Security Model for SNMP [3] Secure Shell Transport Model for SNMP [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models RELATED INTERNET DRAFTS: [5] Datagram Transport Layer Security Transport Model for SNMP [6] Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP) --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --X1bOJ3K7DJ5YkBrT-- From isms-bounces@ietf.org Tue Nov 4 06:55:16 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7313A68AC; Tue, 4 Nov 2008 06:55:16 -0800 (PST) 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 C8EE33A68AC for ; Tue, 4 Nov 2008 06:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 yFqLoGOURZ+7 for ; Tue, 4 Nov 2008 06:55:13 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D31943A67AA for ; Tue, 4 Nov 2008 06:55:12 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2D01A399B3E for ; Tue, 4 Nov 2008 06:55:10 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Tue, 04 Nov 2008 06:55:10 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] New DTLS draft posted as well 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org FYI, this is not a working group document at the moment, but I did post an updated version of the DTLS draft. The SSH and DTLS drafts are fairly closely aligned in structure and many of the changes that went into the SSH draft ended up affecting the DTLS draft too. A new version of I-D, draft-hardaker-isms-dtls-tm-01.txt has been successfuly submitted by Wesley Hardaker and posted to the IETF repository. Filename: draft-hardaker-isms-dtls-tm Revision: 01 Title: Datagram Transport Layer Security Transport Model for SNMP Creation_date: 2008-11-03 WG ID: Independent Submission Number_of_pages: 56 Abstract: This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides authentication and privacy services for SNMP applications. This document describes how the DTLS Transport Model (DTLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators, operate in environments where a connectionless (UDP) transport is preferred, and integrates well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for monitoring and managing the DTLS Transport Model for SNMP. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 4 09:53:31 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97E13A6BBE; Tue, 4 Nov 2008 09:53:31 -0800 (PST) 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 C26C93A6BBE for ; Tue, 4 Nov 2008 09:53:30 -0800 (PST) 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 Xyed9AdzLCnG for ; Tue, 4 Nov 2008 09:53:25 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id F40713A6A07 for ; Tue, 4 Nov 2008 09:53:24 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so3221868rvf.49 for ; Tue, 04 Nov 2008 09:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=SDosUs3ul3V0n91eL0kG2agvOsxyVXsguiawSmdxZ5M=; b=P8v95moxI3SGon4R3BMr9Lm9OorHPpHGK5mhuz0LZQ3RaYFIUJt+QuaA7zKefne893 Ao2ihFGu8y/vkk/xInKCvbHhBjhC6gYQylpDEl9f43PhdNybQDFwL1fZGQuG9qs40y4m PUEUpmakPRynsHG1+np87nX4VGY5VZAXGQe0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=cYfqEoT5VfWeYxjPphdzkyfdcgrmcrwajofjPw5kp6Ru7h5+F5vj4cEMWUOtLHBRdx RBZ+CkqPxqvGeQXCq7y5rpQLhG87Ja9mJJd9LqVka+veFhKuY1aLp546BgDA2SqdVp06 //sZTv4bEDzxBiZjEPPwPhHYgUL0O8Bd6TT8M= Received: by 10.141.161.6 with SMTP id n6mr1038861rvo.155.1225821202612; Tue, 04 Nov 2008 09:53:22 -0800 (PST) Received: by 10.141.42.9 with HTTP; Tue, 4 Nov 2008 09:53:22 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2008 17:53:22 +0000 From: "Dave Shield" To: isms@ietf.org In-Reply-To: <20081104081320.GA26802@elstar.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9165_32700674.1225821202600" References: <20081104081320.GA26802@elstar.local> X-Google-Sender-Auth: 93ba6b3ad1eeb4db Subject: Re: [Isms] wg last call on isms document set 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: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ------=_Part_9165_32700674.1225821202600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/11/4 Juergen Schoenwaelder : > This message starts the working group last call on the ISMS documents... > Please do review the documents and post your comments on this list > until November 23, 2008. How did you guess this was coming? :-) Please find attached my comments on these last set of documents. I've tried to take them as they stand, "reading afresh" without referring back to my previous comments and suggestions. By Shield standards, these comments are not much more than low-level mutterings, though there are a handful of open questions that don't feel to have been resolved as yet. Dave ------=_Part_9165_32700674.1225821202600 Content-Type: text/plain; name=ISMS-lastcall-comments.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fn4u8yuz0 Content-Disposition: attachment; filename=ISMS-lastcall-comments.txt VHlwb2dyYXBoaWNhbAotLS0tLS0tLS0tLS0tCgpUTVNNOgogIDMuMi4yLjEsIHBhcmEgMSAgIGZp bmFsIHNlbnRlbmNlIGVuZHMgd2l0aCBhIGNvbW1hLgogICAgICAgICAgICAgICAgICAgIHMvInBy aW5jaXBhbCIsLyJwcmluY2lwYWwiLi8KICA2LCBwYXJhIDUgICAgICAgICBJbnNlcnQgc3BhY2Ug YmV0d2VlbiBudW1iZXIgJiB0ZXh0CiAgICAgICAgICAgICAgICAgICAgcy8gMilBbiAvIDIpIEFu IC8KICA2LjIuMiwgZ2VuZXJhdGV7UmVxdWVzdCxSZXNwb25zZX1NZXNzYWdlCiAgICAgICAgICAg ICAgICAgICAgdW5iYWxhbmNlZCBwYXJlbnRoZXNlcwogICAgICAgICAgICAgICAgICAgIChPbmUg b3BlbmluZywgdHdvIGNsb3NpbmcpCiAgNi4yLjIsIGdlbmVyYXRlUmVzcG9uc2VNZXNzYWdlCiAg ICAgICAgICAgICAgICAgICAgbWVzc2FnZVByb2Nlc3NpbmdNb2RlbCBjb21tZW50CiAgICAgICAg ICAgICAgICAgICAgbm8gbmVlZCB0byBzcGxpdCBvdmVyIHR3byBsaW5lcwogCiAgcy9nZW5lcmF0 ZVJlcXVlc3RNZXNzYWdlL2dlbmVyYXRlUmVxdWVzdE1zZy8KICBzL2dlbmVyYXRlUmVzcG9uc2VN ZXNzYWdlL2dlbmVyYXRlUmVzcG9uc2VNc2cvCiAgcy9nZW5lcmF0ZU91dGdvaW5nTWVzc2FnZS9w cmVwYXJlT3V0Z29pbmdNZXNzYWdlLwogCgpUU006CiAgNS4yLCBzdGVwIDMpICAgICAgcy8gYW5k IGFuIGVycm9yLywgYW4gZXJyb3IvCiAgICAgICAgICAgICAgICAgICAgKGZvciBjb25zaXN0ZW5j eSB3aXRoIG90aGVyIHN0ZXBzKQogIEFwcGVuZGl4IEEsIHNubXBUYXJnZXRBZGRyVGFibGUKICAg ICAgICAgICAgICAgICAgICBhZGQgJyonIHRvIHNubXBUYXJnZXRBZGRyVEFkZHJlc3MKICBBcHBl bmRpeCBBLjEsIGdlbmVyYXRlUmVxdWVzdE1zZwogICAgICAgICAgICAgICAgICAgIGFkZCAnKicg dG8gc25tcFRhcmdldEFkZHJUQWRkcmVzcwoKClNTSFRNOgogIDMuMS4xIDIpLCBwYXJhIDIgIHMv IChbUkZDNDI1M10pIC8gW1JGQzQyNTNdIC8KICAgICAgICAgICAgcGFyYSAzICBzLyAoW1JGQzQy NTJdKSAvIFtSRkM0MjUyXSAvCiAgICAgICAgICAgICAgICAgICAgKGZvciBjb25zaXN0ZW5jeSB3 aXRoIG90aGVyIHNlY3Rpb25zKQogIDUsIHBhcmEgMyAgICAgICAgIHMvT0lEIGFuZCB2YWx1ZSBj b250ZXh0RW5naW5lLwogICAgICAgICAgICAgICAgICAgICAgT0lEIGFuZCB2YWx1ZSwgY29udGV4 dEVuZ2luZS8KICA1LjEgIDIpICAgICAgICAgICBzL3RtU2VjdXJpdHlMZXZlbC90bVRyYW5zcG9y dFNlY3VyaXR5TGV2ZWwvCiAgNS4yICAxKSAgICAgICAgICAgcy90bVRyYW5zcG9ydERvbWFpbiB0 bVRyYW5zcG9ydEFkZHJlc3MvCiAgICAgICAgICAgICAgICAgICAgICB0bVRyYW5zcG9ydERvbWFp biwgdG1UcmFuc3BvcnRBZGRyZXNzLwogIDUuMyAgMSksIHBhcmEgMSAgIHMvdG1TZWN1cnRpdHlO YW1lL3RtU2VjdXJpdHlOYW1lLwogIDUuMyAgMikgICAgICAgICAgIHMvYXV0aGVudGljYXRpb25z IHNlcnZpY2UvYXV0aGVudGljYXRpb24gc2VydmljZS8KICA1LjMgIDUpICAgICAgICAgICBzL3Nz aHRtU2Vzc2lvblVuYXZhbGlhYmxlU3Vic3lzdGVtcy8KICAgICAgICAgICAgICAgICAgICAgIHNz aHRtU2Vzc2lvblVuYXZhaWxhYmxlU3Vic3lzdGVtcy8KICA1LjMgIDYpICAgICAgICAgICBzLzYu ICAvICAgIC8KICAgICAgICAgICAgICAgICAgICBzL3RoaXMgZG9jdW1lbnQvdGhlIHBhcmFncmFw aCBhYm92ZS8KICAgICAgICAgICAgICAgICAgICAgIFsgTm90ZSB0aGF0IHRoZSByZWYgdG8gUkZD MTk5NCBpbiAxMi4yIG1lbnRpb25zCiAgICAgICAgICAgICAgICAgICAgICAgICdQUFAnLCBhbmQg eW91IGRvbid0IHdhbnQgdGhpcyB0b3VjaGVkISAgXQogIDUuMyAgNykgICAgICAgICAgIHMvNy4g IC82LiAgLwoKCkNvbnRlbnQgICAobWlub3IpCi0tLS0tLS0KClRNU006CiAgMy4yLjEsIHBhcmEg NCAgICAgVGhpcyBwYXJhZ3JhcGggaW1wbGllcyBhIG1hbmRhdG9yeSBUcmFuc3BvcnQgTW9kZWwu CiAgICAgICAgICAgICAgICAgICAgV291bGQgdGhpcyBiZSBTTk1QLW92ZXItVURQIChhcyBwZXIg UkZDMzQxNyksIG9yIFNOTVAtb3Zlci1TU0g/CiAgICAgICAgICAgICAgICAgICAgSXQgd291bGQg YmUgc2Vuc2libGUgdG8gZXhwbGljaXRseSBjbGFyaWZ5IHRoaXMgaGVyZS4KCiAgMy4zLjQsIHBh cmEgNSAgICAgSXQgbWlnaHQgYmUgc2Vuc2libGUgdG8gZW1waGFzaXNlIHRoYXQgYSBUcmFuc3Bv cnQgTW9kZWwKICAgICAgICAgICAgICAgICAgICBNVVNUIE5PVCBkb3duZ3JhZGUgdGhlIHJlcXVl c3RlZCBzZWN1cml0eSBsZXZlbCwKICAgICAgICAgICAgICAgICAgICBhbmQgc2hvdWxkIGRpc2Nh cmQgYW55IG1lc3NhZ2Ugd2hlcmUgdGhpcyB3b3VsZCBvY2N1ci4KCgpUU006CiAgMy4zLjEsIHBh cmEgMiAgICAgVGhpcyBwYXJhZ3JhcGggcmVmZXJzIHRvIHRtU3RhdGVSZWZlcmVuY2UsIHJhdGhl ciB0aGFuCiAgICAgICAgICAgICAgICAgICAgc2VjdXJpdHlTdGF0ZVJlZmVyZW5jZS4gIEl0IG1p Z2h0IGJlIHNlbnNpYmxlIHRvIG1vdmUKICAgICAgICAgICAgICAgICAgICB0aGlzIHBhcmFncmFw aCBpbnRvIDMuMy4yIGluc3RlYWQuCgogIDQuMiAgMiksIHBhcmEgMSAgIHMvbm8gc2VjdXJpdHlT dGF0ZVJlZmVyZW5jZS8KICAgICAgICAgICAgICAgICAgICAgIG5vIHNlY3VyaXR5U3RhdGVSZWZl cmVuY2UgKFJlcXVlc3QgbWVzc2FnZSkvCgogIDUuMiAgMykgICAgICAgICAgIFRoZSBpc29sYXRl ZCBzdWItbnVtYmVyaW5nICdhLicgbG9va3MgdmVyeSBzdHJhbmdlOgoKICAgIDxwcm9wb3NhbD4K ICAgICAgMykgIElmIHRoZSBzbm1wVHNtQ29uZmlndXJhdGlvblVzZVByZWZpeCBvYmplY3QgaXMg c2V0IHRvIGZhbHNlLAogICAgICAgICAgdGhlbiBjb3B5IHRoZSB0bVNlY3VyaXR5TmFtZSB0byBz ZWN1cml0eU5hbWUuCiAgICAKICAgICAgICAgIElmIHRoZSBzbm1wVHNtQ29uZmlndXJhdGlvblVz ZVByZWZpeCBvYmplY3QgaXMgc2V0IHRvIHRydWUsCiAgICAgICAgICB0aGVuIHVzZSB0aGUgdHJh bnNwb3J0RG9tYWluIHRvIGxvb2sgdXAgdGhlIGNvcnJlc3BvbmRpbmcgcHJlZml4LgogICAgICAg ICAgSWYgdGhlIHByZWZpeCBsb29rdXAgZmFpbHMgZm9yIGFueSByZWFzb24sIC4uLi4KICAgICAg ICAgICAgICAgICBbd2l0aCB0aGUgcmVzdCBvZiB0aGUgdGV4dCBhcyBjdXJyZW50bHldCiAgICA8 L3Byb3Bvc2FsPgogICAKICBBcHAgQiwgbGFzdCBwYXJhICBzL2h1bWFuLWZyaWVuZGx5IGlkZW50 aWZpZXIvCiAgICAgICAgICAgICAgICAgICAgICBodW1hbi1mcmllbmRseSBpZGVudGlmaWVyICh0 bVNlY3VyaXR5TmFtZSkvCgoKU1NIVE06CgogIDMuMS4yLCBwYXJhIDMgICAgIHMvVGhlIHRyYW5z cG9ydCBsYXllciBhbGdvcml0aG1zIHVzZWQgdG8gcHJvdmlkZQogICAgICAgICAgICAgICAgICAg ICAgYXV0aGVudGljYXRpb24sIGRhdGEgaW50ZWdyaXR5IGFuZCBlbmNyeXB0aW9uIFNIT1VMRAog ICAgICAgICAgICAgICAgICAgICAgTk9UIGJlIGV4cG9zZWQgdG8gdGhlIFNTSCBUcmFuc3BvcnQg TW9kZWwgbGF5ZXIuLy8KICAgICAgICAgICAgICAgICAgICBbVGhpcyBzaW1wbHkgcmVwZWF0cyB0 aGUgc2Vjb25kIHNlbnRlbmNlIG9mIHBhcmEgMl0KCiAgNC4zLjIgICAgICAgICAgICAgcy90bVNl c3Npb25JRCBtdXN0IGJlIHJlZnJlc2hlZC8KICAgICAgICAgICAgICAgICAgICAgIHRtU2Vzc2lv bklEIE1VU1QgYmUgcmVmcmVzaGVkLyAgICA/PwoKICA2ICBTbm1wU1NIQWRkcmVzcywgcGFyYSAy CiAgICAgICAgICAgICAgICAgICAgcy9jb21lcyB0aGUgaG9zdG5hbWUvCiAgICAgICAgICAgICAg ICAgICAgICBjb21lcyB0aGUgaG9zdG5hbWUgb3IgSVAgYWRkcmVzcy8KCgpPcGVuIFF1ZXN0aW9u cy9Jc3N1ZXMKLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpUU006CiAgNC4yICAyKSwgcGFyYSA0ICAg U2hvdWxkIHRoZSBsZW5ndGggb2YgdGhlIHByZWZpeCAoMS00KSBiZSBjaGVja2VkIGhlcmU/CiAg ICAgICAgICAgICAgICAgICAgKGMuZi4gNS4yLCBzdGVwIDMpLCBwYXJhIDMpCgoKU1NIVE06CiAg My4xLjQsIHBhcmEgMgogIDEwICAgNSkgICAgICAgICAgIFRoZXNlIHNlY3Rpb25zIHJlZmVyIHRv IGEgc3Vic3lzdGVtICJzbm1wIgogIDUuMyAgNSkgICAgICAgICAgIFRoaXMgIHNlY3Rpb24gcmVm ZXJzIHRvIGEgc3Vic3lzdGVtICJTTk1QIgogICAgICAgICAgICAgICAgICAgIFNTSCBzdWJzeXN0 ZW0gbmFtZXMgYXBwZWFyIHRvIGJlIGNhc2Utc2Vuc2l0aXZlCiAgICAgICAgICAgICAgICAgICAg ICAoU2VlIFJGQyA0MjUwLCBzZWN0aW9uIDQuNi4xLCBwYXJhIDEpCgogIDMuMS40LCBwYXJhIDIg ICAgICJTU0ggc3Vic3lzdGVtcyIgaW1wbGllcyB0aGF0IGEgKHNpbmdsZSkgb3V0Z29pbmcKICAg ICAgICAgICAgICAgICAgICBtZXNzYWdlIG1heSBvcGVuIChtdWx0aXBsZSkgInNubXAiIHN1YnN5 c3RlbXMuCiAgICAgICAgICAgICAgICAgICAgU3VyZWx5IGEgc2luZ2xlIG1lc3NhZ2Ugd2lsbCBv bmx5IHVzZSBvbmUgc3Vic3lzdGVtPwoKICA1LjIgIDMpICYgNCkgICAgICBXaGF0IHNob3VsZCBo YXBwZW4gaWYgdG1TYW1lU2VjdXJpdHkgaXMgc2V0LAogICAgICAgICAgICAgICAgICAgIGJ1dCB0 aGVyZSBpcyBubyBMQ0QgZW50cnk/CgogIDYgIHNubXB0bVNlc3Npb24gIFRoZSBkZXNjcmlwdGlv bnMgb2YgdGhlc2Ugc3RhdGlzdGljcyBvYmplY3RzCiAgICAgICAgICAgICAgICAgICAgY29uZmxp Y3Qgd2l0aCB0aGUgRWxlbWVudHMgb2YgUHJvY2VkdXJlIGluIFNlY3Rpb24gNS4KICAgICAgICAg ICAgICAgICAgICBbU2VlIGNvbW1lbnRzIG9uIGRyYWZ0IDEyXQoKICA4ICBwYXJhIDIgICAgICAg ICBUaGlzIGRvY3VtZW50IG9ubHkgZGVmaW5lcyBvbmUgd2VsbC1rbm93biBwb3J0LgoKCkNyb3Nz LWRvY3VtZW50OgogIFRNU00gMy4yLjIuMSBwYXJhIDMgaW5kaWNhdGVzIHRoYXQgdG1TZWN1cml0 eU5hbWUgd2lsbCBpbmNsdWRlIHRoZQogICAgICAgICAgICAgICAgICAgICAgdHJhbnNwb3J0IHBy ZWZpeC4KICBUU00gIDMuMy4zIHBhcmEgNSAgIGV4cGxpY2l0bHkgc3RhdGVzIHRoYXQgaXQgZG9l cyBub3QuCgoKICBUTVNNICA1LjIuMSwgbGFzdCBwYXJhCiAgVFNNICAgMy4yLjEsIGxhc3QgcGFy YQogIFNTSFRNIDQuMi4xLCBsYXN0IHBhcmEKICAgICAgICAgIFRoaXMgKGNvbW1vbikgdGV4dCB0 YWxrcyBhYm91dCB0cmFuc3BvcnQgZG9tYWluL2FkZHJlc3MgdmFsdWVzCiAgICAgICAgICB3aXRo aW4gdGhlIHNlY3VyaXR5U3RhdGVSZWZlcmVuY2UgY2FjaGUgdnMgdGhlIEFTSSBwYXJhbWV0ZXJz LgogICAgICAgICAgICAgIm1pZ2h0IG92ZXJyaWRlIiBmZWVscyB1bmRlcnNwZWNpZmllZAoKICAg ICAgICAgIE5vIG1lbnRpb24gaXMgbWFkZSBoZXJlIG9mIHRoZSBlcXVpdmFsZW50IHZhbHVlcyBp biB0aGUKICAgICAgICAgIHRtU3RhdGVSZWZlcmVuY2UgY2FjaGUsIGFuZCB3aGV0aGVyIHRoZXNl IHNob3VsZC9zaG91bGRuJ3QgYmUKICAgICAgICAgIHVzZWQgaW5zdGVhZCBvZiB0aGUgQVNJIHBh cmFtcy4KICAgICAgICAgICAgU1NIVE0gNS4yIDEpIGV4cGxpY2l0bHkgc3RhdGVzIHRoYXQgdGhl c2UgY2FjaGUgdmFsdWVzIGFyZQogICAgICAgICAgaWdub3JlZC4gIElzIGl0IGludGVuZGVkIHRo YXQgdGhpcyBpcyBhIFRNLXNwZWNpZmljIGRlY2lzaW9uPwogICAgICAgICAgSWYgc28sIGl0IHdv dWxkIGJlIHNlbnNpYmxlIHRvIHN0YXRlIHRoaXMgZXhwbGljaXRseSBoZXJlLgo= ------=_Part_9165_32700674.1225821202600 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_Part_9165_32700674.1225821202600-- From isms-bounces@ietf.org Wed Nov 12 14:07:16 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B123A6B3F; Wed, 12 Nov 2008 14:07:16 -0800 (PST) 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 709FE3A6B3F for ; Wed, 12 Nov 2008 14:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.600, 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 ike-NFHnUQlp for ; Wed, 12 Nov 2008 14:07:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3065B3A63EC for ; Wed, 12 Nov 2008 14:07:13 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A2F6C001E for ; Wed, 12 Nov 2008 23:07:13 +0100 (CET) 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 7CCgCqbBn-CX; Wed, 12 Nov 2008 23:07:08 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F916C001B; Wed, 12 Nov 2008 23:07:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BEBDE85A2A2; Wed, 12 Nov 2008 23:07:06 +0100 (CET) Date: Wed, 12 Nov 2008 23:07:06 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20081112220706.GB12669@elstar.local> Mail-Followup-To: isms@ietf.org References: <20081104081320.GA26802@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081104081320.GA26802@elstar.local> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Isms] wg last call on isms document set X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Nov 04, 2008 at 09:13:20AM +0100, Juergen Schoenwaelder wrote: > This message starts the working group last call on the ISMS documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > [2] Transport Security Model for SNMP > > > [3] Secure Shell Transport Model for SNMP > > > [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > I like to remind everyone that we have our documents in WG last call. It will be very useful to receive reviews before the WG meeting next week. Also short reports that you have read the documents and are fine with them are useful. /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 isms-bounces@ietf.org Sun Nov 16 13:19:53 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8573A691B; Sun, 16 Nov 2008 13:19:53 -0800 (PST) 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 A84403A697B for ; Sun, 16 Nov 2008 13:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[AWL=0.361, 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 6psCNzHQxHEh for ; Sun, 16 Nov 2008 13:19:51 -0800 (PST) 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 80EE23A691B for ; Sun, 16 Nov 2008 13:19:51 -0800 (PST) X-Trace: 195461472/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.196/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.196 X-IP-MAIL-FROM: cfinss@dial.pipex.com 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: ArwEAMkdIEk+vGTE/2dsb2JhbACDUSkYiRnABAiBa4EGgzc X-IronPort-AV: E=Sophos;i="4.33,615,1220223600"; d="scan'208";a="195461472" X-IP-Direction: IN Received: from 1cust196.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.196]) by smtp.pipex.tiscali.co.uk with SMTP; 16 Nov 2008 21:19:43 +0000 Message-ID: <000901c94828$ce007d00$0601a8c0@allison> From: "tom.petch" To: "Dave Shield" , "ISMS WG" References: Date: Fri, 14 Nov 2008 18:06:26 +0100 MIME-Version: 1.0 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] Comments on tmsm-14 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Dave Shield" To: "ISMS WG" Sent: Friday, October 24, 2008 11:45 AM Subject: [Isms] Comments on tmsm-14 > > filename=ISMS-tmsm-14-comments.txt Transport Subsystem > ------------------- > > Section 2 > The second paragraph ends "with no significant effort..." > This comes from the text of my previous comments, where the elision was > intended to indicate that the remainder of the text from draft-12 > should be retained. > This paragraph should finish: > > "... with no significant effort on his part other than identifying > requirements and verifying the quality of service being provided." > yes but in -15 we now have 'with no significant effort with no significant effort on his part' > > Section 3.2.2.1 > The final paragraph refers to "tmSecurityLevel". However no such > field is defined in this set of documents - the tmStateReference cache > distinguishes between tmRequestedSecurityLevel and tmTransportSecurityLevel. > This section should probably refer to 'tmTransportSecurityLevel' (since > it's talking about incoming messages). > fixed in -15 > > Section 3.2.3 > The first paragraph talks about extracting security parameters "from > the transport layer by the Security Model". Isn't it the secure Transport Model that extracts these parameters? Changed in -15 but I think that this change is a mistake. The Secure Transport Model may extract them but only to put them in the cache, not to hand them over to the Message Processing Model; it is the Transport Security Model that passes them on. > > Section 3.3.1 > Paragraphs three and four talk about "securityName" and "securityLevel". > Should these be "tmSecurityName" and "tmRequestedSecurityLevel" respectively? No!! securityName and securityLevel are different concepts and are the right ones here. > > Section 3.3.2 > Paragraph one talks about "securityName" and "securityLevel". Should > these be "tmSecurityName" and "tmRequestedSecurityLevel" respectively? > No!! securityName and securityLevel are different concepts and are the right ones here. > > Paragraph two ends with "... the message should be discarded ..." > Should this be a SHOULD? > That would be a material change to the specification and not one I would agree with. > > Section 5.2.2 > The last two bulletted items do not describe fields within the > tmStateReference, and should be normal paragraphs. > fixed in -15 > > Section 6.4.1 > Is the Message Processing Subsystem allowed to modify/utilise the contents > of the tmStateReference cache? Surely it just passes this between the > Transport Model and Security Model? > That is what the specification says! I would call it keeping our options open, probably wise considering the pain and grief that it has taken to add transport security to RFC3411. > > Should the set of SNMP Transport Domains be rooted under 'snmpDomains' > (following RFC 3417) or under 'transportDomains' (following RFC 3419)? > Is it worth registering prefixes for some of the commonly-used additional > transport domains listed in RFC 3419 - e.g. SNMP-over-UDP/IPv6, or > SNMP-over-TCP (both v4 & v6)? > I think that snmpDomains is right but note that tmsm-15 s.8 erroneously refers to snmpDomain In passing, why is proxy prxy and not proxy? Is there a length limit of four characters? > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Nov 16 14:27:01 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648463A6983; Sun, 16 Nov 2008 14:27:01 -0800 (PST) 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 E150D3A693E for ; Sun, 16 Nov 2008 14:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 YVSEesad3+tv for ; Sun, 16 Nov 2008 14:26:59 -0800 (PST) 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 D90CC3A68AF for ; Sun, 16 Nov 2008 14:26:58 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with comcast id ft181a00V0mv7h05AySpuk; Sun, 16 Nov 2008 22:26:49 +0000 Received: from Harrington73653 ([130.129.79.201]) by OMTA11.westchester.pa.mail.comcast.net with comcast id fySh1a0034LcFFE3XySjg2; Sun, 16 Nov 2008 22:26:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=mrz3Wavlj5REgtFPxzMA:9 a=eYWH578w8gZc7nyGcugA:7 a=UznO26uG9X6HYCnXqJmbNqTK6QcA:4 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , "'Dave Shield'" , "'ISMS WG'" References: <000901c94828$ce007d00$0601a8c0@allison> Date: Sun, 16 Nov 2008 16:26:41 -0600 Message-ID: <006701c9483a$6ec64380$87ac1cac@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000901c94828$ce007d00$0601a8c0@allison> Thread-Index: AclIMQ+nn9nF6bt3SKGlM6UjTFIH2QABJ9og X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] Comments on tmsm-14 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] [..] > > Section 2 > yes but in -15 we now have > 'with no significant effort with no significant effort on his part' whoops. > > > > Section 3.2.3 > > The first paragraph talks about extracting security > parameters "from > > the transport layer by the Security Model". Isn't it the > secure Transport > Model that extracts these parameters? > > Changed in -15 but I think that this change is a mistake. > The Secure Transport > Model may extract them but only to put them in the cache, not > to hand them over > to the Message Processing Model; it is the Transport Security > Model that passes > them on. -15- says "before the message is passed to the Message Processing Subsystem." It doesn't say it passes the parameters to the MPM. I believe this is correct. > > > > > Section 3.3.1 > > Paragraphs three and four talk about "securityName" and > "securityLevel". > > Should these be "tmSecurityName" and > "tmRequestedSecurityLevel" respectively? > > No!! securityName and securityLevel are different concepts > and are the right > ones here. > > > > > Section 3.3.2 > > Paragraph one talks about "securityName" and > "securityLevel". Should > > these be "tmSecurityName" and "tmRequestedSecurityLevel" > respectively? > > > No!! securityName and securityLevel are different concepts > and are the right > ones here. section 3.3.2 talks about what applications provide; they never provide tmSecurityName or tmRequestedSecurityLevel. In section 3.3.1, we use both variable names. Unfortunately, it is not clear at which point in the process this is done, so it is unclear which is the right set of variables. My personal feeling is that applications SHOULD NOT be trying to select transport sessions. That creates a binding between applications and transport models that violates RFC3411 modularity. Earlier revisions said that SNMP recognized no sessions, though the transport might. I am not sure how to fix this, and await instructuons from the chair. > > > > > Paragraph two ends with "... the message should be discarded ..." > > Should this be a SHOULD? > > > > That would be a material change to the specification and not > one I would agree > with. Hmmm. I cannot find the paragraph in -15- where this is not already expressed as SHOULD. I do not understand how this would be a material change to the specification; a session-based transport model has always discarded the message if we could not establish a session. > > > > Section 6.4.1 > > Is the Message Processing Subsystem allowed to > modify/utilise the contents > > of the tmStateReference cache? Surely it just passes this > between the > > Transport Model and Security Model? > > > > That is what the specification says! I would call it keeping > our options open, > probably wise considering the pain and grief that it has > taken to add transport > security to RFC3411. It deliberately does not constrain an MPM. > > > > > Should the set of SNMP Transport Domains be rooted under > 'snmpDomains' > > (following RFC 3417) or under 'transportDomains' (following > RFC 3419)? > > Is it worth registering prefixes for some of the > commonly-used additional > > transport domains listed in RFC 3419 - e.g. SNMP-over-UDP/IPv6, or > > SNMP-over-TCP (both v4 & v6)? > > > I think that snmpDomains is right but note that tmsm-15 s.8 > erroneously refers > to snmpDomain which usage do you consider incorrect? I looked at this and do not think any usage is incorrect. The table heading is just a table heading, not an OID. > > In passing, why is proxy prxy and not proxy? Is there a > length limit of four > characters? yes. "This registry will contain ASCII strings of one to four characters ..." > dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Nov 16 23:09:27 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C523A682D; Sun, 16 Nov 2008 23:09:27 -0800 (PST) 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 129CD3A682D for ; Sun, 16 Nov 2008 23:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 TYExNFMiz1-s for ; Sun, 16 Nov 2008 23:09:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B94553A6774 for ; Sun, 16 Nov 2008 23:09:23 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15BE0C000A; Mon, 17 Nov 2008 08:09:22 +0100 (CET) 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 uhJBJ3jvLQ30; Mon, 17 Nov 2008 08:09:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4313C0004; Mon, 17 Nov 2008 08:09:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1178785D78D; Mon, 17 Nov 2008 08:09:16 +0100 (CET) Date: Mon, 17 Nov 2008 08:09:15 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20081117070915.GA17638@elstar.local> Mail-Followup-To: David Harrington , "'tom.petch'" , 'Dave Shield' , 'ISMS WG' References: <000901c94828$ce007d00$0601a8c0@allison> <006701c9483a$6ec64380$87ac1cac@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <006701c9483a$6ec64380$87ac1cac@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: 'ISMS WG' Subject: Re: [Isms] Comments on tmsm-14 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Sun, Nov 16, 2008 at 04:26:41PM -0600, David Harrington wrote: > > > Section 3.3.2 > > > Paragraph one talks about "securityName" and > > "securityLevel". Should > > > these be "tmSecurityName" and "tmRequestedSecurityLevel" > > respectively? > > > > > No!! securityName and securityLevel are different concepts > > and are the right > > ones here. > > section 3.3.2 talks about what applications provide; they never > provide tmSecurityName or tmRequestedSecurityLevel. > > In section 3.3.1, we use both variable names. Unfortunately, it is not > clear at which point in the process this is done, so it is unclear > which is the right set of variables. > > My personal feeling is that applications SHOULD NOT be trying to > select transport sessions. That creates a binding between applications > and transport models that violates RFC3411 modularity. Earlier > revisions said that SNMP recognized no sessions, though the transport > might. > > I am not sure how to fix this, and await instructuons from the chair. I suggest to discuss this in the ISMS session later today and then I might help with reading consensus. /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 isms-bounces@ietf.org Mon Nov 17 13:21:58 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6E628C0DD; Mon, 17 Nov 2008 13:21:58 -0800 (PST) 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 A6F2A3A6A5A for ; Mon, 17 Nov 2008 13:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 SfYXmV9I2WSS for ; Mon, 17 Nov 2008 13:21:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C09C63A6876 for ; Mon, 17 Nov 2008 13:21:55 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD9B1C0009 for ; Mon, 17 Nov 2008 22:21:54 +0100 (CET) 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 TblyWZgQf1nU; Mon, 17 Nov 2008 22:21:48 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5FE61C001F; Mon, 17 Nov 2008 22:21:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3FEB98607BC; Mon, 17 Nov 2008 22:21:47 +0100 (CET) Date: Mon, 17 Nov 2008 22:21:47 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20081117212147.GA2074@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Isms] draft meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am attaching the draft minutes of today's meeting. Please drop me a note in case something is recorded incorrectly. (And please review our documents in WG last call as well.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-73-minutes.txt" ======================================================= Integrated Security Model for SNMP WG (isms) IETF 73 Minneapolis Monday, November 17, 2008, 1300-1500 Taken by Juergen Schoenwaelder, Juergen Quittek ======================================================= Chair: Juergen Schoenwaelder Meeting Chair: Bert Wijnen Agenda: 1) Agenda bashing, WG status ( 5 min) (Bert Wijnen) - Blue sheets - Minute and note takers - Jabber scribe 2) Last call comment resolution (40 min) (David Harrington, David Nelson) - Transport Subsystem for SNMP [1] - Transport Security Model for SNMP [2] - Secure Shell Transport Model for SNMP [3] - RADIUS Usage for SNMP SSH Security Model [4] 3) Discussion of related drafts (10 min) (Wes Hardaker) 4) Wrap up and review of action items ( 5 min) (Bert Wijnen) WG Documents: [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) [2] Transport Security Model for SNMP [3] Secure Shell Transport Model for SNMP [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models Related Documents: [5] Datagram Transport Layer Security Transport Model for SNMP [6] Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP) [7] Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Actors: - Bert Wijnen (BW) - Juergen Quittek (JQ) - David Nelson (DN) - David Harrington (DH) - Jeff Hutzelman (JH) - Dan Romascanu (DR) Summary: The ISMS WG has four WG documents: the Transport Subsystem for SNMP , the Transport Security Model for SNMP , the Secure Shell Transport Model for SNMP , and the Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models . All four documents are in WG last call until November 23rd. The WG last call comments received so far are mainly editorial and for most of them the editor understands the edits. For one issue, the document editor will come up with a proposal for the resolution on the WG list. Additional reviews of the WG documents in last call have been requested by the chair. A DTLS transport mapping for SNMP, which is not part of the current ISMS charter, has been presented. The DTLS transport mapping author confirmed that the WG documents establish a suitable framework for defining additional secure transport models in the future and the room showed some interest in a DTLS transport for SNMP. The meeting was attended by approximately 20 people. Discussions: 1. Agenda and WG Status (BW) - BW presents the ISMS status slides - no changes to the agenda 2. Last Call Discussion (DH) - DH presents the slides detailing the changes since IETF 72 Q: What if tmSameSecurity is set but there is no LCD entry? The problematical section is 5.2 steps 3 & 4 from the SSH document. (DS) There was agreement that the message should be discarded. This is what the transport subsystem document already says but this needs to be clarified in the elements of procedure of the SSH transport mapping document Q: Another issue is related to the exposure of session information outside of the SNMP engine (DS) DH will come up with a proposal how to resolve the issue - BW polls for additional reviewers 3. Last Call Discussion (DN) - Very minor mostly editorial changes of the radius usage document since the last revision posted in October - No last call comments received so far on the radius usage document - BW and DN poll for additional reviewers 4. SVACM: Simplified VACM (DH) - SVACM is a simplified view-based access control model trying to reduce complexity and implementation costs (e.g. just one context, just one security model) - Three people in the room seem to have read the document - Authors could not present due to travel restrictions from China and the time it takes to obtain visas etc. - Some concerns were raised by JH and DR that work on access control models might be out of scope of ISMS and that any new work on access control models might require a proper IETF wide BoF 5. SNMP over DTLS (WH) - WH presents his DTLS over SNMP slides. SNMP over DTLS is not a WG work item according to the current WG charter. - Three people in the room seem to have read the document. Q: Are certificates used somewhere else for login authentication? I suspect that the name mapping problem is not specific to SNMP and that other WGs must have dealt with this before (DN) JH reports that there are a few cases where X.509 certificates are used for user authentication. Some discussion started about the usage of particular fields of X.509 certificates for identifying identities, in particular concerning subjectAltName JH stated that other WGs have not solved this problem and they usually leave the details wide open and let ultimately the application decide (JH) Q: Have there been any issues with the transport mapping specs that caused trouble in writing the dtls transport? If not, this is a good sign that we got things right (JS) WH did not find any major issues - this is a good sign that we got things right. WH also has some implementation experience with the core documents and believes they are fine to implement. C: We might have an issue with length restriction of security names (32 octets) in the longer run; if we do future work, we might have to look into this (DH) - About 9 people in the room showed interest in a DTLS transport model 6. Wrap Up and Action Points (BW) - all to review the WG documents and tell the WG mailing list - DH will present to the WG a solution for the raised technical issue - DH will apply the editorial changes received so far - DN will address any issues if they come up during last call - JS to decide what the next steps are concerning the SVACM document - JS to decide what the next steps are concerning DTLS-TM --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --6c2NcOVqGQ03X4Wi-- From isms-bounces@ietf.org Tue Nov 18 07:50:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E9F3A6A86; Tue, 18 Nov 2008 07:50:15 -0800 (PST) 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 9CB533A6A66 for ; Tue, 18 Nov 2008 07:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[AWL=1.481, 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 EYHf2iY8EAV7 for ; Tue, 18 Nov 2008 07:50:12 -0800 (PST) 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 4C6973A68A5 for ; Tue, 18 Nov 2008 07:50:12 -0800 (PST) X-Trace: 162058485/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.79 X-SBRS: None X-RemoteIP: 62.188.100.79 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAMFyIkk+vGRP/2dsb2JhbACDUUGJGrl6CYtTAQeBawh+ X-IronPort-AV: E=Sophos;i="4.33,625,1220223600"; d="scan'208";a="162058485" X-IP-Direction: IN Received: from 1cust79.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.79]) by smtp.pipex.tiscali.co.uk with SMTP; 18 Nov 2008 15:50:08 +0000 Message-ID: <004f01c9498d$162e01a0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20081104081320.GA26802@elstar.local> Date: Tue, 18 Nov 2008 15:43:47 +0100 MIME-Version: 1.0 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] wg last call on isms document set -tmsm 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I think that there is still a functional hole in tmsm s.6, the same one that has been bugging me since August 2005. On a Response, to a common or garden Get, nothing fancy, the application will pass transportDomain, transportAddress, securityModel, securityName, securityLevel to the dispatcher, which passes them unaltered to the Message Processing Model, which passes them to the (Transport) Security Model. transportDomain, transportAddress no problem, they pass unchanged through the stack Previous versions of tmsm specified that securityModel should be part of the check for an existing session in s.6.2; this has gone, I am unclear why. This suggests that different securityModel will have distinct caches. Quoting dbh slightly out of context from 12Sep2008, "We should probably add a check to ensure that, on the response, we are using the same security model as was used with the request." The text then says 'requested securityLevel' which I think should be either securityLevel, which is what the Security Model is being passed, or, perhaps, tmRequestedSecurityLevel, assuming that, although the I-D does not say, this is now set to securityLevel as passed as an IN parameter. But the real difficulty for me is the specification here of tmSecurityName 5.2.2 is explicit 'the tmSecurityName may or may not be the same as the securityName as seen by the Application and Access Control subsystems' so my question is, when they are not the same, who is doing the mapping and where so that the securityName as an IN parameter to the Security Model can be translated into tmSecurityName for comparison with existing cache entries. Whoever does it, I think that there is a problem that other parts of the stack need to know the mapping and do not. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Tuesday, November 04, 2008 9:13 AM Subject: [Isms] wg last call on isms document set > This message starts the working group last call on the ISMS documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > [2] Transport Security Model for SNMP > > > [3] Secure Shell Transport Model for SNMP > > > [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > The authors and the chair think that these documents are mature enough > for last call. Since the next IETF meeting is coming up, the last > call period is not two weeks as usual, but extends until the the end > of the IETF week. However, I like to encourage people to review these > documents before the ISMS meeting in Minneapolis (currently scheduled > for Monday November 17) so that the WG meeting time can be used to > resolve any issues that might come up during document review. > > Please do review the documents and post your comments on this list > until November 23, 2008. Please also post to the list if you have > read the documents and you are fine with them. It is very useful to > know how many people have read the documents. > > /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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Nov 19 02:03:51 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABBE3A67F5; Wed, 19 Nov 2008 02:03:51 -0800 (PST) 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 958C13A67F5 for ; Wed, 19 Nov 2008 02:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=0.987, 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 P+AJYpnb57Uw for ; Wed, 19 Nov 2008 02:03:48 -0800 (PST) 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 1C2BF3A63D3 for ; Wed, 19 Nov 2008 02:03:47 -0800 (PST) X-Trace: 108239690/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.119/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.119 X-IP-MAIL-FROM: cfinss@dial.pipex.com 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: ArwEAF9zI0k+vGR3/2dsb2JhbACDUSkYiRq6DQmLOgEHgWsIfg X-IronPort-AV: E=Sophos;i="4.33,630,1220223600"; d="scan'208";a="108239690" X-IP-Direction: IN Received: from 1cust119.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.119]) by smtp.pipex.tiscali.co.uk with SMTP; 19 Nov 2008 10:03:43 +0000 Message-ID: <000c01c94a25$db2bdca0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20081104081320.GA26802@elstar.local> Date: Wed, 19 Nov 2008 10:03:06 +0100 MIME-Version: 1.0 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] wg last call on isms document set -tmsm 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Apart from the technical problem I have flagged separately, my impression of tmsm is that it has become much vaguer, harder to follow unless you know of the background. Perhaps we will need another I-D, a 'SNMP Security Companion'. Som editorial suggestions. s.2 /wide spread/widespread/ s.3.2.1 " This Transport Subsystem uses a modular design that permits Transport Models to be "plugged into" the RFC3411 architecture, supported by corresponding Transport Models" ** reads oddly, I suspect that the second Transport Model is referring to the underlying transport. 3.2.1.3. Passing Information between SNMP Engines A secure Transport Model will establish an authenticated and/or ** this 'and/or' bugs me - it allows for unauthenticated/encrypted transport which I think is a no no " Transport Models MAY support sending multiple SNMP messages through the same tunnel." ** I have never really understood this. It seems to be saying that after sending a message, you are not REQUIRED to tear the tunnel down:-) will be prepended to all passed tmSecurityNames. ** suggest 'tmSecurityName' since that is the name of the object 3.2.2.1. securityName and securityLevel Mapping include from one to four ASCII characters, not including a ":" (ASCII ** this would allow the use of vertical tab and BEL:-) I think that the ASCII character set should be more restricted, to one of the well known sets, both in this section and in s.8 3.2.4 " either based on the message version, e.g., SNMPv1 and SNMPv2c, and " ** suggest 'either ...or' else 'both...and' 3.3.1 ** para 3 uses tmSecurityName and tmRequestedSecurityLevel para 4 uses securityName and securityLevel suggest consistency, with an explicit statement of where in the architecture you are referring to, since this determines the appropriate term, the application interface or the transport interface 6.2.2 generateResponseMessage ** this has lots of references to steps, first appeared in tmsm-13, which are not in the I-D 8 Prefix snmpDomain Reference **should be snmpDomains Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Tuesday, November 04, 2008 9:13 AM Subject: [Isms] wg last call on isms document set > This message starts the working group last call on the ISMS documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > [2] Transport Security Model for SNMP > > > [3] Secure Shell Transport Model for SNMP > > > [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > The authors and the chair think that these documents are mature enough > for last call. Since the next IETF meeting is coming up, the last > call period is not two weeks as usual, but extends until the the end > of the IETF week. However, I like to encourage people to review these > documents before the ISMS meeting in Minneapolis (currently scheduled > for Monday November 17) so that the WG meeting time can be used to > resolve any issues that might come up during document review. > > Please do review the documents and post your comments on this list > until November 23, 2008. Please also post to the list if you have > read the documents and you are fine with them. It is very useful to > know how many people have read the documents. > > /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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Nov 19 04:32:21 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D983B28C15F; Wed, 19 Nov 2008 04:32:21 -0800 (PST) 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 DA69B28C15A for ; Wed, 19 Nov 2008 04:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, 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 nUwmO6npGcBM for ; Wed, 19 Nov 2008 04:32:19 -0800 (PST) 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 741E83A6B01 for ; Wed, 19 Nov 2008 04:32:19 -0800 (PST) X-Trace: 52809536/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.201 X-SBRS: None X-RemoteIP: 62.188.105.201 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAEyWI0k+vGnJ/2dsb2JhbACDUUGJGroYCYsuAQeBawh+ X-IronPort-AV: E=Sophos;i="4.33,631,1220223600"; d="scan'208";a="52809536" X-IP-Direction: IN Received: from 1cust201.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.201]) by smtp.pipex.tiscali.co.uk with SMTP; 19 Nov 2008 12:32:16 +0000 Message-ID: <002c01c94a3a$9bfbd160$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20081104081320.GA26802@elstar.local> Date: Wed, 19 Nov 2008 12:32:12 +0100 MIME-Version: 1.0 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: jjsalowey@cisco.com Subject: Re: [Isms] wg last call on isms document set -secshell 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I cannot make sense of secshell-13 which in turn means I cannot make sense of tsm-10. Back in -11, tmStateReference contained tmTransport and tmAddress which became tmTransportDomain and tmTransportAddress in -12 and stay so in -13. No such fields are mentioned in tmsm-15 or tsm-10 or in the description of the cache in secshell-13. These fields appear from nowhere in secshell-13 s.5.1 and I have no idea why. We established years ago that there would be two values of 'securityLevel' and have kept that idea, giving them different names. We established years ago that there would be multiples values of 'securityName' and have yet to decide how and where it is mapped but no matter, we still have the idea of multiple values with distinct names. I recall no discussion asserting a need for multiple values of transport Domain and Address and cannot see one. s5.2 says '(SSHTM ignores the provided tmTransportDomain tmTransportAddress ' Since it has not been provided by tsm, then it is fortunate that it is being ignored, but really, I have no idea what is going on here. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Tuesday, November 04, 2008 9:13 AM Subject: [Isms] wg last call on isms document set > This message starts the working group last call on the ISMS documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > [2] Transport Security Model for SNMP > > > [3] Secure Shell Transport Model for SNMP > > > [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > The authors and the chair think that these documents are mature enough > for last call. Since the next IETF meeting is coming up, the last > call period is not two weeks as usual, but extends until the the end > of the IETF week. However, I like to encourage people to review these > documents before the ISMS meeting in Minneapolis (currently scheduled > for Monday November 17) so that the WG meeting time can be used to > resolve any issues that might come up during document review. > > Please do review the documents and post your comments on this list > until November 23, 2008. Please also post to the list if you have > read the documents and you are fine with them. It is very useful to > know how many people have read the documents. > > /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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Nov 19 07:26:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5F33A6A31; Wed, 19 Nov 2008 07:26:25 -0800 (PST) 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 F05C63A6A31 for ; Wed, 19 Nov 2008 07:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.381 X-Spam-Level: ** X-Spam-Status: No, score=2.381 tagged_above=-999 required=5 tests=[DATE_IN_PAST_12_24=1.77, HELO_MISMATCH_NET=0.611] 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 f+PNUu7PXtnp for ; Wed, 19 Nov 2008 07:26:23 -0800 (PST) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 4F9B93A67DD for ; Wed, 19 Nov 2008 07:26:22 -0800 (PST) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id EDF60980A7 for ; Wed, 19 Nov 2008 07:26:21 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id EFE49399BAC for ; Tue, 18 Nov 2008 08:50:42 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Tue, 18 Nov 2008 08:50:42 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] TSM nit 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org In section 4.2, Step 1 for an outgoing message we pull the securityLevel out of the securityStateReference. But... In Step 5 of the incoming processing (5.2) we don't put the securityLevel in the cache. I'd suggest we be consistent about documenting in both places what goes in and out (even though it could easily be inferred). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Nov 19 07:39:16 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C163A69AF; Wed, 19 Nov 2008 07:39:16 -0800 (PST) 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 601623A6836 for ; Wed, 19 Nov 2008 07:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[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 k823y7OrJS-l for ; Wed, 19 Nov 2008 07:39:13 -0800 (PST) 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 2C4313A6805 for ; Wed, 19 Nov 2008 07:39:13 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA09.westchester.pa.mail.comcast.net with comcast id gzL11a0030SCNGk593fBwo; Wed, 19 Nov 2008 15:39:11 +0000 Received: from Harrington73653 ([130.129.29.58]) by OMTA09.westchester.pa.mail.comcast.net with comcast id h3es1a00Q1FDwjm3V3ev1W; Wed, 19 Nov 2008 15:39:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=9WVCibXvPVEA:10 a=r2zT34aMsLsA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=ExTMcWbGe4rhoaqTWCYA:9 a=PrmSGdAUKpj_1ZrWl-cA:7 a=2Ib4kC2KxZGF2dlRTMX_E2K0dckA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=Y6qChIQXU1wA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , "'Juergen Schoenwaelder'" , References: <20081104081320.GA26802@elstar.local> <002c01c94a3a$9bfbd160$0601a8c0@allison> Date: Wed, 19 Nov 2008 09:38:51 -0600 Message-ID: <047301c94a5c$f5ca1cc0$87ac1cac@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002c01c94a3a$9bfbd160$0601a8c0@allison> Thread-Index: AclKQt4FevrdHDK0RJ62MR3Z+IYdGwAF3GZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: jjsalowey@cisco.com Subject: Re: [Isms] wg last call on isms document set -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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Tom, Thanks for catching these. comments inline > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, November 19, 2008 5:32 AM > To: Juergen Schoenwaelder; isms@ietf.org > Cc: David Harrington; Wes Hardaker; jjsalowey@cisco.com > Subject: Re: [Isms] wg last call on isms document set -secshell > > I cannot make sense of secshell-13 which in turn means I > cannot make sense of > tsm-10. > > Back in -11, tmStateReference contained tmTransport and > tmAddress which became > tmTransportDomain and tmTransportAddress in -12 and stay so > in -13. No such > fields are mentioned in tmsm-15 or tsm-10 or in the > description of the cache in > secshell-13. > > These fields appear from nowhere in secshell-13 s.5.1 and I > have no idea why. I will look at this and try to determine why the change was made. > > We established years ago that there would be two values of > 'securityLevel' and > have kept that idea, giving them different names. > > We established years ago that there would be multiples values > of 'securityName' > and have yet to decide how and where it is mapped but no > matter, we still have > the idea of multiple values with distinct names. It is the responsibility of the security model to accept "proposed" security names from possibly multiple sources on input, and craete a securityName for use with applications. On output, the reverse mapping (from securityNsme to whatever) is done. > > I recall no discussion asserting a need for multiple values > of transport Domain > and Address and cannot see one. > > s5.2 says > '(SSHTM ignores the provided tmTransportDomain tmTransportAddress ' > > Since it has not been provided by tsm, then it is fortunate > that it is being > ignored, but really, I have no idea what is going on here. I will look into this. It might be that I changed this, but incompletely, to address sameSecurity. It would seem to be wrong to allow an application to specify an address that is different than the one used to receive the request, especially since we have now added the user@example.com feature. If we want to use the same address, we need to store it in securityStateReference, which means the transport model needs to pass it in tmStateReference. The "mappings" to and from securityStateReference must happen in TSM. I think the EOP would fail to find a valid "same session" if the address was changed, so this may not be needed. dbh > > Tom Petch > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Sent: Tuesday, November 04, 2008 9:13 AM > Subject: [Isms] wg last call on isms document set > > > > This message starts the working group last call on the ISMS > documents: > > > > [1] Transport Subsystem for the Simple Network Management > Protocol (SNMP) > > > > > > [2] Transport Security Model for SNMP > > > > > > [3] Secure Shell Transport Model for SNMP > > > > > > [4] Remote Authentication Dial-In User Service (RADIUS) > Usage for Simple > > Network Management Protocol (SNMP) Transport Models > > > > > > The authors and the chair think that these documents are > mature enough > > for last call. Since the next IETF meeting is coming up, the last > > call period is not two weeks as usual, but extends until the the end > > of the IETF week. However, I like to encourage people to > review these > > documents before the ISMS meeting in Minneapolis (currently > scheduled > > for Monday November 17) so that the WG meeting time can be used to > > resolve any issues that might come up during document review. > > > > Please do review the documents and post your comments on this list > > until November 23, 2008. Please also post to the list if you have > > read the documents and you are fine with them. It is very useful to > > know how many people have read the documents. > > > > /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 > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Nov 19 08:05:23 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C9D28C156; Wed, 19 Nov 2008 08:05:23 -0800 (PST) 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 C20A828C130 for ; Wed, 19 Nov 2008 08:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 JkGvu+3VELNd for ; Wed, 19 Nov 2008 08:05:21 -0800 (PST) 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 19E5428C12E for ; Wed, 19 Nov 2008 08:05:20 -0800 (PST) X-Trace: 52895238/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.128 X-SBRS: None X-RemoteIP: 62.188.105.128 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAJjHI0k+vGmA/2dsb2JhbACDUUGJGroiCYsxAQeBawh+ X-IronPort-AV: E=Sophos;i="4.33,631,1220223600"; d="scan'208";a="52895238" X-IP-Direction: IN Received: from 1cust128.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.128]) by smtp.pipex.tiscali.co.uk with SMTP; 19 Nov 2008 16:05:14 +0000 Message-ID: <018001c94a58$5cdf8620$0601a8c0@allison> From: "tom.petch" To: , References: <20081104081320.GA26802@elstar.local> Date: Wed, 19 Nov 2008 15:55:25 +0100 MIME-Version: 1.0 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] wg last call on isms document set- tsm 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org My review of tsm is somewhat hampered by being unable to make sense of secshell but ... I think that the changes discussed in September and October have not been fully followed through. 3.2.4 The WG decided long since that for TSM, responses MUST use the same session as the request. This is clear in 3.3.1 but when you have waded through 3.2.4 you might not be so clear 'response message SHOULD be discarded' 'security-model-specific decision whether to REQUIRE this.' 'this flag is used ' - yes but when is it set? I suggest adding ' The Transport Security Model REQUIRES that the security parameters used for a response are the same as those used for the corresponding request' to the end of 3.2.4 - make it clear! 4.2 I think our caches are getting tangled. For an outgoing response, we get tmStateReference from the securityStateReference cache. But why get anything else? DBH said 12Sep08 that the securityModel should be checked and I think that absolutely right but I see no text for that. Wes 21Oct08 made me think that securityName and securityLevel would come from the tmStateReference and not from the securityStateReference cache. Surely the former is closer to the truth. We REQUIRE the same session and security for the response so why use the securityStateReference cache, which is one stage removed from the truth, at all, except to obtain the tmStateReference? Likewise, transportDomain transportAddress would come from the tmStateReference and the IN parameters would be ignored by TSM - in which case, we should spell that out lest these unused (for outgoing response) parameters confuse. I want to see 4.2 1) clearly spell out the usage of transportDomain transportAddress securityModel securityName securityLevel Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Tuesday, November 04, 2008 9:13 AM Subject: [Isms] wg last call on isms document set > This message starts the working group last call on the ISMS documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > [2] Transport Security Model for SNMP > > > [3] Secure Shell Transport Model for SNMP > > > [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > The authors and the chair think that these documents are mature enough > for last call. Since the next IETF meeting is coming up, the last > call period is not two weeks as usual, but extends until the the end > of the IETF week. However, I like to encourage people to review these > documents before the ISMS meeting in Minneapolis (currently scheduled > for Monday November 17) so that the WG meeting time can be used to > resolve any issues that might come up during document review. > > Please do review the documents and post your comments on this list > until November 23, 2008. Please also post to the list if you have > read the documents and you are fine with them. It is very useful to > know how many people have read the documents. > > /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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Nov 19 12:39:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42023A6AC1; Wed, 19 Nov 2008 12:39:36 -0800 (PST) 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 D930128C127 for ; Wed, 19 Nov 2008 12:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 uMEZG80D9YLq for ; Wed, 19 Nov 2008 12:39:33 -0800 (PST) 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 F329B3A6782 for ; Wed, 19 Nov 2008 12:39:32 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA05.westchester.pa.mail.comcast.net with comcast id h7aj1a0090xGWP8558fLa3; Wed, 19 Nov 2008 20:39:20 +0000 Received: from Harrington73653 ([130.129.79.201]) by OMTA12.westchester.pa.mail.comcast.net with comcast id h8ef1a0024LcFFE3Y8ev4H; Wed, 19 Nov 2008 20:39:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=fbkhgPYwl6AA:10 a=r2zT34aMsLsA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=mb79_Fqi59vrnjctGIcA:9 a=A-o5mSQSfZ9Na_f8htoA:7 a=ahUV4wpAjkduEWRPtSkpNPjHjbkA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , , References: <20081104081320.GA26802@elstar.local> <018001c94a58$5cdf8620$0601a8c0@allison> Date: Wed, 19 Nov 2008 14:38:38 -0600 Message-ID: <04e201c94a86$ddb612e0$87ac1cac@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <018001c94a58$5cdf8620$0601a8c0@allison> Thread-Index: AclKYKAXAXQ+016/RNS5Sy7qxGWAsgAB1nWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] wg last call on isms document set- tsm 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, comments inline. > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, November 19, 2008 8:55 AM > To: j.schoenwaelder@jacobs-university.de; isms@ietf.org > Cc: David Harrington; Wes Hardaker > Subject: Re: [Isms] wg last call on isms document set- tsm > > My review of tsm is somewhat hampered by being unable to make > sense of secshell > but ... > > I think that the changes discussed in September and October > have not been fully > followed through. > > 3.2.4 > > The WG decided long since that for TSM, responses MUST use > the same session as > the request. This is clear in 3.3.1 but when you have waded > through 3.2.4 you > might not be so clear The section "Cached Information and References" is identical in each document, except an add-on section that document-specific differences. In the old format each document said mostly the same thing, but each document was slightly different. This inconsistency across documents was confusing. So we changed it,and put document-specific cache information into a separate section. "section 3.3 Transport Security Model Cached Information The Transport Security Model has specific responsibilities regarding the cached information. " Personally, I find the new cross-document-consistency suggested by Dave Shield much easier. For all future readers who have not particpated in the discussions, I think the new format provides a more abstract and architectural description in the document, before adding the document-specific details in later sections. My impression is this will make it easier for new readers of the document. It might not make it easier for those who are trying to correlate the document text with old email messages. > > 'response message SHOULD be discarded' > 'security-model-specific decision whether to REQUIRE this.' > 'this flag is used ' - yes but when is it set? > > I suggest adding > ' The Transport Security Model REQUIRES that the security parameters > used for a response are the same as those used for the > corresponding > request' > to the end of 3.2.4 - make it clear! It is clearly stated in section 3.3.1 The Transport Security Model REQUIRES that the security parameters used for a response are the same as those used for the corresponding request. This security model sets the tmSameSecurity flag to true in the tmStateReference before passing it to the transport model. > > 4.2 > I think our caches are getting tangled. For an outgoing response, > we get tmStateReference from the securityStateReference cache. > But why get anything else? > > DBH said 12Sep08 that the securityModel should be checked and > I think that > absolutely right but I see no text for that. and as I recall, the WG consensus was that this was not neceeasry. If a flow was directed into TSM and the securityModel is not TSM, that is an implementation bug, not a TSM specification bug. > > Wes 21Oct08 made me think that securityName and securityLevel > would come from > the tmStateReference and not from the securityStateReference > cache. Surely the > former is closer to the truth. We REQUIRE the same session > and security for the > response so why use the securityStateReference cache, which > is one stage removed > from the truth, at all, except to obtain the tmStateReference? tmStateReference records session-related information (except one field, that requires updating the transaction-specific sessionID value from the associated incoming request) securityStateReference records transaction-specific information. In most instances, it makes no difference whether we use the values from securityStateReference or tmStateReference because the values will be the same. why have both? securityStateReference is defined, at least somewhat, in the RFC341x series. Unfortunately, it is not very clear. The definition of tmStateReference duplicates some fields because the TM needs to tell TSM what the values are, and the TM has no access to securityStateReference. > > Likewise, transportDomain transportAddress would come from > the tmStateReference > and the IN parameters would be ignored by TSM - in which > case, we should spell > that out lest these unused (for outgoing response) parameters confuse. I think the following text does this: "If there is a securityStateReference (Response or Report message), then this security model uses the cached information rather than the information provided by the ASI." and "If there is no securityStateReference then create a tmStateReference cache with tmRequestedSecurityLevel set to the value of securityLevel, the tmSecurityName set to securityName, and tmSameSecurity set to false." > > I want to see 4.2 1) clearly spell out the usage of > > transportDomain > transportAddress > securityModel > securityName > securityLevel I will review the text. Additional comments from others welcome. > > Tom Petch > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Sent: Tuesday, November 04, 2008 9:13 AM > Subject: [Isms] wg last call on isms document set > > > > This message starts the working group last call on the ISMS > documents: > > > > [1] Transport Subsystem for the Simple Network Management > Protocol (SNMP) > > > > > > [2] Transport Security Model for SNMP > > > > > > [3] Secure Shell Transport Model for SNMP > > > > > > [4] Remote Authentication Dial-In User Service (RADIUS) > Usage for Simple > > Network Management Protocol (SNMP) Transport Models > > > > > > The authors and the chair think that these documents are > mature enough > > for last call. Since the next IETF meeting is coming up, the last > > call period is not two weeks as usual, but extends until the the end > > of the IETF week. However, I like to encourage people to > review these > > documents before the ISMS meeting in Minneapolis (currently > scheduled > > for Monday November 17) so that the WG meeting time can be used to > > resolve any issues that might come up during document review. > > > > Please do review the documents and post your comments on this list > > until November 23, 2008. Please also post to the list if you have > > read the documents and you are fine with them. It is very useful to > > know how many people have read the documents. > > > > /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 > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 20 01:15:14 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508093A6967; Thu, 20 Nov 2008 01:15:14 -0800 (PST) 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 363C13A6967 for ; Thu, 20 Nov 2008 01:15:13 -0800 (PST) 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 dDF1a5IuhWCI for ; Thu, 20 Nov 2008 01:15:12 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by core3.amsl.com (Postfix) with ESMTP id 860853A6817 for ; Thu, 20 Nov 2008 01:15:11 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so350124mue.9 for ; Thu, 20 Nov 2008 01:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=sQzgvUNL53QN+UBe2Wy3DUk7dPN65rafdPSO2CYgj5I=; b=qt9GIuXa57qs9L30PLpZSgxUBpTAbZQOD4hPaQPLSxz5K4ud5aNnTZyskt1DpwNYdV CmVvFphM3LL0Sgu9H7uowoQYtOQOpE+JGQWBDrgWVEkoqoOiXo39iHfIj1RrBoHaAz5b hrzsCHvm2w3D/EiUw2Fmp1PzIYJyqi/OMzcsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=jyDt+JJnv9I9F3RVj6T1KIwJgyK5BbXzrTXrLfcKyygU0OqpwNDRzG3uLHNR2yGQ/b d3na0+fQgsycyr5iF3VtCVpOmZ4fKeIh4AZwmLElLe4cHRuQLFYqB/kHFy84N13LXHLe oC5IhcqJAPK4tPZUsq9JQfw2akUP8OzouY82Y= Received: by 10.181.48.13 with SMTP id a13mr657074bkk.43.1227172507906; Thu, 20 Nov 2008 01:15:07 -0800 (PST) Received: by 10.181.14.5 with HTTP; Thu, 20 Nov 2008 01:15:07 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 09:15:07 +0000 From: "Dave Shield" To: "tom. petch" , "David Harrington" In-Reply-To: <047301c94a5c$f5ca1cc0$87ac1cac@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081104081320.GA26802@elstar.local> <002c01c94a3a$9bfbd160$0601a8c0@allison> <047301c94a5c$f5ca1cc0$87ac1cac@china.huawei.com> X-Google-Sender-Auth: 5287d85929b96b2d Cc: isms@ietf.org, jjsalowey@cisco.com Subject: Re: [Isms] wg last call on isms document set -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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 2008/11/19 David Harrington : >> s5.2 says >> '(SSHTM ignores the provided tmTransportDomain tmTransportAddress ' >> >> Since it has not been provided by tsm, then it is fortunate >> that it is being ignored, but really, I have no idea what is going on here. > > I will look into this. It might be that I changed this, but > incompletely, to address sameSecurity. I believe that the transport Domain/Address information, held within the tmStateReference cache are originally supplied by the SSHTM itself, from when the request first arrived. Following the path of an incoming request, the processing appears to be as follows: The Transport Model calls the Dispatcher (receiveMessage) providing transportDomain/Address as parameters plus tmStateReference (which also contains transportDomain/Address) The Dispatcher calls the MPM (prepareDataElements) providing transportDomain/Address as parameters plus tmStateReference (which also contains transportDomain/Address) The MPM calls the Security Model (processIncomingMsg) providing tmStateReference (which contains transportDomain/Address) Control then passes back to the Dispatcher, which calls the application (processPdu). The values returned by the Security Model to the MPM, and by the MPM to the Dispatcher include do not include any transport information. Neither does the application receive any tranport information. (At least not directly, although the stateReference contains the securityStateReference which contains the tmStateReference) Following the path of the corresponding response, the processing appears to be as follows: The application calls the Dispatcher (returnResponsePdu) providing no transport information (but including stateReference) The Dispatcher calls the MPM (prepareResponseMessage) providing no transport information (but including stateReference) The MPM calls the Security Model (generateResponseMsg) providing transportDomain/Address parameters <=== *** (plus securityStateReference, which includes tmStateReference) The MPM then passes control back to the Dispatcher, providing values for destTransportDomain/Address <=== *** plus tmStateReference (which also contains transportDomain/Address) The Dispatcher calls the Transport Model providing destTransportDomain/Address as parameters plus tmStateReference (which also contains transportDomain/Address) > It would seem to be wrong to allow an application to specify an > address that is different than the one used to receive the request, The application doesn't have the opportunity to specify *any* address infomation for a response message. That is provided by the MPM Message Processing Model (at the points marked <=== *** above). Presumably cached from the processing of the incoming message. As such, this will inherently be the same value as originally supplied by the initial Transport Model (both as transportDomain/Address parameters and within the tmStateReference). I believe that I've already raised the issue of transportDomain/Address parameter values vs the contents of the tmStateReference (for TSM processing of a response message). In all the RFC3411 modules, there are distinct ASIs for dealing with outgoing requests vs responses: sendPdu vs returnResponsePdu prepareOutgoingMessage vs prepareResponseMessage generateRequestMsg vs generateResponseMsg With the existing RFC 3411 architecture, these ASIs will either take domain/address parameters (sendPdu, prepareOutgoingMessage) or a reference parameter (returnResponsePdu, prepareResponseMessage) but not both. The only ASI that takes *both* address information *and* a state reference as IN parameters, is the revised generateResponseMessage [sic] defined in the current -tmsm and -tsm drafts It would seem more sensible (IMO) *not* to add transportDomain/Address parameters to the generateResponseMsg ASI, and to use the information from the tmStateReference cache instead. Of course, generateRequestMsg *would* need these new transport parameters, since it needs to set up the transport cache itself. Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 20 01:30:28 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1A03A69FC; Thu, 20 Nov 2008 01:30:28 -0800 (PST) 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 9074A28C164 for ; Thu, 20 Nov 2008 01:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 clGFTOi5xsQv for ; Thu, 20 Nov 2008 01:30:26 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id 3783F28C18E for ; Thu, 20 Nov 2008 01:30:26 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so398864fkq.5 for ; Thu, 20 Nov 2008 01:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=+tqRq1MWIxieTMCAmPrJNezMSrasuw8SfJ4Pfbv6cA0=; b=f1DtEULdS8eU51PS+LyV+ur1+9WpXAB+cnM5TMHJhjotC9iOktrDaQ2Eu6RW1JT1RV FQoaWyx0yvPT4SrsQfQXu7crB18SVRuYBEf+ndmnKU6sUDTTj5P9hCQKmMqcM1nAE9s2 ElzyKzmydG2ph0Bx4ojlqMlINAN4Rnu+WkuEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=MJGnZgRa1Jmd2pRtM362lIqLtyQ8cR+1YvEqKdUvT8YkOCBh+MgUf+wp4JTwUu26p1 AamMQa7+CvjBwzU3S1xmx9h56ZcFsDUGmRfM+L34qWjxZjMuB7HBKq8lV0xHVQfjI7q5 XgdtpeqxMZ7Ug1+wEW88zWozb2m5Duj1+nAhU= Received: by 10.181.146.11 with SMTP id y11mr663240bkn.60.1227173422924; Thu, 20 Nov 2008 01:30:22 -0800 (PST) Received: by 10.181.14.5 with HTTP; Thu, 20 Nov 2008 01:30:22 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 09:30:22 +0000 From: "Dave Shield" To: tom.petch In-Reply-To: <004f01c9498d$162e01a0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline References: <20081104081320.GA26802@elstar.local> <004f01c9498d$162e01a0$0601a8c0@allison> X-Google-Sender-Auth: b34f17827abbba9a Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set -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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 2008/11/18 tom.petch : > But the real difficulty for me is the specification here of tmSecurityName > > 5.2.2 is explicit 'the tmSecurityName may or may not be the same as the > securityName as seen by the Application and Access Control subsystems' so my > question is, when they are not the same, who is doing the mapping and where The (transport-aware) security model. > Whoever does it, I think that there is a problem that other parts of the stack > need to know the mapping and do not. The tmSecurityName is the concern of Security Model and the Transport Model, and these modules only. No other module need consider this value. Most modules (application, Dispatcher, MPM, ACM) would only work with the securityName. The Transport Model would only wotk with the tmSecurityName (plus any internal means of identifying the transport principal). The only module that is concerned with *both* securityName and tmSecurityName (and hence needs to know about the mapping between the two) is the Security Model. That's my understanding, anyway. Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 20 10:19:45 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD393A6914; Thu, 20 Nov 2008 10:19:45 -0800 (PST) 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 4D0873A69C0 for ; Thu, 20 Nov 2008 10:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.126 X-Spam-Level: X-Spam-Status: No, score=0.126 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_20=-0.74, DATE_IN_PAST_12_24=0.992] 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 641NI9usNAF3 for ; Thu, 20 Nov 2008 10:19:43 -0800 (PST) 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 5575E3A6914 for ; Thu, 20 Nov 2008 10:19:43 -0800 (PST) X-Trace: 108815745/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.204/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.204 X-IP-MAIL-FROM: cfinss@dial.pipex.com 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: AvQEAB85JUk+vGTM/2dsb2JhbACDUSmJNcRoCIJ0 X-IronPort-AV: E=Sophos;i="4.33,639,1220223600"; d="scan'208";a="108815745" X-IP-Direction: IN Received: from 1cust204.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.204]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Nov 2008 18:19:36 +0000 Message-ID: <000f01c94b34$4af4a760$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: Date: Wed, 19 Nov 2008 20:34:53 +0100 MIME-Version: 1.0 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] TSM nit 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "Wes Hardaker" To: Sent: Tuesday, November 18, 2008 5:50 PM Subject: [Isms] TSM nit > > In section 4.2, Step 1 for an outgoing message we pull the securityLevel > out of the securityStateReference. > > But... In Step 5 of the incoming processing (5.2) we don't put the > securityLevel in the cache. I'd suggest we be consistent about > documenting in both places what goes in and out (even though it could > easily be inferred). > But why use the securityStateReference at all? Why not use tmStateReference instead? Tom Petch > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > 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 isms-bounces@ietf.org Thu Nov 20 10:19:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D783A69DC; Thu, 20 Nov 2008 10:19:47 -0800 (PST) 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 8AB893A69DC for ; Thu, 20 Nov 2008 10:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[AWL=1.363, 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 r9NmmflaRLku for ; Thu, 20 Nov 2008 10:19:44 -0800 (PST) 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 F20993A6992 for ; Thu, 20 Nov 2008 10:19:43 -0800 (PST) X-Trace: 108815751/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.204/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.204 X-IP-MAIL-FROM: cfinss@dial.pipex.com 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: AvIEAB85JUk+vGTM/2dsb2JhbACDUYleuXAJim8BB4FuCH4 X-IronPort-AV: E=Sophos;i="4.33,639,1220223600"; d="scan'208";a="108815751" X-IP-Direction: IN Received: from 1cust204.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.204]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Nov 2008 18:19:38 +0000 Message-ID: <001001c94b34$4bf80da0$0601a8c0@allison> From: "tom.petch" To: , References: <20081104081320.GA26802@elstar.local> Date: Thu, 20 Nov 2008 18:19:46 +0100 MIME-Version: 1.0 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] wg last call on isms document set - tsm b 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org tsm s. 4.2 2) leaves me puzzled. "2) If there is no securityStateReference then create a tmStateReference cache with tmRequestedSecurityLevel set to the value of securityLevel, the tmSecurityName set to securityName, and tmSameSecurity set to false" So if an application generates 99 GET in quick succession, then there will be 99 cache entries containg tmRequestedSecurityLevel and tmSecurityName but no transport domain or address (nor security model) - perhaps in addition to an entry created by a previous GET. This seems to be a cache with an entry per message, like securityStateReference, but at odds with the description in eg tmsm s 5.2 which says " The tmStateReference cache will typically remain valid for the duration of the transport session, and hence may be used for several messages." or tsm s.3 "This document defines the requirements for a cache to handle the longer-term transport state information,..." which, with other references has always left me with the impression that this was a cache with an entry for each transport session. Which is it, an entry per message, or an entry per transport session? I see problems with either alternative. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Tuesday, November 04, 2008 9:13 AM Subject: [Isms] wg last call on isms document set > This message starts the working group last call on the ISMS documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > [2] Transport Security Model for SNMP > > > [3] Secure Shell Transport Model for SNMP > > > [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > The authors and the chair think that these documents are mature enough > for last call. Since the next IETF meeting is coming up, the last > call period is not two weeks as usual, but extends until the the end > of the IETF week. However, I like to encourage people to review these > documents before the ISMS meeting in Minneapolis (currently scheduled > for Monday November 17) so that the WG meeting time can be used to > resolve any issues that might come up during document review. > > Please do review the documents and post your comments on this list > until November 23, 2008. Please also post to the list if you have > read the documents and you are fine with them. It is very useful to > know how many people have read the documents. > > /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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 20 10:35:23 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47FE3A68AD; Thu, 20 Nov 2008 10:35:23 -0800 (PST) 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 CAAD83A68AD for ; Thu, 20 Nov 2008 10:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[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 gDxVc0lN2IKd for ; Thu, 20 Nov 2008 10:35:21 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B8EE53A6861 for ; Thu, 20 Nov 2008 10:35:21 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E16BBC0088; Thu, 20 Nov 2008 19:35:19 +0100 (CET) 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 cPrTtKJ+y3WF; Thu, 20 Nov 2008 19:35:14 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 129FBC0053; Thu, 20 Nov 2008 19:35:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A87968742B8; Thu, 20 Nov 2008 19:35:12 +0100 (CET) Date: Thu, 20 Nov 2008 19:35:12 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20081120183512.GA2804@elstar.local> Mail-Followup-To: "tom.petch" , isms@ietf.org, David Harrington , Wes Hardaker References: <20081104081320.GA26802@elstar.local> <001001c94b34$4bf80da0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <001001c94b34$4bf80da0$0601a8c0@allison> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set - tsm b X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Thu, Nov 20, 2008 at 06:19:46PM +0100, tom.petch wrote: > tsm s. 4.2 2) leaves me puzzled. > > "2) If there is no securityStateReference then create a > tmStateReference cache with tmRequestedSecurityLevel set to the value > of securityLevel, the tmSecurityName set to securityName, and > tmSameSecurity set to false" > > So if an application generates 99 GET in quick succession, then there will be 99 > cache entries containg tmRequestedSecurityLevel and tmSecurityName but no > transport domain or address (nor security model) - perhaps in addition to an > entry created by a previous GET. The text says: 1) If there is a securityStateReference then ... 2) If there is no securityStateReference then ... My reading is that the first message creates the securityStateReference and then it is being reused. How do you read it differently? > Which is it, an entry per message, or an entry per transport session? I see > problems with either alternative. So what is the problem you see? /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 isms-bounces@ietf.org Fri Nov 21 00:49:35 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04CD3A67E5; Fri, 21 Nov 2008 00:49:35 -0800 (PST) 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 99E303A67F1 for ; Fri, 21 Nov 2008 00:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 fb3QgMeZpzdg for ; Fri, 21 Nov 2008 00:49:33 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by core3.amsl.com (Postfix) with ESMTP id 3F40E3A67B4 for ; Fri, 21 Nov 2008 00:49:33 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so857910mue.9 for ; Fri, 21 Nov 2008 00:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=1c3L/OF6qlBOrXs+MNPLszMy/RMET78oOuvd/M1GBVQ=; b=ROuNtwfrG2k7NVSUYt1wG5BSucB3IY7ZB4CUMdK64B03Yj5fWF6pFwk67O80Sjs0si fpeFDcy5cejDFSyI39XQ7mubVakXdwhkAXY7Xq3NBdLBiSHc3FKo6Zsfsgy966fBD0+w MgFKbrJ3tgPSiguBNJEZJvEbEBctVJNPG3UNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ffDKI+ES9OtFE6/9xopZYW4/splqsGk17mx3mnXVSi7Guh6RXhy2ZSokzmEhz7QYwY vko8Mh4HCai1po0VlGBHqBwfSN2DtuMLDrxtsZcUOKPuuFVxwqVf93O3R4JLJTgXWC9t l3UDsAafyK9W556rCiORrnabW/BIlVdyBzcAY= Received: by 10.181.139.10 with SMTP id r10mr96321bkn.64.1227257370076; Fri, 21 Nov 2008 00:49:30 -0800 (PST) Received: by 10.181.14.5 with HTTP; Fri, 21 Nov 2008 00:49:30 -0800 (PST) Message-ID: Date: Fri, 21 Nov 2008 08:49:30 +0000 From: "Dave Shield" To: j.schoenwaelder@jacobs-university.de, tom.petch In-Reply-To: <20081120183512.GA2804@elstar.local> MIME-Version: 1.0 Content-Disposition: inline References: <20081104081320.GA26802@elstar.local> <001001c94b34$4bf80da0$0601a8c0@allison> <20081120183512.GA2804@elstar.local> X-Google-Sender-Auth: 6b4e70b18f812933 Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set - tsm b 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 2008/11/20 Juergen Schoenwaelder : > The text says: > > 1) If there is a securityStateReference then ... > > 2) If there is no securityStateReference then ... > > My reading is that the first message creates the > securityStateReference and then it is being reused. No - I believe Tom is correct here. The securityStateReference is a parameter to the generateResponseMessage ASI. It isn't relevant to the processing of (outgoing) Request messages. It will be created as part of the processing of *incoming* Requests, and only exists during the processing of that single request (being discarded at the end of 4.2 step 1)) It doesn't get reused. The tmStateReference is a longer-term concept, and *should* be reused from one request to the next. The text of 4.2 step 2) should probably say something like If there is no securityStateReference (Request message) then look for an existing transport cache entry matching the requested parameters, and set tmStateReference to point to it. If such an entry does not exist, then create one, with blah blah blah That seems to be the thrust of the general summary description in the last paragraph of TMSM 6.2.2 Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 21 01:01:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96F33A683E; Fri, 21 Nov 2008 01:01:36 -0800 (PST) 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 A95DD3A6826 for ; Fri, 21 Nov 2008 01:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, 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 3FbfB-yBgNVc for ; Fri, 21 Nov 2008 01:01:35 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by core3.amsl.com (Postfix) with ESMTP id B59143A67F1 for ; Fri, 21 Nov 2008 01:01:34 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so861901mue.9 for ; Fri, 21 Nov 2008 01:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=NYM2Xtlt/VcnwUGbjZzSZZ9lSeipY8ih61Q4dc8OebQ=; b=aTX5Xr4kKVVzpdESqIm6wXVYR1661YDoU68ae0ET6O45uQDb4OkyAmTx8ZzsU+VcBt bN8bfTUvM0FUrTrvj1U4oEmUUyrowZXOQAQbjbTGiCSRi6ZKLG37VnMh4B1D8JkhPn2+ 04L5En5g/GOZFnc4OX793VRDeqqQt4xuV0000= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=XPc25ff7J1+tNaSqsO/DQK8SrN4zz1yMFFGdr65NQ4V5Vhu/LoP1IJuWHlpPIZDgg8 3xHWFdvsGvXNND9+sLpXoGRTcLgXBmLEKrUbYBzQnXu9cKTgDEvv7eW5b8VMxk4+4Rbi Kq7mIxdz4PtjAwlkfZK6/r123qf6ra1kzKVxs= Received: by 10.181.239.8 with SMTP id q8mr130873bkr.1.1227258091247; Fri, 21 Nov 2008 01:01:31 -0800 (PST) Received: by 10.181.14.5 with HTTP; Fri, 21 Nov 2008 01:01:31 -0800 (PST) Message-ID: Date: Fri, 21 Nov 2008 09:01:31 +0000 From: "Dave Shield" To: "Wes Hardaker" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: X-Google-Sender-Auth: da28b0a9cf94b339 Cc: isms@ietf.org Subject: Re: [Isms] TSM nit 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 2008/11/18 Wes Hardaker : > In section 4.2, Step 1 for an outgoing message we pull the securityLevel > out of the securityStateReference. > > But... In Step 5 of the incoming processing (5.2) we don't put the > securityLevel in the cache. According to the draft I'm looking at, step 5 simply says "The security data is cached as cachedSecurityData.... Then securityStateReference is set ... to this cached data." There's no attempt to specify what is covered by "the security data" so this may indeed include the message securityLevel value. > I'd suggest we be consistent about > documenting in both places what goes in and out I'd agree. For comparison, the equivalent description of the cachedSecurityData for USM *does* specify what should be included (RFC3414, 3.2 step 11)) Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 21 11:43:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB3A3A68CE; Fri, 21 Nov 2008 11:43:25 -0800 (PST) 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 6430C3A68CE for ; Fri, 21 Nov 2008 11:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, 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 sR0drv2MdZIV for ; Fri, 21 Nov 2008 11:43:23 -0800 (PST) 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 4652C3A6407 for ; Fri, 21 Nov 2008 11:43:23 -0800 (PST) X-Trace: 163264694/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.161 X-SBRS: None X-RemoteIP: 62.188.105.161 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAIueJkk+vGmh/2dsb2JhbABFgwyJXcdeB4J1gz8 X-IronPort-AV: E=Sophos;i="4.33,645,1220223600"; d="scan'208";a="163264694" X-IP-Direction: IN Received: from 1cust161.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.161]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Nov 2008 19:42:47 +0000 Message-ID: <029301c94c09$22322ca0$0601a8c0@allison> From: "tom.petch" To: "Dave Shield" , References: <20081104081320.GA26802@elstar.local> <001001c94b34$4bf80da0$0601a8c0@allison> <20081120183512.GA2804@elstar.local> Date: Fri, 21 Nov 2008 14:36:27 +0100 MIME-Version: 1.0 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 Subject: Re: [Isms] wg last call on isms document set - tsm b 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Dave Shield" To: ; "tom.petch" Cc: ; "David Harrington" ; "Wes Hardaker" Sent: Friday, November 21, 2008 9:49 AM Subject: Re: [Isms] wg last call on isms document set - tsm b > 2008/11/20 Juergen Schoenwaelder : > > The text says: > > > > 1) If there is a securityStateReference then ... > > > > 2) If there is no securityStateReference then ... > > > > My reading is that the first message creates the > > securityStateReference and then it is being reused. > > No - I believe Tom is correct here. > > The securityStateReference is a parameter to the > generateResponseMessage ASI. It isn't relevant > to the processing of (outgoing) Request messages. > It will be created as part of the processing of *incoming* > Requests, and only exists during the processing of > that single request (being discarded at the end of 4.2 step 1)) > It doesn't get reused. > > The tmStateReference is a longer-term concept, and > *should* be reused from one request to the next. > The text of 4.2 step 2) should probably say something like > > If there is no securityStateReference (Request message) > then look for an existing transport cache entry matching the > requested parameters, and set tmStateReference to point to it. > If such an entry does not exist, then create one, with blah blah blah > > That seems to be the thrust of the general summary description > in the last paragraph of TMSM 6.2.2 > Thanks Dave, that is how I see it but .... Can the tsm accurately find a transport cache entry? Does it have the appropriate values of transportAddress, transportDomain, securityModel, securityLevel, securityName or translations thereof to key into the cache? I think not. I had no problem with the transport details until the recent change to secshell which introduced tmTransportAddress whose meaning I remain uncertain of. But perhaps tmTransport... is synonym for transport... and this is not a problem. securityModel should be ok although there are parts of these I-Ds that seem to suggest distinct caches per securityModel which is not what I had thought. The other two I have problems with. I saw consensus years ago that the securityLevel as passed by the application was part of the key to the cache. This was challenged earlier this year, saying that it was tmTransportSecurityLevel that was used, Requested was ignored. I have seen no resolution to this but believe that mixing requested levels on a single secure transport session will create security loopholes. And security name, if it gets mapped from one value to another anywhere - and most people seem to think it will need mapping somewhere sometimes - I think will definitely cause problems since tsm and secshell can get out of synch. So yes, it would be nice if tsm could locate a cache entry, in practice I think it cannot. Tom Petch > > Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 21 11:44:46 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2C93A688B; Fri, 21 Nov 2008 11:44:46 -0800 (PST) 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 396473A688B for ; Fri, 21 Nov 2008 11:44:44 -0800 (PST) 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.815, 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 w-XoxPnvwfAk for ; Fri, 21 Nov 2008 11:44:39 -0800 (PST) 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 2DDCC3A6407 for ; Fri, 21 Nov 2008 11:44:39 -0800 (PST) X-Trace: 163264823/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.161 X-SBRS: None X-RemoteIP: 62.188.105.161 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAIueJkk+vGmh/2dsb2JhbACDUYldx14HgnWDPw X-IronPort-AV: E=Sophos;i="4.33,645,1220223600"; d="scan'208";a="163264823" X-IP-Direction: IN Received: from 1cust161.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.161]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Nov 2008 19:43:25 +0000 Message-ID: <029401c94c09$36084ca0$0601a8c0@allison> From: "tom.petch" To: "Dave Shield" , "David Harrington" References: <20081104081320.GA26802@elstar.local> <002c01c94a3a$9bfbd160$0601a8c0@allison> <047301c94a5c$f5ca1cc0$87ac1cac@china.huawei.com> Date: Fri, 21 Nov 2008 19:02:51 +0100 MIME-Version: 1.0 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, jjsalowey@cisco.com Subject: Re: [Isms] wg last call on isms document set -secshell 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Murky waters - see inline Tom Petch ----- Original Message ----- From: "Dave Shield" To: "tom. petch" ; "David Harrington" Cc: "Juergen Schoenwaelder" ; ; Sent: Thursday, November 20, 2008 10:15 AM Subject: Re: [Isms] wg last call on isms document set -secshell > 2008/11/19 David Harrington : > >> s5.2 says > >> '(SSHTM ignores the provided tmTransportDomain tmTransportAddress ' > >> > >> Since it has not been provided by tsm, then it is fortunate > >> that it is being ignored, but really, I have no idea what is going on here. > > > > I will look into this. It might be that I changed this, but > > incompletely, to address sameSecurity. > > I believe that the transport Domain/Address information, > held within the tmStateReference cache are originally supplied > by the SSHTM itself, from when the request first arrived. > > Following the path of an incoming request, the processing appears > to be as follows: > > The Transport Model calls the Dispatcher (receiveMessage) > providing transportDomain/Address as parameters > plus tmStateReference (which also contains transportDomain/Address) > The Dispatcher calls the MPM (prepareDataElements) > providing transportDomain/Address as parameters > plus tmStateReference (which also contains transportDomain/Address) > The MPM calls the Security Model (processIncomingMsg) > providing tmStateReference (which contains transportDomain/Address) > > Control then passes back to the Dispatcher, which calls the > application (processPdu). > The values returned by the Security Model to the MPM, and by the MPM > to the Dispatcher include do not include any transport information. > Neither does the application receive any tranport information. > (At least not directly, although the stateReference contains the > securityStateReference which contains the tmStateReference) > > Following the path of the corresponding response, the processing appears > to be as follows: > > The application calls the Dispatcher (returnResponsePdu) > providing no transport information (but including stateReference) > The Dispatcher calls the MPM (prepareResponseMessage) > providing no transport information (but including stateReference) > The MPM calls the Security Model (generateResponseMsg) > providing transportDomain/Address parameters <=== *** > (plus securityStateReference, which includes tmStateReference) But... the thinking was that it was up to the Security Subsystem to identify whether or not a session existed and if so, to provide a reference to it in the form of the OUT parameter tmStateReference for the Transport Subsystem to use. So the Security Subsystem to be told the transportDomain and -Address since they were/are part of the 5-tuple (along with security -Model, -Name, -Level) which are the identifier of any session. If those five are the same, then this is the session - if one differs, different session. At that time, tmStateReference was NOT part of securityStateReference so transportAddress Domain could not be obtained in that way. Perhaps this is no longer the consensus but that is why transportDomain/Address is IN and tmStateReference is OUT for generateResponseMsg Tom Petch > > The MPM then passes control back to the Dispatcher, > providing values for destTransportDomain/Address <=== *** > plus tmStateReference (which also contains transportDomain/Address) > The Dispatcher calls the Transport Model > providing destTransportDomain/Address as parameters > plus tmStateReference (which also contains transportDomain/Address) > > > > It would seem to be wrong to allow an application to specify an > > address that is different than the one used to receive the request, > > The application doesn't have the opportunity to specify *any* address > infomation for a response message. That is provided by the MPM > Message Processing Model (at the points marked <=== *** above). > Presumably cached from the processing of the incoming message. > > As such, this will inherently be the same value as originally supplied > by the initial Transport Model (both as transportDomain/Address parameters > and within the tmStateReference). > > > I believe that I've already raised the issue of transportDomain/Address > parameter values vs the contents of the tmStateReference (for TSM > processing of a response message). In all the RFC3411 modules, > there are distinct ASIs for dealing with outgoing requests vs responses: > > sendPdu vs returnResponsePdu > prepareOutgoingMessage vs prepareResponseMessage > generateRequestMsg vs generateResponseMsg > > With the existing RFC 3411 architecture, these ASIs will either take > domain/address parameters (sendPdu, prepareOutgoingMessage) or > a reference parameter (returnResponsePdu, prepareResponseMessage) > but not both. > > The only ASI that takes *both* address information *and* a state > reference as IN parameters, is the revised generateResponseMessage [sic] > defined in the current -tmsm and -tsm drafts > > It would seem more sensible (IMO) *not* to add transportDomain/Address > parameters to the generateResponseMsg ASI, and to use the information > from the tmStateReference cache instead. See above; there was a good reason for including them. I also have concerns here about the tmStateReference cache, entry per message or entry per session; I see problems with either approach. > Of course, generateRequestMsg *would* need these new transport > parameters, since it needs to set up the transport cache itself. > > > Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 21 11:45:30 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689603A689E; Fri, 21 Nov 2008 11:45:29 -0800 (PST) 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 A13C83A689E for ; Fri, 21 Nov 2008 11:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.352, 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 AnPt7TPBAkQb for ; Fri, 21 Nov 2008 11:45:23 -0800 (PST) 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 E79123A6407 for ; Fri, 21 Nov 2008 11:45:22 -0800 (PST) X-Trace: 163265129/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.161 X-SBRS: None X-RemoteIP: 62.188.105.161 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAIueJkk+vGmh/2dsb2JhbACDUYldx14HgnWDPw X-IronPort-AV: E=Sophos;i="4.33,645,1220223600"; d="scan'208";a="163265129" X-IP-Direction: IN Received: from 1cust161.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.161]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Nov 2008 19:44:46 +0000 Message-ID: <029501c94c09$686a8dc0$0601a8c0@allison> From: "tom.petch" To: "Dave Shield" References: <20081104081320.GA26802@elstar.local> <004f01c9498d$162e01a0$0601a8c0@allison> Date: Fri, 21 Nov 2008 19:11:50 +0100 MIME-Version: 1.0 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 Subject: Re: [Isms] wg last call on isms document set -tmsm 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Dave Shield" To: "tom.petch" Cc: "Juergen Schoenwaelder" ; Sent: Thursday, November 20, 2008 10:30 AM Subject: Re: [Isms] wg last call on isms document set -tmsm > 2008/11/18 tom.petch : > > But the real difficulty for me is the specification here of tmSecurityName > > > > 5.2.2 is explicit 'the tmSecurityName may or may not be the same as the > > securityName as seen by the Application and Access Control subsystems' so my > > question is, when they are not the same, who is doing the mapping and where > > The (transport-aware) security model. > > > > Whoever does it, I think that there is a problem that other parts of the stack > > need to know the mapping and do not. > > The tmSecurityName is the concern of Security Model and the Transport Model, > and these modules only. No other module need consider this value. > > Most modules (application, Dispatcher, MPM, ACM) would only work with > the securityName. > The Transport Model would only wotk with the tmSecurityName (plus any > internal means > of identifying the transport principal). > > The only module that is concerned with *both* securityName and tmSecurityName > (and hence needs to know about the mapping between the two) is the > Security Model. > The problem now is that cache entries cannot be identified. A cache entry is identified by a 5-tuple which includes a 'security' name. If this is securityName, which you say above is unknown to the Transport Subsystem, then the Transport Subsystem can never identify a cache entry. if it is the tmSecurityName, then a session cannot be identified until the Security Subsystem has performed its mapping ie the Application cannot know what will happen. I convinced myself last year that it has to be the securityName, and the mapping to tmSecurityName can only happen in the Transport Subsystem Tom Petch > > That's my understanding, anyway. > > Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 21 11:46:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEBAA3A689E; Fri, 21 Nov 2008 11:46:38 -0800 (PST) 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 01FD93A689E for ; Fri, 21 Nov 2008 11:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 ojvHt+aooiG5 for ; Fri, 21 Nov 2008 11:46:35 -0800 (PST) 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 E54033A6407 for ; Fri, 21 Nov 2008 11:46:34 -0800 (PST) X-Trace: 163265265/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.161 X-SBRS: None X-RemoteIP: 62.188.105.161 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAIueJkk+vGmh/2dsb2JhbACDUYldx14HgnU X-IronPort-AV: E=Sophos;i="4.33,645,1220223600"; d="scan'208";a="163265265" X-IP-Direction: IN Received: from 1cust161.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.161]) by smtp.pipex.tiscali.co.uk with SMTP; 21 Nov 2008 19:45:31 +0000 Message-ID: <02ae01c94c09$93b37c80$0601a8c0@allison> From: "tom.petch" To: "David Harrington" References: <20081104081320.GA26802@elstar.local> <018001c94a58$5cdf8620$0601a8c0@allison> <04e201c94a86$ddb612e0$87ac1cac@china.huawei.com> Date: Fri, 21 Nov 2008 19:16:14 +0100 MIME-Version: 1.0 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 Subject: Re: [Isms] wg last call on isms document set- tsm 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; ; Cc: "'Wes Hardaker'" Sent: Wednesday, November 19, 2008 9:38 PM Subject: RE: [Isms] wg last call on isms document set- tsm > > Wes 21Oct08 made me think that securityName and securityLevel > > would come from > > the tmStateReference and not from the securityStateReference > > cache. Surely the > > former is closer to the truth. We REQUIRE the same session > > and security for the > > response so why use the securityStateReference cache, which > > is one stage removed > > from the truth, at all, except to obtain the tmStateReference? > > tmStateReference records session-related information (except one > field, that requires updating the transaction-specific sessionID > value from the associated incoming request) Gosh, that has rocked me back on my heels. I had always imagined that tmSessionID identified a session and stayed the same for the life of the session which could encompass millions of transactions. Doubtless I have missed the text that explains it is unique to a transaction; can you point me to it please? Tom Petch > securityStateReference records transaction-specific information. > In most instances, it makes no difference whether we use the values > from securityStateReference or tmStateReference because the values > will be the same. > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Nov 22 05:14:46 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3063A6825; Sat, 22 Nov 2008 05:14:46 -0800 (PST) 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 347533A6825 for ; Sat, 22 Nov 2008 05:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FCLqmLEWRNIa for ; Sat, 22 Nov 2008 05:14:44 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id D31763A67B2 for ; Sat, 22 Nov 2008 05:14:43 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so1493596fkq.5 for ; Sat, 22 Nov 2008 05:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ShSmxJaUOIqms1lVXPhwjmJOhZh20adxEb8f89ku1OQ=; b=ioXXGUyJM8GVtbZUaAe7o2NiR+zQGREGySURZg+ZIiw6t5dq4jmDcyzG0L937M6s6K zBS1LTu6GT9pdFDfybTW9r9ehxiJ3SYiEDyfpBblktLsjWJrHovcaIvXRufVcmPjObQZ 70Qeg8EoZ5UnpH+aIPnOa76UzEhLrH9YBJy5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=B8IZA55a1F6v1nOi2NhLAMcGZyaBWmPc6V0C0eDp9S//+VLAAjQ0EpBH0A5sYCQQvU 9gDNX7Ftz+ChighvFXMyphOxWKKQFtDePV3bxoeyoWbPGx9YUwAQvqi7Wy6KDUnw5tKb lyJK4eWgzZlnycDTq4px87P3QUubo1YH0sosQ= Received: by 10.181.10.7 with SMTP id n7mr432037bki.50.1227359679608; Sat, 22 Nov 2008 05:14:39 -0800 (PST) Received: by 10.181.14.5 with HTTP; Sat, 22 Nov 2008 05:14:39 -0800 (PST) Message-ID: Date: Sat, 22 Nov 2008 13:14:39 +0000 From: "Dave Shield" To: tom.petch In-Reply-To: <029501c94c09$686a8dc0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline References: <20081104081320.GA26802@elstar.local> <004f01c9498d$162e01a0$0601a8c0@allison> <029501c94c09$686a8dc0$0601a8c0@allison> X-Google-Sender-Auth: dda0334bbd17a6a4 Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set -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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 2008/11/21 tom.petch : >> The only module that is concerned with *both* securityName and tmSecurityName >> (and hence needs to know about the mapping between the two) is the >> Security Model. >> > > The problem now is that cache entries cannot be identified. > > A cache entry is identified by a 5-tuple which includes a 'security' name. What level of the RFC3411 architecture are you talking about? Security, or Transport? In the case of the security subsystem, what you say is probably true. But in the case of the transport subsystem, the tmStateReference cache holds the information relevant to a particular transport session. So I'd expect the mapping to be more direct - perhaps via the tmSessionID value. > If this is securityName, which you say above is unknown to the > Transport Subsystem, then the Transport Subsystem can never > identify a cache entry. If the transport subsystem is processing an outgoing message, then the cache entry is provided as one of the parameters to the sendMessage() ASI. If the transport subsystem is processing an incoming message, then it knows which session the message was received on, and can select the cache entry corresponding to that session. Perhaps using the sessionID as the lookup key, or possibly the transport cache will be part of the data structure for the transport session. In any case, this is an implementation detail - it's not part of the specs. All that is required is that the transport subsystem can map between a tmStateReference cache entry and the corresponding transport session. Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Nov 22 05:16:14 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEE63A6816; Sat, 22 Nov 2008 05:16:14 -0800 (PST) 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 282F53A6816 for ; Sat, 22 Nov 2008 05:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7tsnCBg-ixDV for ; Sat, 22 Nov 2008 05:16:13 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by core3.amsl.com (Postfix) with ESMTP id CE8D73A67AB for ; Sat, 22 Nov 2008 05:16:12 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so1494117fkq.5 for ; Sat, 22 Nov 2008 05:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Z173OtXeDFDN05g6FWx+DlpIcO8TEzdciI4lx9mJLCA=; b=pu5YVVddO8qsafIwjxbeFphWlaToUL9c2IKtaUVaLXmaAiLCmOwifK4MxSMHHrG0u9 QfO46sEUdC7A6odsGViTC/sHyRVPNKyI1roTyiKhioxaYkTzxwM+vOgvM6Kbrwbu7z+n Aqwwgz/6bXgl26xbU6VHRfngUycBoIASb8ry8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=uKWhFuFdOalg9UHzGC4k0EeE2bW4Kl8ey58jwoGlhYaVMo+YSJGStN6SjtsTU9XIIT XVIiFL1KkbCcTOEjxvdmmTmdPiUn9kw1MbWgzIR0kBnoJN9MrqZq+PKPRqpJv99oemfU dW43PHx6w4blRK6ohgSIOnF1e6+POkBVJSds0= Received: by 10.181.158.16 with SMTP id k16mr418828bko.208.1227359769812; Sat, 22 Nov 2008 05:16:09 -0800 (PST) Received: by 10.181.14.5 with HTTP; Sat, 22 Nov 2008 05:16:09 -0800 (PST) Message-ID: Date: Sat, 22 Nov 2008 13:16:09 +0000 From: "Dave Shield" To: tom.petch In-Reply-To: <029301c94c09$22322ca0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline References: <20081104081320.GA26802@elstar.local> <001001c94b34$4bf80da0$0601a8c0@allison> <20081120183512.GA2804@elstar.local> <029301c94c09$22322ca0$0601a8c0@allison> X-Google-Sender-Auth: 8562ee9a780698d8 Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set - tsm b 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 2008/11/21 tom.petch : > Can the tsm accurately find a transport cache entry? Does it have the > appropriate values of transportAddress, transportDomain, securityModel, > securityLevel, securityName or translations thereof to key into the cache? All five of these values are parameters to the generateRequestMsg() ASI. So yes, it should be able to do a lookup into the transport cache, to check whether there is a suitable existing transport connection for an outgoing request. Why do you think there will be a problem with this? > I had no problem with the transport details until the recent change to secshell > which introduced tmTransportAddress whose meaning I remain uncertain of. I suspect that this may be a typographical error (possibly introduced by me). By 'tmTransportAddress/Domain', I presume the intention is to refer to the transport information held within the tmStateReference cache (rather than the ASI parameter values). But the common description of the tmStateReference cache actually talks about fields 'transortAddress' and 'transportDomain'. So there's certainly a naming inconsistency which needs to be sorted out. Personally, I'd suggest that it would be useful to have distinct names for the ASI parameters and the tmStateReference cache fields, so that it's clear exactly what is being referred to. (Although the values will typically be the same anyway, as I indicated yesterday). > The other two I have problems with. I saw consensus years ago that the > securityLevel as passed by the application was part of the key to the cache. > This was challenged earlier this year, saying that it was > tmTransportSecurityLevel that was used, Requested was ignored. If we're talking about establishing a connection for outgoing requests (and then re-using this for subsequent requests), then the securityLevel ASI parameter is the only possible candidate, since this is the *only* security level value that is available to the security model. The tmRequestedSecurityLevel field is simply used to pass this value down to the transport level. It wouldn't make sense to use this field as part of the cache lookup. If we're talking about what connection to use for an outgoing response to an incoming request, then the appropriate tmStateReference cache is already available in the securityStateReference cache. No lookup is needed. The only potentially problematical case is where a transport session is established for an incoming request, and then the local system needs to send an outgoing request (not a response) to the same remote destination. If the transport level creates a tmStateReference cache entry, then it would have to use tmTransportSecurityLevel (typically authPriv) as part of the index, since this is the only security level information it knows. If the outgoing request was requesting authPriv protection, then the cache lookup would succeed and re-use this established session for the outgoing request. But if the outgoing request needed weaker protection, then the lookup would fail, and the engine would end up (unnecessarily) creating a new connection for this traffic. But that's actually the same scenario as outgoing authPriv and authNoPriv requests to the same destination, with no existing session present. Once again, the transport session lookup for one wouldn't match the session established for the other, so you'd end up with two parallel transport sessions for the two levels of security protection. It could even be argued that this is a feature, not a bug! > I have seen no > resolution to this but believe that mixing requested levels on a single secure > transport session will create security loopholes. I'm not sure that this would happen. (See above). > And security name, if it gets mapped from one value to another anywhere - and > most people seem to think it will need mapping somewhere sometimes - I think > will definitely cause problems since tsm and secshell can get out of synch. The transport model doesn't need to know about the securityName. It doesn't even ever see it. The *only* name that the transport model is concerned with is tmSecurityName (plus whatever it uses to identify principals internally). Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 24 02:15:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C523A68BC; Mon, 24 Nov 2008 02:15:39 -0800 (PST) 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 561A33A68BC for ; Mon, 24 Nov 2008 02:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=0.231, 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 n6fBHdf7G3-G for ; Mon, 24 Nov 2008 02:15:37 -0800 (PST) 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 A24043A67B3 for ; Mon, 24 Nov 2008 02:15:36 -0800 (PST) X-Trace: 109793378/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.13/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.13 X-IP-MAIL-FROM: cfinss@dial.pipex.com 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: AsQEAL4NKkk+vGQN/2dsb2JhbACDUUGJH8JFB4J1g0E X-IronPort-AV: E=Sophos;i="4.33,658,1220223600"; d="scan'208";a="109793378" X-IP-Direction: IN Received: from 1cust13.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.13]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Nov 2008 10:15:31 +0000 Message-ID: <003c01c94e15$50f9d5c0$0601a8c0@allison> From: "tom.petch" To: "Dave Shield" References: <20081104081320.GA26802@elstar.local> <001001c94b34$4bf80da0$0601a8c0@allison> <20081120183512.GA2804@elstar.local> <029301c94c09$22322ca0$0601a8c0@allison> Date: Mon, 24 Nov 2008 09:19:32 +0100 MIME-Version: 1.0 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 Subject: Re: [Isms] wg last call on isms document set - tsm b 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "Dave Shield" To: "tom.petch" Cc: ; ; "David Harrington" ; "Wes Hardaker" Sent: Saturday, November 22, 2008 2:16 PM Subject: Re: [Isms] wg last call on isms document set - tsm b > 2008/11/21 tom.petch : > > Can the tsm accurately find a transport cache entry? Does it have the > > appropriate values of transportAddress, transportDomain, securityModel, > > securityLevel, securityName or translations thereof to key into the cache? > > All five of these values are parameters to the generateRequestMsg() ASI. > So yes, it should be able to do a lookup into the transport cache, to check > whether there is a suitable existing transport connection for an outgoing > request. > Why do you think there will be a problem with this? > a) Consider an incoming session request, successfully processed by the Transport Subsystem, followed by a message. The secshell transport model cannot know the securityLevel and if, as you have suggested, the security subsystem is responsible for translating between securityName and other name(s), then nor can it be confident that it will know the securityName. So the secshell tm creates a cache entry, passes on a message but does not know the n-tuple to identify the cache. In general, I look at the quartet of outgoing request, incoming request, outgoing response, incoming response and try to find a single set of assumptions, a single set of interpretations of the text, that will cause these four to be successfully processed. It is easy to make assumptions that will cause one or two of these to succeed, but for all four, I do not think that it is possible. > > > > I had no problem with the transport details until the recent change to secshell > > which introduced tmTransportAddress whose meaning I remain uncertain of. > > I suspect that this may be a typographical error (possibly introduced by me). > By 'tmTransportAddress/Domain', I presume the intention is to refer to the > transport information held within the tmStateReference cache (rather than > the ASI parameter values). > But the common description of the tmStateReference cache actually talks > about fields 'transortAddress' and 'transportDomain'. So there's certainly a > naming inconsistency which needs to be sorted out. > b) Yes, hopefully soon. My recollection was that the original description of the cache did not have any tm... names in it, just the names from the existing ASI but in fact it was the other way round. tmTransportDomain and tmTransportAddress were in I-Ds in 2005 (along with tmKitchenSink and everything else:-). I have pressed over the years for clarity in this area, for a specification or indication of how the tm.. values are or may be derived from the values in the RFC3411 ASIs. My pressing has in some cases identified aspects that would not work so I am still pressing:-) > Personally, I'd suggest that it would be useful to have distinct names for the > ASI parameters and the tmStateReference cache fields, so that it's clear > exactly what is being referred to. > (Although the values will typically be the same anyway, as I indicated > yesterday). > c) Well, I think the same for transport Address/Domain, potentially different for securityLevel and securityName. Tom Petch. > > > The other two I have problems with. I saw consensus years ago that the > > securityLevel as passed by the application was part of the key to the cache. > > This was challenged earlier this year, saying that it was > > tmTransportSecurityLevel that was used, Requested was ignored. > > If we're talking about establishing a connection for outgoing requests > (and then re-using this for subsequent requests), then the securityLevel > ASI parameter is the only possible candidate, since this is the *only* > security level value that is available to the security model. > The tmRequestedSecurityLevel field is simply used to pass this value > down to the transport level. It wouldn't make sense to use this field as > part of the cache lookup. > > If we're talking about what connection to use for an outgoing response > to an incoming request, then the appropriate tmStateReference cache > is already available in the securityStateReference cache. > No lookup is needed. > > The only potentially problematical case is where a transport session is > established for an incoming request, and then the local system needs to > send an outgoing request (not a response) to the same remote destination. > If the transport level creates a tmStateReference cache entry, then it > would have to use tmTransportSecurityLevel (typically authPriv) as part of > the index, since this is the only security level information it knows. > > If the outgoing request was requesting authPriv protection, then the cache > lookup would succeed and re-use this established session for the outgoing > request. But if the outgoing request needed weaker protection, then the > lookup would fail, and the engine would end up (unnecessarily) creating a > new connection for this traffic. > But that's actually the same scenario as outgoing authPriv and authNoPriv > requests to the same destination, with no existing session present. Once > again, the transport session lookup for one wouldn't match the session > established for the other, so you'd end up with two parallel transport sessions > for the two levels of security protection. > It could even be argued that this is a feature, not a bug! > > > > > I have seen no > > resolution to this but believe that mixing requested levels on a single secure > > transport session will create security loopholes. > > I'm not sure that this would happen. (See above). > > > > > And security name, if it gets mapped from one value to another anywhere - and > > most people seem to think it will need mapping somewhere sometimes - I think > > will definitely cause problems since tsm and secshell can get out of synch. > > The transport model doesn't need to know about the securityName. It doesn't > even ever see it. The *only* name that the transport model is concerned with is > tmSecurityName (plus whatever it uses to identify principals internally). > > > Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 24 02:15:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8622C3A69DD; Mon, 24 Nov 2008 02:15:39 -0800 (PST) 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 B01F33A67B3 for ; Mon, 24 Nov 2008 02:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[AWL=-1.098, 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 8Ij92LzOe8Kp for ; Mon, 24 Nov 2008 02:15:38 -0800 (PST) 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 A64123A681D for ; Mon, 24 Nov 2008 02:15:37 -0800 (PST) X-Trace: 109793401/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.13/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.13 X-IP-MAIL-FROM: cfinss@dial.pipex.com 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: AsQEAL4NKkk+vGQN/2dsb2JhbACDUUGJH8JFB4FtgQiDQQ X-IronPort-AV: E=Sophos;i="4.33,658,1220223600"; d="scan'208";a="109793401" X-IP-Direction: IN Received: from 1cust13.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.13]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Nov 2008 10:15:33 +0000 Message-ID: <003d01c94e15$525a5020$0601a8c0@allison> From: "tom.petch" To: "Dave Shield" References: <20081104081320.GA26802@elstar.local> <004f01c9498d$162e01a0$0601a8c0@allison> <029501c94c09$686a8dc0$0601a8c0@allison> Date: Mon, 24 Nov 2008 09:24:04 +0100 MIME-Version: 1.0 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 Subject: Re: [Isms] wg last call on isms document set -tmsm 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Dave Shield" To: "tom.petch" Cc: "Juergen Schoenwaelder" ; Sent: Saturday, November 22, 2008 2:14 PM Subject: Re: [Isms] wg last call on isms document set -tmsm > 2008/11/21 tom.petch : > >> The only module that is concerned with *both* securityName and tmSecurityName > >> (and hence needs to know about the mapping between the two) is the > >> Security Model. > >> > > > > The problem now is that cache entries cannot be identified. > > > > A cache entry is identified by a 5-tuple which includes a 'security' name. > > What level of the RFC3411 architecture are you talking about? > Security, or Transport? > > In the case of the security subsystem, what you say is probably true. > > But in the case of the transport subsystem, the tmStateReference > cache holds the information relevant to a particular transport session. > So I'd expect the mapping to be more direct - perhaps via the > tmSessionID value. > To quote tmsm, the update to RFC3411, " In summary, a unique combination of transportDomain, transportAddress, securityName, and securityLevel could serve to identify a given transport session. Different values for any of these parameters would imply the use of a different session." so while sessions are not supported and there is no session selector in the Abstract Service Interfaces, I do expect that there is an n-tuple doing that job, or an explanation of why that is not the case for a particular Transport Model and the interactions of a Security Model with it. Tom Petch > > If this is securityName, which you say above is unknown to the > > Transport Subsystem, then the Transport Subsystem can never > > identify a cache entry. > > If the transport subsystem is processing an outgoing message, > then the cache entry is provided as one of the parameters to the > sendMessage() ASI. > > If the transport subsystem is processing an incoming message, > then it knows which session the message was received on, and > can select the cache entry corresponding to that session. > Perhaps using the sessionID as the lookup key, or possibly the > transport cache will be part of the data structure for the transport > session. > In any case, this is an implementation detail - it's not part of the > specs. All that is required is that the transport subsystem can > map between a tmStateReference cache entry and the corresponding > transport session. > > Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 24 02:15:41 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DAF3A6BA5; Mon, 24 Nov 2008 02:15:41 -0800 (PST) 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 53A0D3A6BA5 for ; Mon, 24 Nov 2008 02:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.624, 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 Ik-qlNyhH0EX for ; Mon, 24 Nov 2008 02:15:39 -0800 (PST) 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 D871D3A67B3 for ; Mon, 24 Nov 2008 02:15:38 -0800 (PST) X-Trace: 109793418/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.13/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.13 X-IP-MAIL-FROM: cfinss@dial.pipex.com 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: AsQEAL4NKkk+vGQN/2dsb2JhbACDUUGJH7kJBwEIiSwBBoFtAQcBfw X-IronPort-AV: E=Sophos;i="4.33,658,1220223600"; d="scan'208";a="109793418" X-IP-Direction: IN Received: from 1cust13.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.13]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Nov 2008 10:15:35 +0000 Message-ID: <003e01c94e15$533c24a0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20081104081320.GA26802@elstar.local> Date: Mon, 24 Nov 2008 10:11:50 +0100 MIME-Version: 1.0 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] wg last call on isms document set 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen The end date of the last call is past so where have I got to? I suspect that some of the procedures described in the I-Ds do not work but have difficulty in being sure on account of underlying issues. Hopefully, these, at least in part, can be resolved fairly quickly. 1) the (re-)appearance of tmTranportAddress/Domain in secshell with no explanation of how they relate to transportAddress/Domain. Hopefully just an editorial glitch. 2) does a single secshell transport session, assumed of course to have authentication and privacy, multiplex messages of different securityLevel? I had always assumed not, based on discussions on this list and on tmsm s.3.3.1. But earlier this year, I was told that no, of course multiplexing would happen. I see this as an open issue. 3) why is securityModel not part of the 'session selector'? It was present up until tmsm-07 where it was removed "since this is not known for incoming messages until the message processing model". True, but also true for securityLevel. The implication is that if a USM 'session' is set up to a given transportAddress/Domain with a given securityName/Level, then it is impossible to set up a secshell session with the same 4-tuple since these have the same identifier; aliter, an application cannot influence the choice between USM and TSM. I am not sure that this is what I want. 4) is the tmStateReference updated with each message, as the recent text implies? or is it long term information about the session that remains invariant until the session is taken down? I had always assumed the latter and was surprised to see the former. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Tuesday, November 04, 2008 9:13 AM Subject: [Isms] wg last call on isms document set > This message starts the working group last call on the ISMS documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > [2] Transport Security Model for SNMP > > > [3] Secure Shell Transport Model for SNMP > > > [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > The authors and the chair think that these documents are mature enough > for last call. Since the next IETF meeting is coming up, the last > call period is not two weeks as usual, but extends until the the end > of the IETF week. However, I like to encourage people to review these > documents before the ISMS meeting in Minneapolis (currently scheduled > for Monday November 17) so that the WG meeting time can be used to > resolve any issues that might come up during document review. > > Please do review the documents and post your comments on this list > until November 23, 2008. Please also post to the list if you have > read the documents and you are fine with them. It is very useful to > know how many people have read the documents. > > /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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 24 04:49:44 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90EE53A68D5; Mon, 24 Nov 2008 04:49:44 -0800 (PST) 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 F2E403A68D5 for ; Mon, 24 Nov 2008 04:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 NBKSkkcfmpCH for ; Mon, 24 Nov 2008 04:49:38 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 66FA43A688E for ; Mon, 24 Nov 2008 04:49:38 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1654554fga.41 for ; Mon, 24 Nov 2008 04:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=f88ZEgUohjqovq0xPgfYsH70ERM+Ex6CJm9MA5fmPvk=; b=vlJXO6jheqHa9sQiPlZ3cPVg/AReenWa2eusYtAeMm0E01LdJPTJqDKmGlawLcRfkd wixwfIl9Dtus8DoQO2tPZ7JdAs6aebNhIJAhZ9pE2jPdrTKmFtzwxuS6kMRQL091fazz kxfWerFHyg2IOVIjQn0W6UHi2fxm/lwo8RFC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=J5OiY8d25/LUIBY8xvGT3+bQiVxvYftjDhaCzFvE+IVxkqYUNAoE9txGM9ZlOwV6i5 aZgagEn/bH6RIAneps+4tZHDgkjxukkYv7aQTnm8zT3QwP59hb3sgyje8hRI9CAxm2JO evyGgSheuUbRHSfPzihN3nZ8G8vBvV+g09LO8= Received: by 10.181.55.2 with SMTP id h2mr1123444bkk.52.1227530973972; Mon, 24 Nov 2008 04:49:33 -0800 (PST) Received: by 10.181.14.5 with HTTP; Mon, 24 Nov 2008 04:49:33 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 12:49:33 +0000 From: "Dave Shield" To: tom.petch In-Reply-To: <003d01c94e15$525a5020$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline References: <20081104081320.GA26802@elstar.local> <004f01c9498d$162e01a0$0601a8c0@allison> <029501c94c09$686a8dc0$0601a8c0@allison> <003d01c94e15$525a5020$0601a8c0@allison> X-Google-Sender-Auth: 979724ee6a5defe1 Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set -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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 2008/11/24 tom.petch : > To quote tmsm, the update to RFC3411, > > " In summary, a unique combination of transportDomain, > transportAddress, securityName, and securityLevel could serve to > identify a given transport session. Different values for any of > these parameters would imply the use of a different session." > > so while sessions are not supported and there is no session selector in the > Abstract Service Interfaces, I do expect that there is an n-tuple doing that > job, or an explanation of why that is not the case for a particular Transport > Model and the interactions of a Security Model with it. I view that text as descriptive, rather then prescriptive. A given transport session will be associated with fixed values for the security information. The n-tuple "could" be used to identify a particular session (which is typically what would be done at the higher-level modules - application and security). That's different from saying that this n-tuple "must" be used to identify the session. As I understand it, the Transport Model *will* end up using the transport session appropriate for that n-tuple of values. It's just that it doesn't use the n-tuple as a lookup mechanism (so it doesn't matter that some of these values are not available). Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 24 05:02:46 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6963A69DC; Mon, 24 Nov 2008 05:02:46 -0800 (PST) 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 359003A69DC for ; Mon, 24 Nov 2008 05:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 fxLiJqLcW4pf for ; Mon, 24 Nov 2008 05:02:44 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id 149623A68D5 for ; Mon, 24 Nov 2008 05:02:43 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so2368186fkq.5 for ; Mon, 24 Nov 2008 05:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=UrUJNLx74JM4dKJxghG4pYF6cKquB3ZuNZ646f1+wlI=; b=Onqpy12s6XHBbLb/P+y+keZWbZFp04UxyZaleHz746QwmQtnekvgmvuKsB38FDaaVG e5SUl2osQf63euo+hIckNAwhRlo/SaRRmRgtdCRk7WZREErHcJMwTmHRuhN8Ad0D9OOn CBhHMVwtdtHOeNYdt8y5DJA0tJQRuI73s99n8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ppLzVItNZZ5v/e4wmOp2sfy2Rs9EDdCtWFSL0VZwMJ0SPT4pj3wTVVe/2/Hi3l8ADT NwZxet/oHQzELUunfKtdbY1lrQHqHGd6g6gYE6ALlTDl2fr7yeNkMlqzp6pqTKPjvDvH QzRflRL5ZQ093eBNOC0cvNlsNqmq4fCt8H/JY= Received: by 10.181.197.6 with SMTP id z6mr711449bkp.213.1227531759841; Mon, 24 Nov 2008 05:02:39 -0800 (PST) Received: by 10.181.14.5 with HTTP; Mon, 24 Nov 2008 05:02:39 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 13:02:39 +0000 From: "Dave Shield" To: tom.petch In-Reply-To: <003c01c94e15$50f9d5c0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline References: <20081104081320.GA26802@elstar.local> <001001c94b34$4bf80da0$0601a8c0@allison> <20081120183512.GA2804@elstar.local> <029301c94c09$22322ca0$0601a8c0@allison> <003c01c94e15$50f9d5c0$0601a8c0@allison> X-Google-Sender-Auth: 59a608f3ebfa6d36 Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set - tsm b 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 2008/11/24 tom.petch : > a) Consider an incoming session request, successfully processed by the Transport > Subsystem, followed by a message. The secshell transport model cannot know the > securityLevel and if, as you have suggested, the security subsystem is > responsible for translating between securityName and other name(s), then nor can > it be confident that it will know the securityName. So the secshell tm creates > a cache entry, passes on a message but does not know the n-tuple to identify the > cache. Indeed. But I don't think that it needs to. As long as it can map from a given transport session to the appropriate cache entry, and from a transport cache entry to the corresponding session, then it will always be using the appropriate transport for that particular n-tuple. (Even though it doesn't know what that n-tuple actually is). It's the security model that would be using the n-tuple of security values as a lookup index. So in the scenario you outline, it might well need to add this mapping for the incoming request to its local lookup table. It could then use these lookup values to identify the same transport cache for the outgoing request > In general, I look at the quartet of outgoing request, incoming request, > outgoing response, incoming response and try to find a single set of > assumptions, a single set of interpretations of the text, that will cause these > four to be successfully processed. I'll need to sit down and think about all the (valid) combinations of these requests to make sure that my reading of the current specs works correctly in all cases. But I'm reasonably confident that everything should be OK. Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 24 17:36:32 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72EA53A67FB; Mon, 24 Nov 2008 17:36:32 -0800 (PST) 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 26F843A67FB for ; Mon, 24 Nov 2008 17:36:31 -0800 (PST) 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 zefaqrKxa7F7 for ; Mon, 24 Nov 2008 17:36:30 -0800 (PST) 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 2C4063A677E for ; Mon, 24 Nov 2008 17:36:27 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA03.westchester.pa.mail.comcast.net with comcast id jA581a00E0xGWP853DbHVa; Tue, 25 Nov 2008 01:35:17 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id jDcQ1a00G0UQ6dC3YDcQSW; Tue, 25 Nov 2008 01:36:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=pFSvqYct6o1-cqWozvgA:9 a=459OfRDBfV4bmefjWEp7nAHAuX8A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Mon, 24 Nov 2008 20:36:24 -0500 Message-ID: <00a101c94e9e$3a67a4c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclOnjnpPHVj51BmRuSpX7RI0QzVeg== Subject: [Isms] sshtm nit 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, section 4.3.1 is incorrect. It says: The tmSecurityName is presented to the SSH Transport Model by the application (possibly because of configuration specified in the SNMP-TARGET-MIB). This is incorrect. tmSecurityName is presented to SSHTM by a transport-aware security model such as TSM. How the security model decided what tmSecurityName to present is immaterial to SSHTM. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 24 17:55:42 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CC13A6947; Mon, 24 Nov 2008 17:55:42 -0800 (PST) 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 1E6A93A6947 for ; Mon, 24 Nov 2008 17:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 L-0ouyNPG9rO for ; Mon, 24 Nov 2008 17:55:40 -0800 (PST) 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 B3C433A67FB for ; Mon, 24 Nov 2008 17:55:39 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA03.westchester.pa.mail.comcast.net with comcast id jBvF1a00117dt5G53DuUUj; Tue, 25 Nov 2008 01:54:28 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id jDvb1a00a0UQ6dC3ZDvcX7; Tue, 25 Nov 2008 01:55:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=Ek5kk0_f0xB9JuolS20A:9 a=nBMqiRVzdi6M_PVcrDsA:7 a=RZ5knTKXvs2C5e6oLIbYfnY37oYA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=8847bm5PGg4A:10 From: "David Harrington" To: "'David Harrington \(E-mail 2\)'" Date: Mon, 24 Nov 2008 20:55:35 -0500 Message-ID: <00a801c94ea0$e8a6f700$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclOoOhM095mApRJQsSsXHm7SdlnUg== Cc: isms@ietf.org Subject: [Isms] sshtm 4.3 1 nit - partt 2 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org s/The identity SHOULD be the value of the user name field of the/ The tmSecurityName SHOULD be the value of the user name field of the/ s/mapping algorithm to transform a user name to a SSH identity compatible with the parameters required by this transport./ mapping algorithm to transform an SSH identity to a tmSecurityName, and to transform a tmSecurityName to an SSH identity./ s/How a compatible SSH identity is determined should be administratively configurable if such a mapping is needed.// (I don't know how an administrator can configure this. It seems to be implementation-dependent. If we do not specify a standard for translating from GSSAPI identity to tmSecurityName and back, then the transforms will be implementation-specific (probably vendor-specific). The most important thing is that it is predictable and documented, so an operator will know how a GSSAPI identity will be mapped to a tmSecurityName.) The securityName derived from the tmSecurityName by a security model is used to configure notifications and access controls. Non-default transport model transforms SHOULD generate a predictable identity representing the principal. The securityName is not necessarily derived from tmSecurityName; it could just as easily be derived from community or from msgSecurityName. The securityName MAY be used to configure MIB modules, such as for notifications and access control. also: s/Non-default transport model transforms/transport models/ s/identity representing the principal/tmSecurityName/ David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 24 19:27:57 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B583A69B1; Mon, 24 Nov 2008 19:27:57 -0800 (PST) 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 330683A68DD for ; Mon, 24 Nov 2008 19:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.072, 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 D6Htjt8F7yjB for ; Mon, 24 Nov 2008 19:27:54 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 5309E3A67FB for ; Mon, 24 Nov 2008 19:27:54 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA08.westchester.pa.mail.comcast.net with comcast id jDvx1a00T0vyq2s58FTreH; Tue, 25 Nov 2008 03:27:51 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id jFTp1a00A0UQ6dC3RFTpj8; Tue, 25 Nov 2008 03:27:51 +0000 X-Authority-Analysis: v=1.0 c=1 a=MzUmlQ5_VHYA:10 a=r2zT34aMsLsA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=NsM_AZ5qwGzGA1Ecr4AA:9 a=5lBDQSSaVwbAiDnR1pMA:7 a=4hs9n1ipKum-0CdV6rBM6rNayLIA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , "'Juergen Schoenwaelder'" , References: <20081104081320.GA26802@elstar.local> <003e01c94e15$533c24a0$0601a8c0@allison> Date: Mon, 24 Nov 2008 22:27:49 -0500 Message-ID: <00af01c94ead$cba18a00$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <003e01c94e15$533c24a0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclOHZuzXPLPg1QIRaKHvxl2tpJE7QAc33qQ Subject: Re: [Isms] wg last call on isms document set 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Let me respond with my view of the universe. > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Monday, November 24, 2008 4:12 AM > To: Juergen Schoenwaelder; isms@ietf.org > Subject: Re: [Isms] wg last call on isms document set > > Juergen > > The end date of the last call is past so where have I got to? > > I suspect that some of the procedures described in the I-Ds > do not work but have > difficulty in being sure on account of underlying issues. > Hopefully, these, at > least in part, can be resolved fairly quickly. > > 1) the (re-)appearance of tmTranportAddress/Domain in secshell with no > explanation of how they relate to transportAddress/Domain. > Hopefully just an > editorial glitch. I need to check this one. > > 2) does a single secshell transport session, assumed of course to have > authentication and privacy, multiplex messages of different > securityLevel? I > had always assumed not, based on discussions on this list and > on tmsm s.3.3.1. > But earlier this year, I was told that no, of course > multiplexing would happen. > I see this as an open issue. I do not see it as an open issue. Architecturally (i.e., in tmsm), an application can request different levels of security. Practically, a security model that relies on lower layers to provide security (i.e., TSM) cannot tell whether security level has been applied as requested. It must take the transport model's assertion of securityLevel. Secure Shell Transport Model states: SSH provides the "none" userauth method. The SSH Transport Model MUST NOT be used with an SSH connection with the "none" userauth method. While SSH does support turning off confidentiality and integrity, they MUST NOT be turned off when used with the SSH Transport Model. As a result, SSHTM does not support noAuthNoPriv or NoAuthPriv. The only securityLevel it supports is authPriv. An application cannot request noAuthNoPriv or NoAuthPriv and get such a securityLevel from SSHTM. All requests are treated as (promoted to) authPriv. Since authPriv is the only level supported by SSHTM, it does not make sense to have multiple sessions for the same securityModel and securityname and securityLevel (authPriv) at the same remote address. You only need one authPriv connection. (And having three different authPriv connections called authPriv, AuthNoPriv, and NoAuthNoPriv is simply misleading. I strongly recommend against adding support for this "feature".) For RFC3411 modularity purposes, an application has never been allowed to specify a particular transport session (not that any existing transport mapping HAD transport sessions). We do not pass any type of transport session ID to the application subsystem, and the application subsystem never passes a transport session selector in an ASI. An application should know nothing about transport-specific sessions. Even the (transport) security model should know nothing about transport-specific sessions. That violates RFC3411 modularity. We added sessionID to tmStateReference so a security model could store an opaque reference to some type of transport session identification so the security model can pass it back, so the transport model could match requests and corresponding responses. > > 3) why is securityModel not part of the 'session selector'? **** We should not have a 'session selector' **** The only place we should be dealing with transport-specific sessions is in the transport model. Period!!! I would be absolutely thrilled to remove all notion of session selection from these documents, except the opaque sessionID required for sameSecurity. I think the idea of allowing an application to try to select a particular transport session is absolutely wrong from the RFC3411 perspective. The application can choose what transportDomain, transportAddress, securtityModel, securityName, and securityLevel it would like used. However, because the handling of transport sessions is specific to each transport model, some transport models MAY restrict the applicability of these parameters for selecting an associated transport session. And I should add ... However, because the handling of securityName and securityLevel are specific to each security model, some security models MAY restrict the applicability of these parameters for selecting security properties. (Keep in mind that the SNMPv1 Security Model and the SNMPv2 Security Model [RFC3584] always tell an application that the securityLevel is noAuthNoPriv, regardless of any additional authentication or encryption provided by the transport used.) > It was present up > until tmsm-07 where it was removed "since this is not known > for incoming > messages until the message processing model". True, but also true for > securityLevel. The implication is that if a USM 'session' is > set up to a given > transportAddress/Domain with a given securityName/Level, then > it is impossible > to set up a secshell session with the same 4-tuple since > these have the same > identifier; aliter, an application cannot influence the > choice between USM and > TSM. I am not sure that this is what I want. I am certain that I do not WANT applications to try to select particular transport sessions. And SNMP has no sessions to select. I would be happy to remove the text that suggests "selecting a session" makes any sense here. But let's talk about 4-tuples. An application most certainly can influence the choice between USM and TSM; every ASI on the path between the application subsystem and the security subsystem includes securityModel. That's how it gets delivered to the appropriate security model. The RFC3411 architecture is built on the principal that information necessary to each model, and especially information that is modifiable by each model, should be in a conceptually separate data store (e.g., a MIB module) for that model. This is important to make sure one model does not cause side-effects by changing another model's datastore. Each security model uses its own MIB (or its own implementation-dependent datastore). USM and TSM do not share standardized datastores. Whether they do at the implementation-level is implementation-dependent. So any type of 'session selector' might mean totally different things in USM and TSM and SNMPv1-SM and SNMPv2-SM, and might mean totally different things in different transport models (or mappings), such as UDP, TCP, CMOT, SSHTM, DTLSTM. That's why we should not have any mention of session selectors except within a model that has model-specific sessions. > > 4) is the tmStateReference updated with each message, as the > recent text > implies? or is it long term information about the session > that remains > invariant until the session is taken down? I had always > assumed the latter and > was surprised to see the former. Well, securityStateReference and tmStateReference are references. securityStateReference references a specific securityState, and tmStateReference references a particular tmState. It is implementation-dependent how tmState and securityState and the references to them are implemented (duh). The sessionID field that is contained in the tmState is used for one and only one purpose - to match corresponding request and response sessions to ensure sameSecurity. It is never used for any other purpose. And it is opaque to the security model. The securityState includes a reference to a tmState. That tmStateReference must reference the tmState that identifies the session on which a request was received, so TSM can require the same session be used when sending the associated response. It is model-dependent (and possibly implementation-dependent) how the transport model compares the sessionID value from a tmStateReference and its notion of a current sessionID. In my view of the universe, this means, every time we receive a request, the associated tmStateReference must point to a tmState that accurately records the sessionID the incoming message was received on. As long as there is a request/response transaction in-process, we cannot change the securityState (or its Reference) or the tmState (or its Reference) or the sessionID field contained in that tmState. That is true even if we receive another request before the first response is sent. If a session closes and another is opened while a request/response transaction is in-process, we need to be able to look at the tmState for the request and compare that to the current tmState to be used for the response. If the security model REQUIRES sameSEcurity, and the tmState for the request and the tmState for the response do not match, then we MUST discard the message. Let's assume I keep my tmStates in an array, and each entry identifies a specific long-lived session. (The sessionID might simply be the array index.) Every time I receive a request, I pass a reference (or pointer) to the appropriate array entry. But wait, there's more! Since the transport model has no access to the PDU type, it doesn't know which messages contain requests. Therefore it must pass a tmStateReference for each received message, regardless of PDU, and the tmStateReference points to the tmState for that incoming message. If two incoming messages use different sessions, the tmStateReference associated with each message is set to point to the associated tmState used for each message. (So in my implementation, the first tmStateReference might be a pointer to tmState[1], and the second tmStateReference might be a pointer to tmState[2].) If two incoming messages use the same session, the tmStateReference associated with each message is set to point to the associated tmState used for each message. (So in my implementation, the first tmStateReference might be a pointer to tmState[1], and the second tmStateReference might be a pointer to tmState[1] as well.) If the transport model gets on outgoing message with a sameSecurity=true, then the transport model checks that the sessionID for the transport session used to send the message matches the sessionID in the tmState that is referenced by the tmStateReference. > > Tom Petch > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Sent: Tuesday, November 04, 2008 9:13 AM > Subject: [Isms] wg last call on isms document set > > > > This message starts the working group last call on the ISMS > documents: > > > > [1] Transport Subsystem for the Simple Network Management > Protocol (SNMP) > > > > > > [2] Transport Security Model for SNMP > > > > > > [3] Secure Shell Transport Model for SNMP > > > > > > [4] Remote Authentication Dial-In User Service (RADIUS) > Usage for Simple > > Network Management Protocol (SNMP) Transport Models > > > > > > The authors and the chair think that these documents are > mature enough > > for last call. Since the next IETF meeting is coming up, the last > > call period is not two weeks as usual, but extends until the the end > > of the IETF week. However, I like to encourage people to > review these > > documents before the ISMS meeting in Minneapolis (currently > scheduled > > for Monday November 17) so that the WG meeting time can be used to > > resolve any issues that might come up during document review. > > > > Please do review the documents and post your comments on this list > > until November 23, 2008. Please also post to the list if you have > > read the documents and you are fine with them. It is very useful to > > know how many people have read the documents. > > > > /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 > > _______________________________________________ > 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 isms-bounces@ietf.org Mon Nov 24 23:28:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A303A6A93; Mon, 24 Nov 2008 23:28:48 -0800 (PST) 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 C0ED83A6A95 for ; Mon, 24 Nov 2008 23:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 DmvMSTLiyndG for ; Mon, 24 Nov 2008 23:28:46 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0BAAF3A682F for ; Mon, 24 Nov 2008 23:28:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,663,1220227200"; d="scan'208";a="109593635" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Nov 2008 07:28:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mAP7SiCR018328 for ; Mon, 24 Nov 2008 23:28:44 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAP7SisA026208 for ; Tue, 25 Nov 2008 07:28:44 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 23:28:43 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 23:28:42 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-isms-tmsm-15 Thread-Index: AclOz3El9mjb/HwjTlS+JZOK+/vkKQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 25 Nov 2008 07:28:43.0734 (UTC) FILETIME=[722A4760:01C94ECF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1883; t=1227598124; x=1228462124; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Review=20of=20draft-ietf-isms-tmsm-15 |Sender:=20; bh=OoDd2zi3N3/7VaBhRvlAm4Mq7/jv8Q6NWoXHx9y4LF8=; b=a+ae211l3xUG9ech9Ym1vZbnzDa4d2EPUg3DcC04u+XsACdJdbxUB3N/I5 CM9ziHH6yCI7ygOFNiry2fT1GuYkbuvAMpKM5gx14o3/1nHRdxTQZB0bfQRr CoGF5bKRPn; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Isms] Review of draft-ietf-isms-tmsm-15 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I have review the transport subsystem document. I think the document is excellent. I have a few comments and questions below. I have not been able to keep up with the discussion so if I am bringing up old news let me know and I'll go back through the archives. 1. Denial of service Section 3.1 states "It is not required to protect against denial of service or traffic analysis, but it should not make those threats significantly worse." While I think this is a fine statement, I believe the DOS characteristics of some transport subsystems will be different than USM. There should be a section in the security considerations section that indicates that the DOS characteristics of various transports will vary and should be evaluated when determining the applicability to a particular deployment situation. 2. (editorial) Section 3.2.2.1 comma instead of period at end of paragraph 3. Security name Is it possible for the security name in 3.2.2.1 to be ambiguous. For example is it possible for a ":" to exist in a security name from another model? I think the answer is that this is the tmSecurityName so it always has the ":" form. Mapping to the securityName takes this into account. 4. 5.2.2. when is the tmSecurityName Different than the transport principal? 5. I had some trouble visualizing the flow of information in the ASIs. In particular I wasn't sure who was going to fill in the tmState fields. I think on an out going message the transport security model populates the cache and on an incoming message the transport model does. I think one can probably get this from the ASIs, but it might help to explicitly state this (if it is indeed accurate). 6. security considerations section should indicate that DOS characteristics of transport models may vary and deployments should consider this. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 25 06:26:16 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4BA28C17C; Tue, 25 Nov 2008 06:26:16 -0800 (PST) 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 1F68D28C17C for ; Tue, 25 Nov 2008 06:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.562, 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 8+bXCZvIlvhQ for ; Tue, 25 Nov 2008 06:26:14 -0800 (PST) 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 2523C28C156 for ; Tue, 25 Nov 2008 06:26:11 -0800 (PST) X-Trace: 110419295/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.37/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.37 X-IP-MAIL-FROM: cfinss@dial.pipex.com 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: As4EAOSZK0k+vGkl/2dsb2JhbACDUSkYiR/FLgeCdQ X-IronPort-AV: E=Sophos;i="4.33,664,1220223600"; d="scan'208";a="110419295" X-IP-Direction: IN Received: from 1cust37.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.37]) by smtp.pipex.tiscali.co.uk with SMTP; 25 Nov 2008 14:26:06 +0000 Message-ID: <000701c94f01$7bd9c240$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Juergen Schoenwaelder'" , References: <20081104081320.GA26802@elstar.local> <003e01c94e15$533c24a0$0601a8c0@allison> <00af01c94ead$cba18a00$0600a8c0@china.huawei.com> Date: Tue, 25 Nov 2008 14:26:11 +0100 MIME-Version: 1.0 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] wg last call on isms document set - tmStateReference 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Thanks for the comprehensive reply; I am splitting out 4) Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; "'Juergen Schoenwaelder'" ; Sent: Tuesday, November 25, 2008 4:27 AM Subject: RE: [Isms] wg last call on isms document set > > Let me respond with my view of the universe. > > > > > 4) is the tmStateReference updated with each message, as the > > recent text > > implies? or is it long term information about the session > > that remains > > invariant until the session is taken down? I had always > > assumed the latter and > > was surprised to see the former. > > Well, securityStateReference and tmStateReference are references. > securityStateReference references a specific securityState, and > tmStateReference references a particular tmState. It is > implementation-dependent how tmState and securityState and the > references to them are implemented (duh). > > The sessionID field that is contained in the tmState is used for one > and only one purpose - to match corresponding request and response > sessions to ensure sameSecurity. It is never used for any other > purpose. And it is opaque to the security model. > > The securityState includes a reference to a tmState. That > tmStateReference must reference the tmState that identifies the > session on which a request was received, so TSM can require the same > session be used when sending the associated response. It is > model-dependent (and possibly implementation-dependent) how the > transport model compares the sessionID value from a tmStateReference > and its notion of a current sessionID. > > In my view of the universe, this means, every time we receive a > request, the associated tmStateReference must point to a tmState that > accurately records the sessionID the incoming message was received on. > As long as there is a request/response transaction in-process, we > cannot change the securityState (or its Reference) or the tmState (or > its Reference) or the sessionID field contained in that tmState. That > is true even if we receive another request before the first response > is sent. > > If a session closes and another is opened while a request/response > transaction is in-process, we need to be able to look at the tmState > for the request and compare that to the current tmState to be used for > the response. If the security model REQUIRES sameSEcurity, and the > tmState for the request and the tmState for the response do not match, > then we MUST discard the message. > > Let's assume I keep my tmStates in an array, and each entry identifies > a specific long-lived session. (The sessionID might simply be the > array index.) > > Every time I receive a request, I pass a reference (or pointer) to the > appropriate array entry. But wait, there's more! Since the transport > model has no access to the PDU type, it doesn't know which messages > contain requests. Therefore it must pass a tmStateReference for each > received message, regardless of PDU, and the tmStateReference points > to the tmState for that incoming message. > > If two incoming messages use different sessions, the tmStateReference > associated with each message is set to point to the associated tmState > used for each message. (So in my implementation, the first > tmStateReference might be a pointer to tmState[1], and the second > tmStateReference might be a pointer to tmState[2].) > > If two incoming messages use the same session, the tmStateReference > associated with each message is set to point to the associated tmState > used for each message. (So in my implementation, the first > tmStateReference might be a pointer to tmState[1], and the second > tmStateReference might be a pointer to tmState[1] as well.) > > If the transport model gets on outgoing message with a > sameSecurity=true, then the transport model checks that the sessionID > for the transport session used to send the message matches the > sessionID in the tmState that is referenced by the tmStateReference. > Yes, all this I agree with (but it's good to know we are on the same page). My problem is then with tsm-10 s 4.2 Elements of Procedure for Outgoing Messages 2) which says "If there is no securityStateReference then create a tmStateReference cache ..." so 99 outgoing Request with the same securityName will create 99 cache entries, many - perhaps all - of which will have the same securityLevel, none of which, on the current text, will have a transportDomain/Address. This seems like a cache entry per message. The text used to be " 3) If there is no securityStateReference, then find or create an entry in a Local Configuration Datastore containing the provided transportDomain, transportAddress, securityName, securityLevel, and securityModel, and create a tmStateReference to reference the entry." which I always thought was ok (especially the reference to securityModel:-). I do not know why we changed it between tsm-5 and tsm-6. The only reference in the change log that might be apt is " Replaced tmSameSession with tmSameSecurity to eliminate session- matching from the security model." 'Eliminate session-matching' would appear to mean create a separate cache entry for each and every outbound message which does not have a securityStateReference, cache entries which the stm then has to map to its own 'these are not sessions' cache entries. So tmStateReference will point to a session entry for incoming messages and outgoing responses, but to a very incomplete message entry for outgoing messages. Is this what we want? If so, then I think that more words of explanation would be desirable, in all three I-Ds. > > > > Tom Petch > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 25 11:58:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443A13A6C35; Tue, 25 Nov 2008 11:58:34 -0800 (PST) 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 6D5F23A6C35 for ; Tue, 25 Nov 2008 11:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 m7utoqfiN1ZX for ; Tue, 25 Nov 2008 11:58:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A11E23A6874 for ; Tue, 25 Nov 2008 11:58:32 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4715C0040; Tue, 25 Nov 2008 20:58:29 +0100 (CET) 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 DBbKerwjejMw; Tue, 25 Nov 2008 20:58:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEE1DC0045; Tue, 25 Nov 2008 20:58:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C07C4883226; Tue, 25 Nov 2008 20:58:23 +0100 (CET) Date: Tue, 25 Nov 2008 20:58:23 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20081125195823.GA4291@elstar.local> Mail-Followup-To: "tom.petch" , isms@ietf.org References: <20081104081320.GA26802@elstar.local> <003e01c94e15$533c24a0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <003e01c94e15$533c24a0$0601a8c0@allison> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] wg last call on isms document set X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Mon, Nov 24, 2008 at 10:11:50AM +0100, tom.petch wrote: > The end date of the last call is past so where have I got to? We received some substantial reviews, which is good. > I suspect that some of the procedures described in the I-Ds do not > work but have difficulty in being sure on account of underlying > issues. Hopefully, these, at least in part, can be resolved fairly > quickly. This is what I hope as well. And it will surely help our editors if people can make concrete editing proposals such as replace "this text" with "some new text" plus a rationale for the suggested change. /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 isms-bounces@ietf.org Tue Nov 25 13:44:12 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E3128C1C3; Tue, 25 Nov 2008 13:44:12 -0800 (PST) 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 9F48928C1C6 for ; Tue, 25 Nov 2008 13:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 jjMHslIsMy72 for ; Tue, 25 Nov 2008 13:44:11 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E4F2C28C1C3 for ; Tue, 25 Nov 2008 13:44:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,666,1220227200"; d="scan'208";a="110105079" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Nov 2008 21:44:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mAPLi6rK023521 for ; Tue, 25 Nov 2008 13:44:06 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAPLi6KX023848 for ; Tue, 25 Nov 2008 21:44:06 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 13:44:06 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 13:44:05 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-isms-transport-security-model-10 Thread-Index: AclPRvCXI1wqrNFBQK6P4ckPBCD2eA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 25 Nov 2008 21:44:06.0640 (UTC) FILETIME=[F1003F00:01C94F46] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=966; t=1227649446; x=1228513446; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Review=20of=20draft-ietf-isms-transport-securit y-model-10 |Sender:=20; bh=V4KAomEEFy7aZ+gL+1csX1D2VF4UrrCBvODp1HJLOO8=; b=GkQyHiQlLL3FOccilFib7ugjbNUO6UKjfHRWaIKSi25rgB5bLST4s8x5i/ SsSJ+3idRPSQogq603bPhDhuPlaiQg4IW7wGieiBtYhAzjNw0lQXNgIJaA/Q s4btms/ykk; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Isms] Review of draft-ietf-isms-transport-security-model-10 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is also an excellent document. I have a few comments listed below: 1. Section 2 - This section is useful and explicitly stated some things I was looking for in the transport document about who generates the tmState is different cases. This section discusses what happens when the transport model does not fill in the tmState reference on an incoming message. It should also have a brief discussion of what happens if the security model does not fill in the tmState. It seems that this is possible since a secure transport can be used with a security model other than the transport security model. 2. It seems that section 3.3.3 conflicts with section 3.2.2.1 of TMSM. TMSM states that the tmSecurityName is constructed with a prefix and the security model states that the tmSecurityName does not have a prefix. I think it makes more sense if the tmSecurityName does not have the prefix, but the securiutyName may have the prefix. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 25 18:26:52 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472763A6C92; Tue, 25 Nov 2008 18:26:52 -0800 (PST) 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 86E303A6C92 for ; Tue, 25 Nov 2008 18:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.211, 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 2xBqKnLpYA-f for ; Tue, 25 Nov 2008 18:26:50 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C37333A6C91 for ; Tue, 25 Nov 2008 18:26:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,666,1220227200"; d="scan'208";a="201813087" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Nov 2008 02:26:48 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAQ2QmAJ020769 for ; Tue, 25 Nov 2008 18:26:48 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAQ2QisO004745 for ; Wed, 26 Nov 2008 02:26:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 18:26:43 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 18:26:43 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-isms-secshell-13 Thread-Index: AclPbmvBampcQNASQFavGy6hJ/5vfA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 26 Nov 2008 02:26:43.0934 (UTC) FILETIME=[6C55F7E0:01C94F6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1932; t=1227666408; x=1228530408; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Review=20of=20draft-ietf-isms-secshell-13=20 |Sender:=20; bh=pxam0rstAuO6thPzTjqMDzbkOK32altoN6lCCj0aweg=; b=GattNIYw1cq1ogcpQ7UqOh56xhwgbJScool5cMiQKdOKbbRQs6jyfPShQt 2D7Jr4KvHt86N4ZaG91q5HDPZs5wbn2ElV3ZcQearuZu/8+fnNagHsArzlf6 O1DCaJTox7; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Isms] Review of draft-ietf-isms-secshell-13 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Here are some review comments on draft-ietf-isms-secshell-13: 1. (editorial) 3.1.2 the first sentence in the third paragraph is a duplicate of one in the preceding paragraph. I suggest removing it. 2. 3.1.2 - In paragraph 2 I don't think we need the text after the first 2 sentences. This would better belong in a AAA document 3. 4.3.1 - In some cases the user name field of the SSH_MSG_USERAUTH_REQUEST may not be validated by the SSH server. In these cases it should not be relied upon as an authenticated identity. This section needs to take this into account. Here is some text for the second paragraph of the SSH server side of a connection: The SSH protocol is not always clear on whether the user name field must be filled in, so for some implementations, such as those using GSSAPI authentication, it may be necessary to use a mapping algorithm to transform a user name to a SSH identity compatible with the parameters required by this transport. In other cases the user name may not be verified by the server, so for these implementations, it may be necessary to obtain the user name from other credentials exchanged during the SSH exchange. How a compatible SSH identity is determined should be administratively configurable if such a mapping is needed. 4. in section 5.1 1, second paragraph should contain a pointer to the issues in 4.3.1 2, tmSecurityName shouldn't this just be "ssh principal name determined by the SSH server."? 5. Its not clear to me from the elements of procedure how access control is performed for a notification originator. On a notification originator when is access control performed, what principal name is used and where does it come from? I concerned that currently it will use a local principal instead of the remote principal which does not seem right. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 27 02:39:20 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584D93A6907; Thu, 27 Nov 2008 02:39:20 -0800 (PST) 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 EF8C43A6907 for ; Thu, 27 Nov 2008 02:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 L0fQERCKFDYg for ; Thu, 27 Nov 2008 02:39:19 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id BE53C3A67D1 for ; Thu, 27 Nov 2008 02:39:18 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mARAd5Ug013427 for ; Thu, 27 Nov 2008 12:39:13 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 12:38:55 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 12:38:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Nov 2008 12:38:54 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720264FE8A@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments for tmsm-15 and transport-security-model-10 Thread-Index: AclQfFhyK8btQ0RcR8Om+UbZq7fyHg== From: To: X-OriginalArrivalTime: 27 Nov 2008 10:38:54.0625 (UTC) FILETIME=[58699110:01C9507C] X-Nokia-AV: Clean Subject: [Isms] Comments for tmsm-15 and transport-security-model-10 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I know these comments are a bit late, but anyway... some suggestions for clarifications and editorial nits: transport-security-model-10: - Section 3: This section should say in the beginning that Sections 3...3.2.4. are duplicated from tmsm-15 Section 5 for convenience. (And add a note to the RFC Editor to keep the wording exactly the same in these documents.) - Appendix A: "sampleUser" is "our name for the recipient" (our==notification originator's), and that's used for VACM. Since it's quite unlikely (although not impossible) that this same string works as the SSH user name ("the recipient's/SSH server's name for us"), the example would be much easier to understand if it used the "user@address" syntax for transportAddress. Perhaps securityName "alice" and transportAddress "rtr-nyc4@192.0.2.1:PPP"? - Appendix A: should use IANA-assigned port for SSHTM instead of 162. - Appendix A: should "snmpTargetAddrTAddress" be marked with "*"? (since its contents are transport model specific) draft-ietf-isms-tmsm-15: - Section 1.3: expand acronym "ASI" when first mentioned - Section 3.2.2.1: The first two paragraphs read OK, but after that, the reader will be completely lost. We need some text introducing the concept of tmSecurityName, and explaining what it is, and its relationship to securityName. - Section 4: There's something very confusing in these two paragraphs. Would something like this be clearer? RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to illustrate how an outgoing message is created, and how an incoming message is processed. However, RFC3411 does not define ASIs for the "Send SNMP Request Message to Network", Receive SNMP Response Message from Network", "Receive SNMP Message from Network", or "Send SNMP message to Network" arrows in these diagrams. This document defines two ASIs corresponding to these arrows: a sendMessage ASI to send SNMP messages to the network, and a receiveMessage ASI to receive SNMP messages from the network. These ASIs are used for all SNMP messages, regardless of pduType. - Sections 5.2: perhaps add something like "The details of these fields are described in the following subsections." to the end? - Sections 5 and 7: the term "LCD" is mentioned only twice in the whole document, and neither reference explains what it is (or even expands the acronym). Could we just remove all references to LCD from this draft? - Section 8 references RFC2434, but it's been obsoleted by RFC 5226, and it's not listed as a normative reference. Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 27 03:07:08 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910E13A67F1; Thu, 27 Nov 2008 03:07:08 -0800 (PST) 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 839913A67F1 for ; Thu, 27 Nov 2008 03:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 nQkFRvhE8-9D for ; Thu, 27 Nov 2008 03:07:07 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id DB6963A67D1 for ; Thu, 27 Nov 2008 03:07:06 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mARB6e2p006784 for ; Thu, 27 Nov 2008 05:07:02 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 13:07:00 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 13:07:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Nov 2008 13:07:00 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720264FF14@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: One additional comment for transport-security-model-10 Thread-Index: AclQgEUTnp+QNan7Q8KJWtpODCZBVA== From: To: X-OriginalArrivalTime: 27 Nov 2008 11:07:00.0644 (UTC) FILETIME=[455BA640:01C95080] X-Nokia-AV: Clean Subject: [Isms] One additional comment for transport-security-model-10 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Section 4.2, step 1: it seems this step should also mention tmSessionID (extract tmSessionID from securityStateReference cache) Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 27 03:09:09 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD1C3A6B9F; Thu, 27 Nov 2008 03:09:09 -0800 (PST) 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 805723A6B9F for ; Thu, 27 Nov 2008 03:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 x5mFC0UdhTYl for ; Thu, 27 Nov 2008 03:09:07 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7864C3A6407 for ; Thu, 27 Nov 2008 03:09:07 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mARB8xwJ014101 for ; Thu, 27 Nov 2008 13:09:01 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 13:08:59 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 13:08:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Nov 2008 13:08:53 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720264FF19@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments about draft-ietf-isms-secshell-13 Thread-Index: AclQgIhsLdtLFjuQTjKtqkMjqYnlOw== From: To: X-OriginalArrivalTime: 27 Nov 2008 11:08:53.0867 (UTC) FILETIME=[88D81BB0:01C95080] X-Nokia-AV: Clean Subject: [Isms] Comments about draft-ietf-isms-secshell-13 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I have more comments about Section 5, but I'll send them in a separate email. - Section 3.1.2: there's some duplication of text (the sentence "The transport layer algorithms...") - Section 3.1.3, "DISCUSS: do we really need this paragraph?" Seems useful to me. - Section 4: Do we really need to duplicate this text in all three documents? May be do -- but we should say in the beginning that Sections 4 through 4.2.4 are duplicated from tmsm-15 Section 5 for convenience (And add a note to the RFC Editor to keep the wording exactly the same in all three documents.) - Section 4.3.1, "for which a SSH_MSG_USERAUTH_SUCCESS has been received" should be "for which ... has been sent" (also occurs in in Section 5.1) - Section 5.3: '"SNMP" as an SSH subsystem', should be in lowercase "snmp" (subsystem names are case-sensitive) - Secton 8, "two well-known ports" -- hmm, rest of the document seems to assume a single port? (including IANA considerations and several other places) - Section 8, last sentence: is this sentence recommending that we create a standard protocol for configuring SSH credentials? If yes, it needs some rephrasing... (since such protocol does not yet exist, recommending its use would be a bit strange -- but if that's the intention, some rephrasing is still needed) - Section 10, "snmp" is an SSH Subsystem Name, not an SSH Service Name (and yes, RFC 4742 got this wrong -- I'll look into filing an erratum and fixing the IANA registry). Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 27 03:57:17 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016D83A67D1; Thu, 27 Nov 2008 03:57:17 -0800 (PST) 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 976313A67D1 for ; Thu, 27 Nov 2008 03:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 Bjg2TTRs85u3 for ; Thu, 27 Nov 2008 03:57:14 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C3AE13A67B3 for ; Thu, 27 Nov 2008 03:57:14 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mARBushe021945 for ; Thu, 27 Nov 2008 05:57:10 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 13:56:57 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 13:56:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Nov 2008 13:56:55 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments about draft-ietf-isms-secshell-13, Section 5 Thread-Index: AclQhz6E3EeYK4jZSYmwNwYWd8X+9g== From: To: X-OriginalArrivalTime: 27 Nov 2008 11:56:57.0096 (UTC) FILETIME=[3F61F080:01C95087] X-Nokia-AV: Clean Subject: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Comments about draft-ietf-isms-secshell-13, Section 5: Overall: I think we're *almost* done -- I think we need to fill in some minor details, but those shouldn't affect the overall processing. - The distinction between tmStateReference cache and LCD is a bit unclear -- do these actually mean the same thing? For example, Section 5.3 talks about creating an LCD entry when the SSH client has established a connection (step 7), and Section 5.2 checks if the LCD entry exists (step 2). But there's no text saying that the SSH server ever creates any LCD entries -- so step 2 of Section 5.2 would always fail when e.g. sending command responses. That's clearly not the intention. Section 5.1 does talk about creating a tmStateReference cache -- perhaps it should talk about creating a LCD cache entry? Or perhaps Sections 5.2/5.3 should talk about tmStateReference cache? Or perhaps we need to describe opening a session also from SSH server's point of view? (Section 5.3 talks only about what the SSH client does, and says basically nothing about what the server does.) - Section 5.2 (step 2) says the LCD entry is indexed by (destTransportAddress,tmSecurityName) but 5.3 (step 7) says it's (destTransportAddress,tmStateReference). Probably the former is correct? (but in that case, there's no need to store tmSecurityName in the entry itself, so step 7 of 5.3 may need some editing) - Section 5.3, step 1: it would be *really* useful to add a note that to authenticate the server, the client usually stores (destTransportAddress, server host public key) pairs in implementation-dependent manner. (Otherwise, this text gets difficult to understand.) - Section 5.1: we shouldneed a better description of how tmSecurityName works on the SSH client side; IMHO the current behavior isn't quite right: Suppose a command generator sends a command with tmSecurityName="alice" and destTransportAddress="ahopkins@router1.example.net:1234". An SSH connection is opened and so on. When the command response is received, the current text in Section 5.1 would lead to having tmSecurityName="ahopkins" in the response -- a slightly unexpected response. Would it be better to extract the tmSecurityName from the "LCD cache entry" (or whatever is the right term) that was created when the client first established the session? - Section 5.1, on related note, on SSH client side, the tmTransportAddress in incoming messages should probably also be extracted from the "LCD cache entry", so that it's exactly the same as was used for the outgoing message (that triggered creating the SSH connection). - Section 5.1, we should say what the tmTransportAddress for incoming messages looks on the SSH server side: it's "address:port" form (not user@address:port). - Typos: Section 5.3, "tmSecurtityName" Section 5.4, "sever" Several sections (including the MIB): "sshtmSessionUnavaliableSubsystems" Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 28 06:25:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A2528C11C; Fri, 28 Nov 2008 06:25:25 -0800 (PST) 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 0976C28C11D for ; Fri, 28 Nov 2008 06:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 Jp20Zxbw1khM for ; Fri, 28 Nov 2008 06:25:23 -0800 (PST) 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 629DB28C0DB for ; Fri, 28 Nov 2008 06:25:18 -0800 (PST) X-Trace: 165986495/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.31 X-SBRS: None X-RemoteIP: 62.188.105.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAGGOL0k+vGkf/2dsb2JhbABEgwA4iRnEBAeCdg X-IronPort-AV: E=Sophos;i="4.33,682,1220223600"; d="scan'208";a="165986495" X-IP-Direction: IN Received: from 1cust31.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.31]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Nov 2008 14:25:12 +0000 Message-ID: <016001c9515c$d8bee500$0601a8c0@allison> From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , References: Date: Fri, 28 Nov 2008 12:09:04 +0100 MIME-Version: 1.0 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] Review of draft-ietf-isms-transport-security-model-10 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Joseph Salowey (jsalowey)" To: Sent: Tuesday, November 25, 2008 10:44 PM Subject: [Isms] Review of draft-ietf-isms-transport-security-model-10 > This is also an excellent document. I have a few comments listed below: > > 1. Section 2 - This section is useful and explicitly stated some things > I was looking for in the transport document about who generates the > tmState is different cases. This section discusses what happens when > the transport model does not fill in the tmState reference on an > incoming message. It should also have a brief discussion of what > happens if the security model does not fill in the tmState. It seems > that this is possible since a secure transport can be used with a > security model other than the transport security model. > > 2. It seems that section 3.3.3 conflicts with section 3.2.2.1 of TMSM. > TMSM states that the tmSecurityName is constructed with a prefix and the > security model states that the tmSecurityName does not have a prefix. I > think it makes more sense if the tmSecurityName does not have the > prefix, but the securiutyName may have the prefix. > tmsm says a prefix MUST exist but does not say MAY/SHOULD/MUST be used. s3.2.2.1 could be interpreted as saying that tmSecurityName includes the prefix but could also not eg where it says that the prefix will be prepended (not that it has been prepended) tsm 3.3.3 says the tmSecurityName does not include a prefix. tsm 4.2 2) says that the securityStateReference (ie this is a outgoing Response) stores the tmStateReference with the unprefixed tmSecurityName - the use of 'unprefixed' suggests to me that on other occasions tmSecurityName may be prefixed. tsm 4.2 2) a says strip the transport-specific prefix from the tmSecurityName (when snmpTsmConfigurationUsePrefix is true); the tmSecurityName has just been copied from the securityName so the prefix is presumably there temporarily tsm 5.2 3) says set the securityName to be the concatenation of the prefix and the tmSecurityName (when snmpTsmConfigurationUsePrefix is true) implying that tmSecurityName does not contain the prefix secshell defines the prefix character string and gives it an SNMP OID. So my current view is that using TSM, the tmSecurityName may include the prefix on a temporary basis; whether or not it will do so for other Security Models (VSM, WSM, XSM etc) will appear as and when they are defined. > _______________________________________________ > 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 isms-bounces@ietf.org Fri Nov 28 06:25:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A9728C135; Fri, 28 Nov 2008 06:25:25 -0800 (PST) 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 70B5C28C0DB for ; Fri, 28 Nov 2008 06:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 H8a0zXfX-vLh for ; Fri, 28 Nov 2008 06:25:23 -0800 (PST) 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 3BCA328C11C for ; Fri, 28 Nov 2008 06:25:21 -0800 (PST) X-Trace: 165986505/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.31 X-SBRS: None X-RemoteIP: 62.188.105.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAGGOL0k+vGkf/2dsb2JhbABEgwA4iRm4cAiLDAeBbgEIfw X-IronPort-AV: E=Sophos;i="4.33,682,1220223600"; d="scan'208";a="165986505" X-IP-Direction: IN Received: from 1cust31.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.31]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Nov 2008 14:25:14 +0000 Message-ID: <016101c9515c$d9991860$0601a8c0@allison> From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , References: Date: Fri, 28 Nov 2008 12:23:35 +0100 MIME-Version: 1.0 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] Review of draft-ietf-isms-tmsm-15 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Joseph Salowey (jsalowey)" To: Sent: Tuesday, November 25, 2008 8:28 AM Subject: [Isms] Review of draft-ietf-isms-tmsm-15 > I have review the transport subsystem document. I think the document is > excellent. I have a few comments and questions below. I have not been > able to keep up with the discussion so if I am bringing up old news let > me know and I'll go back through the archives. > > > 1. Denial of service > > Section 3.1 states "It is not required to protect against denial of > service or traffic analysis, but it should not make those threats > significantly worse." While I think this is a fine statement, I > believe the DOS characteristics of some transport subsystems will be > different than USM. There should be a section in the security > considerations section that indicates that the DOS characteristics of > various transports will vary and should be evaluated when determining > the applicability to a particular deployment situation. > > 2. (editorial) Section 3.2.2.1 comma instead of period at end of > paragraph > > 3. Security name > > Is it possible for the security name in 3.2.2.1 to be ambiguous. For > example is it possible for a ":" to exist in a security name from > another model? I think the answer is that this is the tmSecurityName so > it always has the ":" form. Mapping to the securityName takes this into > account. > > 4. 5.2.2. when is the tmSecurityName Different than the transport > principal? > When it needs to be:-) The idea of a mapping between the identity used in a secure transport and the identity in the securityName has been around a long time but the justification for it has varied. eg ssh has different restrictions on character set and length to SNMP and that might force a mapping. ssh users might be using one security domain and tls users another with different identities in each with a need for the identities to be mapped to a common identity for securityName purposes. SNMP as it stands has a securityName for a transaction, common to Notification Originator/Notification Receiver etc; ssh has distinct client and server identities so one might need mapping etc etc and this has then led to two or more identities - currently three - with various proposals for where mapping between them takes place. (My own personal view is that we MUST allow for a mapping and that this is only possible if it happens in the Transport Model but this is only a personal view). > 5. I had some trouble visualizing the flow of information in the ASIs. > In particular I wasn't sure who was going to fill in the tmState fields. > I think on an out going message the transport security model populates > the cache and on an incoming message the transport model does. I think > one can probably get this from the ASIs, but it might help to explicitly > state this (if it is indeed accurate). > > 6. security considerations section should indicate that DOS > characteristics of transport models may vary and deployments should > consider this. > > > > > > _______________________________________________ > 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 isms-bounces@ietf.org Fri Nov 28 06:25:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823F928C11D; Fri, 28 Nov 2008 06:25:26 -0800 (PST) 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 2D7AF28C134 for ; Fri, 28 Nov 2008 06:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.514, 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 YlyOQyf52IWC for ; Fri, 28 Nov 2008 06:25:24 -0800 (PST) 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 DB24828C11A for ; Fri, 28 Nov 2008 06:25:23 -0800 (PST) X-Trace: 165986510/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.31 X-SBRS: None X-RemoteIP: 62.188.105.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAGGOL0k+vGkf/2dsb2JhbACDRDiJGcQEB4J2 X-IronPort-AV: E=Sophos;i="4.33,682,1220223600"; d="scan'208";a="165986510" X-IP-Direction: IN Received: from 1cust31.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.31]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Nov 2008 14:25:15 +0000 Message-ID: <016201c9515c$da8414a0$0601a8c0@allison> From: "tom.petch" To: , References: <1696498986EFEC4D9153717DA325CB720264FF14@vaebe104.NOE.Nokia.com> Date: Fri, 28 Nov 2008 12:30:43 +0100 MIME-Version: 1.0 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] One additional comment for transport-security-model-10 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: To: Sent: Thursday, November 27, 2008 12:07 PM Subject: [Isms] One additional comment for transport-security-model-10 > > Section 4.2, step 1: it seems this step should also mention tmSessionID > (extract tmSessionID from securityStateReference cache) > I don't see this. tmSessionID is in the tmStateReference cache not in the securityStateReferenceCache. The pointer to the tmStateReference cache is passed to the Transport Model which will then extract the tmSessionID and check that a Response is going out over the session that the Request came in on (secshell 5.2 1.). But perhaps some text here is unclear and could be made clearer. Tom Petch > Best regards, > Pasi > _______________________________________________ > 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 isms-bounces@ietf.org Fri Nov 28 06:25:27 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B6F28C14D; Fri, 28 Nov 2008 06:25:27 -0800 (PST) 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 0336C28C11D for ; Fri, 28 Nov 2008 06:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.480, 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 mnny+8-mHZff for ; Fri, 28 Nov 2008 06:25:25 -0800 (PST) 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 B9F6C28C101 for ; Fri, 28 Nov 2008 06:25:24 -0800 (PST) X-Trace: 165986514/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.31 X-SBRS: None X-RemoteIP: 62.188.105.31 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAGGOL0k+vGkf/2dsb2JhbACDRDiJGcQEB4J2 X-IronPort-AV: E=Sophos;i="4.33,682,1220223600"; d="scan'208";a="165986514" X-IP-Direction: IN Received: from 1cust31.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.31]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Nov 2008 14:25:17 +0000 Message-ID: <016301c9515c$db3cb640$0601a8c0@allison> From: "tom.petch" To: , References: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> Date: Fri, 28 Nov 2008 14:22:56 +0100 MIME-Version: 1.0 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] Comments about draft-ietf-isms-secshell-13, Section 5 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On LCD, this is architected in RFC3411. The LCD is defined as sets of configuration information needed by models and applications (s3.4.2). The cache is introduced so that if the LCD is changed, then the same security information is still available for a Response as was used in the Request (s A.1.5). So no, the (securityStateReference at least) cache is quite separate from the LCD. tmsm likens the tmStateReference to the existing RFC3411 cache so by implication, it too should be distinct from the LCD. Tom Petch ----- Original Message ----- From: To: Sent: Thursday, November 27, 2008 12:56 PM Subject: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 > Comments about draft-ietf-isms-secshell-13, Section 5: > > Overall: I think we're *almost* done -- I think we need to fill in > some minor details, but those shouldn't affect the overall processing. > > - The distinction between tmStateReference cache and LCD is a bit > unclear -- do these actually mean the same thing? For example, Section > 5.3 talks about creating an LCD entry when the SSH client has > established a connection (step 7), and Section 5.2 checks if the LCD > entry exists (step 2). > > But there's no text saying that the SSH server ever creates any LCD > entries -- so step 2 of Section 5.2 would always fail when > e.g. sending command responses. That's clearly not the intention. > Section 5.1 does talk about creating a tmStateReference cache -- > perhaps it should talk about creating a LCD cache entry? Or perhaps > Sections 5.2/5.3 should talk about tmStateReference cache? Or perhaps > we need to describe opening a session also from SSH server's point > of view? (Section 5.3 talks only about what the SSH client does, and > says basically nothing about what the server does.) > > - Section 5.2 (step 2) says the LCD entry is indexed by > (destTransportAddress,tmSecurityName) but 5.3 (step 7) says it's > (destTransportAddress,tmStateReference). Probably the former is > correct? (but in that case, there's no need to store tmSecurityName > in the entry itself, so step 7 of 5.3 may need some editing) > > - Section 5.3, step 1: it would be *really* useful to add a note > that to authenticate the server, the client usually stores > (destTransportAddress, server host public key) pairs in > implementation-dependent manner. (Otherwise, this text gets difficult > to understand.) > > - Section 5.1: we shouldneed a better description of how tmSecurityName > works on the SSH client side; IMHO the current behavior isn't quite > right: Suppose a command generator sends a command with > tmSecurityName="alice" and > destTransportAddress="ahopkins@router1.example.net:1234". An SSH > connection is opened and so on. When the command response is received, > the current text in Section 5.1 would lead to having > tmSecurityName="ahopkins" in the response -- a slightly unexpected > response. Would it be better to extract the tmSecurityName from the > "LCD cache entry" (or whatever is the right term) that was created > when the client first established the session? > > - Section 5.1, on related note, on SSH client side, the > tmTransportAddress in incoming messages should probably also be > extracted from the "LCD cache entry", so that it's exactly the same as > was used for the outgoing message (that triggered creating the SSH > connection). > > - Section 5.1, we should say what the tmTransportAddress for incoming > messages looks on the SSH server side: it's "address:port" form (not > user@address:port). > > - Typos: > Section 5.3, "tmSecurtityName" > Section 5.4, "sever" > Several sections (including the MIB): "sshtmSessionUnavaliableSubsystems" > > Best regards, > Pasi > _______________________________________________ > 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 isms-bounces@ietf.org Fri Nov 28 09:12:09 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5123A67A7; Fri, 28 Nov 2008 09:12:09 -0800 (PST) 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 8417C3A67A7 for ; Fri, 28 Nov 2008 09:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 lrqeRgj-OOXW for ; Fri, 28 Nov 2008 09:12:07 -0800 (PST) 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 9699D3A676A for ; Fri, 28 Nov 2008 09:12:07 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA06.westchester.pa.mail.comcast.net with comcast id keBQ1a02o0ldTLk56hC4YN; Fri, 28 Nov 2008 17:12:04 +0000 Received: from Harrington73653 ([24.128.19.107]) by OMTA04.westchester.pa.mail.comcast.net with comcast id khC31a0092Jcr883QhC4YN; Fri, 28 Nov 2008 17:12:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=AdVAIaQyNmsA:10 a=eGl-4UIgrvoA:10 a=09VIjgw7GXwR0hnBbjQA:9 a=23mn3QOpm8DQnMkNav0K1galce4A:4 a=gJcimI5xSWUA:10 From: "David Harrington" To: , References: <1696498986EFEC4D9153717DA325CB720264FF19@vaebe104.NOE.Nokia.com> Date: Fri, 28 Nov 2008 12:12:02 -0500 Message-ID: <00c001c9517c$6f0edf50$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1696498986EFEC4D9153717DA325CB720264FF19@vaebe104.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclQgIhsLdtLFjuQTjKtqkMjqYnlOwA8rL5w Subject: Re: [Isms] Comments about draft-ietf-isms-secshell-13 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > - Section 4: Do we really need to duplicate this text in all three > documents? May be do -- but we should say in the beginning that > Sections 4 through 4.2.4 are duplicated from tmsm-15 Section 5 for > convenience (And add a note to the RFC Editor to keep the wording > exactly the same in all three documents.) Hi, I think this change has been confusing to most readers. I recommend having this text only in tmsm, and then having the others docs reference the text just prior to explaining the document-specific cache differences. dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 28 09:35:53 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F3C3A692B; Fri, 28 Nov 2008 09:35:53 -0800 (PST) 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 35B6B3A692B for ; Fri, 28 Nov 2008 09:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.630, 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 UXN0HxiFX9gS for ; Fri, 28 Nov 2008 09:35:51 -0800 (PST) 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 30E243A67AB for ; Fri, 28 Nov 2008 09:35:51 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA03.westchester.pa.mail.comcast.net with comcast id kbxs1a0020EZKEL53haZ4V; Fri, 28 Nov 2008 17:34:33 +0000 Received: from Harrington73653 ([24.128.19.107]) by OMTA01.westchester.pa.mail.comcast.net with comcast id khbm1a00W2Jcr883Mhbn9t; Fri, 28 Nov 2008 17:35:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=MEVWz2V25cYA:10 a=pq20RfjYIhAA:10 a=48vgC7mUAAAA:8 a=39Pwwl5DAyeZrf8Z3JYA:9 a=APJ9Aovmo1gJRHyuMlYA:7 a=AfPJC_YeB-esKcu3BjwDp5Nzt1sA:4 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , "'Joseph Salowey \(jsalowey\)'" , References: <016001c9515c$d8bee500$0601a8c0@allison> Date: Fri, 28 Nov 2008 12:35:46 -0500 Message-ID: <015801c9517f$bf6bcfa0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <016001c9515c$d8bee500$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclRZSa5yEoQ5lgLRiqQUwAq11Lx9gAGljzQ Subject: Re: [Isms] Review of draft-ietf-isms-transport-security-model-10 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, with the exception of the temporary state Tom mentioned, the tmSecurityName does not include the prefix. It is added by TSM when defining securityName on input, and removed by TSM when received from an application. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Friday, November 28, 2008 6:09 AM > To: Joseph Salowey (jsalowey); isms@ietf.org > Subject: Re: [Isms] Review of > draft-ietf-isms-transport-security-model-10 > > > > Tom Petch > > ----- Original Message ----- > From: "Joseph Salowey (jsalowey)" > To: > Sent: Tuesday, November 25, 2008 10:44 PM > Subject: [Isms] Review of draft-ietf-isms-transport-security-model-10 > > > > This is also an excellent document. I have a few comments > listed below: > > > > 1. Section 2 - This section is useful and explicitly stated > some things > > I was looking for in the transport document about who generates the > > tmState is different cases. This section discusses what > happens when > > the transport model does not fill in the tmState reference on an > > incoming message. It should also have a brief discussion of what > > happens if the security model does not fill in the tmState. > It seems > > that this is possible since a secure transport can be used with a > > security model other than the transport security model. > > > > 2. It seems that section 3.3.3 conflicts with section > 3.2.2.1 of TMSM. > > TMSM states that the tmSecurityName is constructed with a > prefix and the > > security model states that the tmSecurityName does not have > a prefix. I > > think it makes more sense if the tmSecurityName does not have the > > prefix, but the securiutyName may have the prefix. > > > tmsm says a prefix MUST exist but does not say > MAY/SHOULD/MUST be used. > s3.2.2.1 could be interpreted as saying that tmSecurityName > includes the prefix > but could also not eg where it says that the prefix will be > prepended (not that > it has been prepended) > > tsm 3.3.3 says the tmSecurityName does not include a prefix. > > tsm 4.2 2) says that the securityStateReference (ie this is a > outgoing Response) > stores the tmStateReference with the unprefixed > tmSecurityName - the use of > 'unprefixed' suggests to me that on other occasions > tmSecurityName may be > prefixed. > > tsm 4.2 2) a says strip the transport-specific prefix from > the tmSecurityName > (when snmpTsmConfigurationUsePrefix is true); the > tmSecurityName has just been > copied from the securityName so the prefix is presumably > there temporarily > > tsm 5.2 3) says set the securityName to be the concatenation > of the prefix and > the tmSecurityName (when snmpTsmConfigurationUsePrefix is > true) implying that > tmSecurityName does not contain the prefix > > secshell defines the prefix character string and gives it an SNMP OID. > > So my current view is that using TSM, the tmSecurityName may > include the prefix > on a temporary basis; whether or not it will do so for other > Security Models > (VSM, WSM, XSM etc) will appear as and when they are defined. > > > _______________________________________________ > > 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 > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 28 11:36:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA2C3A6939; Fri, 28 Nov 2008 11:36:36 -0800 (PST) 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 87CA93A6939 for ; Fri, 28 Nov 2008 11:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=-0.355, 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 0uHvdefGr0LH for ; Fri, 28 Nov 2008 11:36:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AF5933A6937 for ; Fri, 28 Nov 2008 11:36:34 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A3F8C00BB; Fri, 28 Nov 2008 20:36:31 +0100 (CET) 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 R4ml9rSpbgtD; Fri, 28 Nov 2008 20:36:26 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7C00C00B2; Fri, 28 Nov 2008 20:36:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B22A38870DC; Fri, 28 Nov 2008 20:36:24 +0100 (CET) Date: Fri, 28 Nov 2008 20:36:24 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20081128193624.GB10857@elstar.local> Mail-Followup-To: "tom.petch" , "Joseph Salowey (jsalowey)" , isms@ietf.org References: <016001c9515c$d8bee500$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <016001c9515c$d8bee500$0601a8c0@allison> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] Review of draft-ietf-isms-transport-security-model-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Fri, Nov 28, 2008 at 12:09:04PM +0100, tom.petch wrote: > secshell defines the prefix character string and gives it an SNMP OID. The text says: The securityName prefix to be associated with the snmpSSHDomain is 'ssh'. The fact that this text appears in the snmpSSHDomain definition is not relevant for the prefix value; the OID is assigned to the snmpSSHDomain not to the prefix. /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 isms-bounces@ietf.org Sat Nov 29 10:22:55 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF943A6B68; Sat, 29 Nov 2008 10:22:55 -0800 (PST) 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 AFD123A6B68 for ; Sat, 29 Nov 2008 10:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 eQOVq1utNMyj for ; Sat, 29 Nov 2008 10:22:54 -0800 (PST) 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 B37E83A6943 for ; Sat, 29 Nov 2008 10:22:53 -0800 (PST) X-Trace: 200471674/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.206/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.206 X-IP-MAIL-FROM: cfinss@dial.pipex.com 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: ApwEAI8XMUk+vGTO/2dsb2JhbACDRIlRwFYHgnY X-IronPort-AV: E=Sophos;i="4.33,687,1220223600"; d="scan'208";a="200471674" X-IP-Direction: IN Received: from 1cust206.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.206]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Nov 2008 18:22:47 +0000 Message-ID: <008401c95247$32defd00$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Joseph Salowey \(jsalowey\)'" , References: <015801c9517f$bf6bcfa0$0600a8c0@china.huawei.com> Date: Sat, 29 Nov 2008 13:55:33 +0100 MIME-Version: 1.0 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] Review of draft-ietf-isms-transport-security-model-10 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "David Harrington" Sent: Friday, November 28, 2008 6:35 PM Subject: RE: [Isms] Review of draft-ietf-isms-transport-security-model-10 > with the exception of the temporary state Tom mentioned, the > tmSecurityName does not include the prefix. It is added by TSM when > defining securityName on input, and removed by TSM when received from > an application. > So, following Joe's original comment, should we amend the text in tmsm s.3.2.2.1? Not easy, because adding the prefix in TSM is still optional and a discussion of that seems like a Model issue to me, not an architectural one. Currently Documents defining a new transport domain MUST define a prefix that will be prepended to all passed tmSecurityNames. The prefix MUST include from one to four ASCII characters, not including a ":" (ASCII 0x3a) character. A tmSecurityName 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". it might become Documents defining a new transport domain MUST define a prefix that MAY be prepended to a tmSecurityName when converted by a Security Model to a securityName. The prefix MUST include from one to four ASCII characters, not including a ":" (ASCII 0x3a) character. The conversion is performed 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"[RFCXXXX]. -- NOTE to RFC editor: replace XXXX with actual RFC number -- for this document and remove this note [I prefer the singular object name tmSecurityName to a false plural] [my comment about ASCII characters still applies - I would like it restricted, eg to printable ASCII] Tom Petch ps David, everytime I send you a message, Comcast tells me it's BL004 Blocked for spam:-( > dbh > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of tom.petch > > Sent: Friday, November 28, 2008 6:09 AM > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Nov 30 22:18:11 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728E728C142; Sun, 30 Nov 2008 22:18:11 -0800 (PST) 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 DB26228C142 for ; Sun, 30 Nov 2008 22:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 0kG7Y-vNAQkO for ; Sun, 30 Nov 2008 22:18:09 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1A7F128C127 for ; Sun, 30 Nov 2008 22:18:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,693,1220227200"; d="scan'208";a="204078269" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Dec 2008 06:18:05 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB16I5sM026813; Sun, 30 Nov 2008 22:18:05 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id mB16I5O8027890; Mon, 1 Dec 2008 06:18:05 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 22:18:05 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Nov 2008 22:18:03 -0800 Message-ID: In-Reply-To: <016101c9515c$d9991860$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Review of draft-ietf-isms-tmsm-15 Thread-Index: AclRZTVTYIZpe3gaTba+p/T+qHQY2wCFlRYg References: <016101c9515c$d9991860$0601a8c0@allison> From: "Joseph Salowey (jsalowey)" To: "tom.petch" , X-OriginalArrivalTime: 01 Dec 2008 06:18:05.0241 (UTC) FILETIME=[924E1290:01C9537C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2302; t=1228112285; x=1228976285; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Isms]=20Review=20of=20draft-ietf-isms- tmsm-15 |Sender:=20; bh=5gCrxIstWnfQ/f4FICReiLAzTyOGUL820+Ie4gL9Rdk=; b=RjLX9AJc5aLDy2GCzUi/U5ZlS6+9MlAmmhgdoNN2MKgGXj45Sz0QUzczSV 71fFBZBD6K0z6efETZsS2uDbvzjOrGDmrp+h/wP9Aw2EHTvPhXsTT0W7aP90 aPzCP9jBpanJLoldKMpy44LCy1PA6YcGR/1yMmdf1K02mZodukjOM=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Isms] Review of draft-ietf-isms-tmsm-15 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > > 4. 5.2.2. when is the tmSecurityName Different than the transport > > principal? > > > When it needs to be:-) > > The idea of a mapping between the identity used in a secure > transport and the identity in the securityName has been > around a long time but the justification for it has varied. > > eg > ssh has different restrictions on character set and length to > SNMP and that might force a mapping. > > ssh users might be using one security domain and tls users > another with different identities in each with a need for the > identities to be mapped to a common identity for securityName > purposes. > > SNMP as it stands has a securityName for a transaction, > common to Notification Originator/Notification Receiver etc; > ssh has distinct client and server identities so one might > need mapping > > etc etc > [Joe] I had trouble reading the text first time through. I definitely thing there needs to be allowance for a mapping between the transport name for the principal and the securityName. > and this has then led to two or more identities - currently > three - with various proposals for where mapping between them > takes place. > [Joe] I think I understand the three identities now. > (My own personal view is that we MUST allow for a mapping and > that this is only possible if it happens in the Transport > Model but this is only a personal view). > > > 5. I had some trouble visualizing the flow of information > in the ASIs. > > In particular I wasn't sure who was going to fill in the > tmState fields. > > I think on an out going message the transport security > model populates > > the cache and on an incoming message the transport model does. I > > think one can probably get this from the ASIs, but it might help to > > explicitly state this (if it is indeed accurate). > > > > 6. security considerations section should indicate that DOS > > characteristics of transport models may vary and deployments should > > consider this. > > > > > > > > > > > > _______________________________________________ > > 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