From cfinss@dial.pipex.com Sun Mar 1 05:09:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE9028C35A for ; Sun, 1 Mar 2009 05:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=-0.315, 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 A6RcB8lh7NcN for ; Sun, 1 Mar 2009 05:09:29 -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 27EC528C307 for ; Sun, 1 Mar 2009 05:02:54 -0800 (PST) X-Trace: 190283921/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.102/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.102 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: Ap4EAFQWqkk+vBNm/2dsb2JhbACDK4pYyGwHglSBPwY X-IronPort-AV: E=Sophos;i="4.38,284,1233532800"; d="scan'208";a="190283921" X-IP-Direction: IN Received: from 1cust102.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.102]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Mar 2009 13:03:12 +0000 Message-ID: <002501c99a65$80a15180$0601a8c0@allison> From: "tom.petch" To: , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> Date: Sun, 1 Mar 2009 12:45:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] wg last call followup - sshtm openSession X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 13:09:38 -0000 Not sure if this is editorial, I suspect not. sshtm openSession used to be openSession( IN destTransportAddress -- transport address to be used IN tmSecurityName -- on behalf of this principal IN maxMessageSize -- of the sending SNMP entity ) and is now openSession( IN tmStateReference -- transport information to be used OUT tmStateReference -- transport information to be used IN maxMessageSize -- of the sending SNMP entity ) Why the change? That OUT parameter looks strange to me. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Thursday, February 26, 2009 8:53 AM Subject: [Isms] wg last call followup > On November 4th 2008, I started WG last call on the ISMS document set: > > [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 > > > We received some comments and the subsequent mailing list discussions > have led to some changes to the ISMS core documents. David just posted > revised IDs of the core documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > [2] Transport Security Model for SNMP > > [3] Secure Shell Transport Model for SNMP > From cfinss@dial.pipex.com Sun Mar 1 05:09:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F5328E388 for ; Sun, 1 Mar 2009 05:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=1.008, 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 H3RT2wf6ItUU for ; Sun, 1 Mar 2009 05:09:32 -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 B6EA728C243 for ; Sun, 1 Mar 2009 05:03:02 -0800 (PST) X-Trace: 190283932/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.102/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.102 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: Ap4EAFQWqkk+vBNm/2dsb2JhbACDK4pYyGwHglSBPwY X-IronPort-AV: E=Sophos;i="4.38,284,1233532800"; d="scan'208";a="190283932" X-IP-Direction: IN Received: from 1cust102.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.102]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Mar 2009 13:03:21 +0000 Message-ID: <002601c99a65$858aa480$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> Date: Sun, 1 Mar 2009 12:58:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 13:09:41 -0000 This is probably not editorial but I cannot tell. I commented during the last round time how hard I find it to understand parts of these I-Ds and a concrete example of this is the e-mail address format we now have for transportAddress. Assume I read all of RFC341x, then tmsm, tsm and sshtm and am almost at the end of my journey of discovery and then I encounter " (If the session was not opened locally with a user@example.com formatted tmTransportAddress, ..." Hang on, what have I missed? Re-read all the foregoing and I am none the wiser; this is indeed the first reference. Why have e-mail format addresses? What function do they serve? Reverse engineer the ASI and EOP and I am fairly sure that they do not work, or more likely I cannot understand the relevant text. I thought this when Wes proposed wording for it last month; I waited for the complete I-Ds before I tried again but am still none the wiser. I have read every post on this list for years ... but that helps me none. The nearest is Jeff saying that this overcomes an asymmetry in SSH. Well, yes, I track SSH and understand its asymmetry; and am none the wiser:-( What I think essential is an expanatory paragraph, much earlier, in tmsm even (thinking that another transport model might find a use for this) saying eg "The transportAddress, as passed by the application may take the form user@example.com:port The 'user' part may be used to establish a transport and then be used by the remote engine as securityName. The local engine still uses securityName as well and so has two names, one of which is used somewhere and the other elsewhere making this specification hard to understand, dysfunctional even. This capability meets no known requirement but there is a good reason for it being present". Well, you might find a better pair of the last two sentences but after expending so much effort, I am a tad frustrated at my lack of understanding:-). I really would like to understand why we introduced this and how it works. My current focus is on a Command Generator as ssh client and the processing of outbound Request and inbound Response; forget about Command Responders and Notification engines for the moment. Wes? Jeff? Dave? Dave? Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Thursday, February 26, 2009 8:53 AM Subject: [Isms] wg last call followup > On November 4th 2008, I started WG last call on the ISMS document set: > > [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 > > > We received some comments and the subsequent mailing list discussions > have led to some changes to the ISMS core documents. David just posted > revised IDs of the core documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > [2] Transport Security Model for SNMP > > [3] Secure Shell Transport Model for SNMP > > > Please take a look at the changes. Let us know by March 6th if there > are any major technical problems with the changes that must be fixed > before submitting the documents to the AD for publication. Please > keep in mind that we are going for Proposed Standard, the entry-level > maturity level for the standards track. > > If you find editorial issues, please report them clearly marked as > editorial issues. > > /js From jhutz@cmu.edu Sun Mar 1 05:28:07 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6092A28C1DF for ; Sun, 1 Mar 2009 05:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbL8X+Oe9Qfh for ; Sun, 1 Mar 2009 05:28:06 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id A419C28C456 for ; Sun, 1 Mar 2009 05:19:46 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (70-5-93-108.pools.spcsdns.net [70.5.93.108]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n21DK4qA008221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 08:20:06 -0500 (EST) Date: Sun, 01 Mar 2009 08:20:04 -0500 From: Jeffrey Hutzelman To: "tom.petch" , Juergen Schoenwaelder , isms@ietf.org Message-ID: <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> In-Reply-To: <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 13:28:07 -0000 --On Saturday, February 28, 2009 08:45:09 PM +0100 "tom.petch" wrote: > I am still struggling with the 'Pasi problem' that he raised last > November and although I recall seeing a message from him that he was > satisfied, I cannot understand how it works in the current I-Ds; I cannot > understand part of the I-Ds so tell me first what is meant to happen. > > Suppose securityName is alice and transport address is bob@example.com:ssh > in a Command Generator. > > For a Request, sshtm passes bob to SSH and that is used for the session > setup as per s5.3 3 1. The Command Responder uses bob for access control > etc. The response will come back, SSH will pass a name of bob (s5.1 2) > to stm as a securityName via tmStateReference which will pass it on to > tsm which may or may not prefix it (s5.2 3) and then it will get passed > to the application. > > So the application specified alice and got back bob. > > Is this how it is meant to work? That won't happen. In your scenario, the CR does not "use bob for access control". TSM compares the name reported by SSH (bob) with the securityName in the SNMP message, and when they don't match, rejects the request. -- Jeff From jhutz@cmu.edu Sun Mar 1 05:35:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7413A68A8 for ; Sun, 1 Mar 2009 05:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0euyM7jA4Hyr for ; Sun, 1 Mar 2009 05:35:44 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 977153A6842 for ; Sun, 1 Mar 2009 05:35:44 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (70-5-93-108.pools.spcsdns.net [70.5.93.108]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n21DZhVi008339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 08:35:44 -0500 (EST) Date: Sun, 01 Mar 2009 08:35:42 -0500 From: Jeffrey Hutzelman To: "tom.petch" , Juergen Schoenwaelder , isms@ietf.org Message-ID: <790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu> In-Reply-To: <200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu> References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 13:35:45 -0000 --On Sunday, March 01, 2009 12:58:40 PM +0100 "tom.petch" wrote: > What I think essential is an expanatory paragraph, much earlier, in tmsm > even (thinking that another transport model might find a use for this) > saying eg > > "The transportAddress, as passed by the application may take the form > user@example.com:port > The 'user' part may be used to establish a transport and then be used by > the remote engine as securityName. The local engine still uses > securityName as well and so has two names, one of which is used somewhere > and the other elsewhere making this specification hard to understand, > dysfunctional even. This capability meets no known requirement but there > is a good reason for it being present". Well, we're not going to have a paragraph like that, because it takes totally the wrong tone. The feature is present because it _does_ need a requirement and is needed. But yes, there should be a paragraph describing the transport address format; I'm surprised if that's not in there. > Well, you might find a better pair of the last two sentences but after > expending so much effort, I am a tad frustrated at my lack of > understanding:-). I really would like to understand why we introduced > this and how it works. My current focus is on a Command Generator as ssh > client and the processing of outbound Request and inbound Response; > forget about Command Responders and Notification engines for the moment. Then you're not going to understand, because it's not intended for that use case. It's specfically for the case of a Notification Originator as an SSH client, where the SNMP securityName names the recipient of the notification, not the originator. In this case, using the securityName as the SSH username is almost certainly the _wrong_ thing to do, and the user@host transport address format provides a way to specify the correct username (which in fact likely has nothing to do with any other identity that SNMP knows about). -- Jeff From ietfdbh@comcast.net Sun Mar 1 05:59:26 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6043A6AC4 for ; Sun, 1 Mar 2009 05:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 HjB49z-g0iYI for ; Sun, 1 Mar 2009 05:59:25 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 88F873A6A62 for ; Sun, 1 Mar 2009 05:58:00 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Mpht1b0020vyq2s57pySfB; Sun, 01 Mar 2009 13:58:26 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id MpyR1b00K0UQ6dC3RpyRnX; Sun, 01 Mar 2009 13:58:26 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" , "'Juergen Schoenwaelder'" , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> Date: Sun, 1 Mar 2009 08:58:24 -0500 Message-ID: <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmacfUM823aYyMKRO+duJA1/5rZfQAAxvBw Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 13:59:26 -0000 Whoa!!!!!! There is NO securityName in the message. Where do you think the message contains a securityname? IN 4.2, TSM 3) Set securityParameters to a zero-length OCTET STRING ('0400'). dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Jeffrey Hutzelman > Sent: Sunday, March 01, 2009 8:20 AM > To: tom.petch; Juergen Schoenwaelder; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] wg last call followup - sshtm > [...] > > > > So the application specified alice and got back bob. > > > > Is this how it is meant to work? > > That won't happen. In your scenario, the CR does not "use > bob for access > control". TSM compares the name reported by SSH (bob) with the > securityName in the SNMP message, and when they don't match, > rejects the > request. > > -- Jeff > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From jhutz@cmu.edu Sun Mar 1 06:04:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9063A68EF for ; Sun, 1 Mar 2009 06:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aIFbjrMJw8o for ; Sun, 1 Mar 2009 06:04:16 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id A2D8D3A68A8 for ; Sun, 1 Mar 2009 06:04:16 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (70-5-93-108.pools.spcsdns.net [70.5.93.108]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n21E4Xjm008634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 09:04:34 -0500 (EST) Date: Sun, 01 Mar 2009 09:04:33 -0500 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" , "'Juergen Schoenwaelder'" , isms@ietf.org Message-ID: <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> In-Reply-To: <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 14:04:17 -0000 --On Sunday, March 01, 2009 08:58:24 AM -0500 David Harrington wrote: > Whoa!!!!!! > > There is NO securityName in the message. > Where do you think the message contains a securityname? > > IN 4.2, TSM > 3) Set securityParameters to a zero-length OCTET STRING ('0400'). OK; I haven't had much sleep, so maybe my memory is wrong, and I certainly need to go back and re-read the draft. But, I think it is essential to actually transport the security name and level in the SNMP message, and for TSM to verify that they are the saem. Otherwise, among other things, you can run into the situation Tom describes, where the two ends disagree on what the securityName is. -- Jeff From ietfdbh@comcast.net Sun Mar 1 06:29:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16FD3A693B for ; Sun, 1 Mar 2009 06:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 MyVfSUiz8acH for ; Sun, 1 Mar 2009 06:29:44 -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 6D29C3A6809 for ; Sun, 1 Mar 2009 06:29:42 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA01.westchester.pa.mail.comcast.net with comcast id MqVR1b00b0ldTLk51qW8uz; Sun, 01 Mar 2009 14:30:08 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA04.westchester.pa.mail.comcast.net with comcast id MqW71b00Q0UQ6dC3QqW73c; Sun, 01 Mar 2009 14:30:08 +0000 From: "David Harrington" To: References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu> <790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu> Date: Sun, 1 Mar 2009 09:30:06 -0500 Message-ID: <0fcb01c99a7a$37c64c80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmacrDNFk7PrubcRXmz6zYqAnmAIwABCg/A Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 14:29:45 -0000 H Jeff, I am finding some inaccuracies in your statements. Please check the drafts before making statements, please, so we do not get off into the weeds. inline. > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Jeffrey Hutzelman > Sent: Sunday, March 01, 2009 8:36 AM > To: tom.petch; Juergen Schoenwaelder; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] wg last call followup - e-mail address > > --On Sunday, March 01, 2009 12:58:40 PM +0100 "tom.petch" > wrote: > > > What I think essential is an expanatory paragraph, much > earlier, agreed. The definition of the format is in the MIB. An exlanatory paragraph earlier would be helpful. I didn't realize we didn't have it discussed adequately. > in tmsm > > even (thinking that another transport model might find a > use for this) this is specific to SnmpSSHDomain and SnmpSSHAddress The only transport model that should process SnmpSSHDomain is the SSHTM. > > Well, we're not going to have a paragraph like that, because it takes > totally the wrong tone. The feature is present because it > _does_ need a > requirement and is needed. But yes, there should be a > paragraph describing > the transport address format; I'm surprised if that's not in there. If you had looked, you would have found it in the MIB. > Then you're not going to understand, because it's not > intended for that use > case. It's specfically for the case of a Notification > Originator as an SSH > client, where the SNMP securityName names the recipient of the > notification, not the originator. I think that is a misstatement. Per RFC3411 modularity, any application should be able to use that format of domain/address. A CG could use this format just as well as a NO can. The proxy application defined in RFC3413 should be able to use this format just as well as a NO. > In this case, using the > securityName as > the SSH username is almost certainly the _wrong_ thing to do, and the > user@host transport address format provides a way to specify > the correct > username (which in fact likely has nothing to do with any > other identity > that SNMP knows about). > > -- Jeff > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From jhutz@cmu.edu Sun Mar 1 06:48:03 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFAA3A69A7 for ; Sun, 1 Mar 2009 06:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 elD4ECAkPzsn for ; Sun, 1 Mar 2009 06:48:02 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 5FE6B3A6939 for ; Sun, 1 Mar 2009 06:48:02 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (70-5-93-108.pools.spcsdns.net [70.5.93.108]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n21EmNhD009005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 09:48:24 -0500 (EST) Date: Sun, 01 Mar 2009 09:48:22 -0500 From: Jeffrey Hutzelman To: David Harrington , isms@ietf.org Message-ID: <009C7BF23F5B9C5373B3C6C1@atlantis.pc.cs.cmu.edu> In-Reply-To: <200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu> References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu> <790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu> <200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 14:48:03 -0000 --On Sunday, March 01, 2009 09:30:06 AM -0500 David Harrington wrote: >> Well, we're not going to have a paragraph like that, because it > takes >> totally the wrong tone. The feature is present because it >> _does_ need a >> requirement and is needed. But yes, there should be a >> paragraph describing >> the transport address format; I'm surprised if that's not in there. > > If you had looked, you would have found it in the MIB. Hrm. I didn't look, only because I figured Tom had, and if he couldn't find it, then perhaps we haven't said it prominently enough. >> Then you're not going to understand, because it's not >> intended for that use >> case. It's specfically for the case of a Notification >> Originator as an SSH >> client, where the SNMP securityName names the recipient of the >> notification, not the originator. > > I think that is a misstatement. Per RFC3411 modularity, any > application should be able to use that format of domain/address. A CG > could use this format just as well as a NO can. The proxy application > defined in RFC3413 should be able to use this format just as well as a > NO. It's _intended_ for the case I described, where deriving the SSH username from the SNMP securityName is likely to produce the wrong answer. In the case of a CG, deriving the SSH username from the SNMP securityName probably will produce the correct answer, so the user@host address format is much less likely to be used by a CG. But you're right; that doesn't mean it _can't_ be used by a CG. Nonetheless, I think my previous statement is true -- an NO is the use case for the user@host address format, so it's difficult to understand why it is useful without considering that case. -- Jeff From ietfdbh@comcast.net Sun Mar 1 06:58:30 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684D93A67F5 for ; Sun, 1 Mar 2009 06:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=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 5DgPTSdFVeTx for ; Sun, 1 Mar 2009 06:58:29 -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 4F6753A6878 for ; Sun, 1 Mar 2009 06:58:29 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Mqyp1b00L0QuhwU58qyulf; Sun, 01 Mar 2009 14:58:54 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id Mqyu1b00i0UQ6dC3Nqyuwl; Sun, 01 Mar 2009 14:58:54 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" , "'Juergen Schoenwaelder'" , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> Date: Sun, 1 Mar 2009 09:58:53 -0500 Message-ID: <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmadqkQ10yOcQpcQxCtBwAv12EfegAA0ewg Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 14:58:30 -0000 Hi, > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Sunday, March 01, 2009 9:05 AM > To: David Harrington; 'tom.petch'; 'Juergen Schoenwaelder'; > isms@ietf.org > Cc: jhutz@cmu.edu > Subject: RE: [Isms] wg last call followup - sshtm > > --On Sunday, March 01, 2009 08:58:24 AM -0500 David Harrington > wrote: > > > Whoa!!!!!! > > > > There is NO securityName in the message. > > Where do you think the message contains a securityname? > > > > IN 4.2, TSM > > 3) Set securityParameters to a zero-length OCTET STRING ('0400'). > > > OK; I haven't had much sleep, so maybe my memory is wrong, > and I certainly > need to go back and re-read the draft. But, I think it is > essential to > actually transport the security name and level in the SNMP > message, and for > TSM to verify that they are the saem. The securityLevel and securityModel are transported in the message, and the specified securityModel will (presumably, but definitely in the case of USM and TSM) verify the securityLevel is at least as strong as specified in the message. securityName, on the other hand, is a security-model-dependent parameter, and only exist sin the message if the sending TSM includes it in the message, and presumably the incoming TSM processes it. For USM, it is included because USM authenticates that securityname. In TSM, it is not included because TSM relies on the transport model to provide a proposed securityname in the tmSecurityName. TSM does not validate the tmSecurityName at all; it accepts it as being the securityName for subsequent use for access control for the associated incoming message. For SSH, the two sides do not have to agree on the same securityName. The principal known as alice in snmp entity#1 might be known as bob in snmp entity#2. The securityname is a local construct. I don't think that was the intenrtion of the SNMPv3 WG, but the asymmetric nature of SSH has forced it to be so, and the RFC34xx do not seem to require that it be so (despite my expectations). Basically, if the MIB information being sent in a message is from a local MIB, then verify that the local securityName is allowed to send the data. There are three current applications that send data from the local MIB - 1) NO - the securityName used for access control is a prinsipal known tot he local system, via the NOTIFY-MIB, for example. ACM verifies that the local principal is allowed to send data off the box. It does not matter to whom it is being sent; either they are allowed to send the data or not. 2) CR - the securityName used for ACM is based on the principal that was authenticated during the receipt of the message. If bob@example.com was authneticated by SSHTM, and SSHTM sets tmSecurityName to "bob" as a result (or to fred, or to barney, or to router@192.168.0.1), then the value passed by SSHTM in tmSecurityName becomes securityName, and ACM uses that securityName. 3) proxy - I have not checked this thoroughly, but the information passed to the proxy application for an incoming message should be the same as what would be passed to a CR for an incoming message. The information used for an outgoing message comes from the the proxy-mib (and associated mibs) just like in the NO case. In some instances, the same tabl;es are used for transportdomain/address and security parameters as the NO use case. The proxy use case is important if, say, SNMPv1 security model is used within an enterprise network, but USM is used to send SNMP data over the Internet. The router that separates the enterpise network form the Internet might act as the proxy. Proxy could be used if the enterprise network used USM security model, and SSHTM+TSM was used to forward SNMP messages over the Internet. > Otherwise, among other > things, you > can run into the situation Tom describes, where the two ends > disagree on > what the securityName is. > > -- Jeff > From jhutz@cmu.edu Sun Mar 1 08:25:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17C93A693D for ; Sun, 1 Mar 2009 08:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hXXVLLs7l8o for ; Sun, 1 Mar 2009 08:25:41 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 138433A68F6 for ; Sun, 1 Mar 2009 08:25:40 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (70-5-93-108.pools.spcsdns.net [70.5.93.108]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n21GPrB6010095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 11:25:54 -0500 (EST) Date: Sun, 01 Mar 2009 11:25:52 -0500 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" , "'Juergen Schoenwaelder'" , isms@ietf.org Message-ID: In-Reply-To: <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 16:25:42 -0000 --On Sunday, March 01, 2009 09:58:53 AM -0500 David Harrington wrote: > The securityLevel and securityModel are transported in the message... > securityName, on the other hand, is a security-model-dependent... > For SSH, the two sides do not have to agree on the same securityName... I'm still short on sleep, but this sounds sane to me, and I'm fairly convinced there is not a problem -- as long as we believe it's OK that the two parties to a transation might not use the same securityName. -- Jeff From cfinss@dial.pipex.com Sun Mar 1 13:05:50 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFE63A68BA for ; Sun, 1 Mar 2009 13:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.940, 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 qBXz8cr0GnIf for ; Sun, 1 Mar 2009 13:05:49 -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 3DDC13A6784 for ; Sun, 1 Mar 2009 13:05:49 -0800 (PST) X-Trace: 136152832/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.58/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.58 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-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: ArUEAA+Hqkk+vBM6/2dsb2JhbACDLIpYuTgHjSQHhBMGhj4 X-IronPort-AV: E=Sophos;i="4.38,285,1233532800"; d="scan'208";a="136152832" X-IP-Direction: IN Received: from 1cust58.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.58]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Mar 2009 21:06:09 +0000 Message-ID: <003d01c99aa8$f5e6d9e0$0601a8c0@allison> From: "tom.petch" To: "Jeffrey Hutzelman" , "David Harrington" , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu><790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu><200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu> <009C7BF23F5B9C5373B3C6C1@atlantis.pc.cs.cmu.edu> Date: Sun, 1 Mar 2009 21:04:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 21:05:50 -0000 ----- Original Message ----- From: "Jeffrey Hutzelman" To: "David Harrington" ; Cc: Sent: Sunday, March 01, 2009 3:48 PM Subject: Re: [Isms] wg last call followup - e-mail address > --On Sunday, March 01, 2009 09:30:06 AM -0500 David Harrington > wrote: > > >> Well, we're not going to have a paragraph like that, because it > > takes > >> totally the wrong tone. The feature is present because it > >> _does_ need a > >> requirement and is needed. But yes, there should be a > >> paragraph describing > >> the transport address format; I'm surprised if that's not in there. > > > > If you had looked, you would have found it in the MIB. > > Hrm. I didn't look, only because I figured Tom had, and if he couldn't > find it, then perhaps we haven't said it prominently enough. > > > >> Then you're not going to understand, because it's not > >> intended for that use > >> case. It's specfically for the case of a Notification > >> Originator as an SSH > >> client, where the SNMP securityName names the recipient of the > >> notification, not the originator. > > > > I think that is a misstatement. Per RFC3411 modularity, any > > application should be able to use that format of domain/address. A CG > > could use this format just as well as a NO can. The proxy application > > defined in RFC3413 should be able to use this format just as well as a > > NO. > > It's _intended_ for the case I described, where deriving the SSH username > from the SNMP securityName is likely to produce the wrong answer. In the > case of a CG, deriving the SSH username from the SNMP securityName probably > will produce the correct answer, so the user@host address format is much > less likely to be used by a CG. But you're right; that doesn't mean it > _can't_ be used by a CG. > > Nonetheless, I think my previous statement is true -- an NO is the use case > for the user@host address format, so it's difficult to understand why it is > useful without considering that case. > Jeff I am sorry if you found my facetiousness offensive. It has been over three years for me, trying to make sense of the mappings, and being convinced with each successive I-D that either it will not work or I cannot understand it or ... My point was not that there is not some more information about e-mail format addresses, but that the text I quote is the first anyone will ever hear about it if they read the SNMPv3 documents in a sensible order. And as an introduction, that sentence is dire (IMO). The later sentences flesh out the format, the implementation detail if you like, but there is no statement anywhere of why this complication is introduced especially as this feature brings fresh problems, as all the mappings we have had have done. In particular, it creates the 'Pasi problem', Command Generator sends a Request with securityName of Alice, gets a Reponse with securityName of Bob. Pasi described it as surprising. I say unacceptable. And that is why I specified this scenario in my other post. By all means explain that it solves an NO problem - well I think that that is essential - but if the solution leads to unacceptable results with CR/CG, then our job is not done. I say that a paragraph is needed saying what the problem is with NO and how this solves it ie requirements and design, to me the foundation of my practice as an engineer. Tom Petch > -- Jeff > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From cfinss@dial.pipex.com Sun Mar 1 13:05:51 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D15F3A6784 for ; Sun, 1 Mar 2009 13:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=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 fTV7M6pYq0jp for ; Sun, 1 Mar 2009 13:05:50 -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 E7C143A6880 for ; Sun, 1 Mar 2009 13:05:49 -0800 (PST) X-Trace: 136152835/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.58/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.58 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-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: ArUEAA+Hqkk+vBM6/2dsb2JhbACDLIpYxmMHhBMGhj4 X-IronPort-AV: E=Sophos;i="4.38,285,1233532800"; d="scan'208";a="136152835" X-IP-Direction: IN Received: from 1cust58.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.58]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Mar 2009 21:06:11 +0000 Message-ID: <003e01c99aa8$f70bd1e0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Jeffrey Hutzelman'" , "'Juergen Schoenwaelder'" , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> Date: Sun, 1 Mar 2009 21:04:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 21:05:51 -0000 ----- Original Message ----- From: "David Harrington" To: "'Jeffrey Hutzelman'" ; "'tom.petch'" ; "'Juergen Schoenwaelder'" ; Sent: Sunday, March 01, 2009 3:58 PM Subject: RE: [Isms] wg last call followup - sshtm > Hi, > > > > -----Original Message----- > > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > > Sent: Sunday, March 01, 2009 9:05 AM > > To: David Harrington; 'tom.petch'; 'Juergen Schoenwaelder'; > > isms@ietf.org > > Cc: jhutz@cmu.edu > > Subject: RE: [Isms] wg last call followup - sshtm > > > > --On Sunday, March 01, 2009 08:58:24 AM -0500 David Harrington > > wrote: > > > > > Whoa!!!!!! > > > > > > There is NO securityName in the message. > > > Where do you think the message contains a securityname? > > > > > > IN 4.2, TSM > > > 3) Set securityParameters to a zero-length OCTET STRING > ('0400'). > > > > > > OK; I haven't had much sleep, so maybe my memory is wrong, > > and I certainly > > need to go back and re-read the draft. But, I think it is > > essential to > > actually transport the security name and level in the SNMP > > message, and for > > TSM to verify that they are the saem. > > The securityLevel and securityModel are transported in the message, > and the specified securityModel will (presumably, but definitely in > the case of USM and TSM) verify the securityLevel is at least as > strong as specified in the message. > > securityName, on the other hand, is a security-model-dependent > parameter, and only exist sin the message if the sending TSM includes > it in the message, and presumably the incoming TSM processes it. For > USM, it is included because USM authenticates that securityname. In > TSM, it is not included because TSM relies on the transport model to > provide a proposed securityname in the tmSecurityName. TSM does not > validate the tmSecurityName at all; it accepts it as being the > securityName for subsequent use for access control for the associated > incoming message. > > For SSH, the two sides do not have to agree on the same securityName. > The principal known as alice in snmp entity#1 might be known as bob in > snmp entity#2. The securityname is a local construct. I don't think > that was the intenrtion of the SNMPv3 WG, but the asymmetric nature of > SSH has forced it to be so, and the RFC34xx do not seem to require > that it be so (despite my expectations). > > Basically, if the MIB information being sent in a message is from a > local MIB, then verify that the local securityName is allowed to send > the data. There are three current applications that send data from the > local MIB - > > 1) NO - the securityName used for access control is a prinsipal known > tot he local system, via the NOTIFY-MIB, for example. ACM verifies > that the local principal is allowed to send data off the box. It does > not matter to whom it is being sent; either they are allowed to send > the data or not. > > 2) CR - the securityName used for ACM is based on the principal that > was authenticated during the receipt of the message. If > bob@example.com was authneticated by SSHTM, and SSHTM sets > tmSecurityName to "bob" as a result (or to fred, or to barney, or to > router@192.168.0.1), then the value passed by SSHTM in tmSecurityName > becomes securityName, and ACM uses that securityName. > > 3) proxy - I have not checked this thoroughly, but the information > passed to the proxy application for an incoming message should be the > same as what would be passed to a CR for an incoming message. The > information used for an outgoing message comes from the the proxy-mib > (and associated mibs) just like in the NO case. In some instances, the > same tabl;es are used for transportdomain/address and security > parameters as the NO use case. > > The proxy use case is important if, say, SNMPv1 security model is used > within an enterprise network, but USM is used to send SNMP data over > the Internet. The router that separates the enterpise network form the > Internet might act as the proxy. Proxy could be used if the enterprise > network used USM security model, and SSHTM+TSM was used to forward > SNMP messages over the Internet. > David I agree but my concern is the one Pasi expressed, that in the Command Generator, the application will send a Request with securityName of alice and the Response within the Command Generator (forget CR, that I do not have a problem with) will have a securityName of bob. Pasi called it surprising, I would suggest unacceptable, and in need either of preventing or of warning people of the consequences. And I think we also need a warning that the two engines can have different views of securityName, I think that that is not something to be expected from the RFC341x series. Tom Petch > > > Otherwise, among other > > things, you > > can run into the situation Tom describes, where the two ends > > disagree on > > what the securityName is. > > > > -- Jeff > > > From ietfdbh@comcast.net Sun Mar 1 18:16:43 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D3728C10E for ; Sun, 1 Mar 2009 18:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=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 ul1KVzq0yinV for ; Sun, 1 Mar 2009 18:16:42 -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 B30B63A6952 for ; Sun, 1 Mar 2009 18:16:41 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA01.westchester.pa.mail.comcast.net with comcast id MxZS1b03Q0QuhwU512H8kt; Mon, 02 Mar 2009 02:17:08 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id N2H71b0040UQ6dC3N2H7Y3; Mon, 02 Mar 2009 02:17:07 +0000 From: "David Harrington" To: "'tom.petch'" , "'Jeffrey Hutzelman'" , "'Juergen Schoenwaelder'" , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <003e01c99aa8$f70bd1e0$0601a8c0@allison> Date: Sun, 1 Mar 2009 21:17:06 -0500 Message-ID: <101a01c99adc$fc63eea0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <003e01c99aa8$f70bd1e0$0601a8c0@allison> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmasY/YK8Wxi6nnT8i1dqNPC13LYgAKdh2Q Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 02:16:43 -0000 Hi, I have the same concerns. I feel very uneasy about this. I think that the way to resolve it is to have sshtm record the SnmpSSHAddress and the tmSecurityName for outgoing messages, and match them up to incoming messages. If the principal identity matches the user part of an SnmpSSHAddress in email format, and that is different than the tmSecurityName used with that transport adddress for the outgoing message, then use the tmSecurityName that was used for the corresponding outgoing message. If we send the message to "bob@remote.org", then I presume the response will come back from "bob" at remote.com's address. However, we might have used a domain address (remote.org) on the outgoing, I am not sure whether we get a response from remote.org or from <10.1.9.34> (an address that remote.org resolves to). I have documented the elemts of procedure as well as I can given my current understanding. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Sunday, March 01, 2009 3:05 PM > To: David Harrington; 'Jeffrey Hutzelman'; 'Juergen > Schoenwaelder'; isms@ietf.org > Subject: Re: [Isms] wg last call followup - sshtm > > ----- Original Message ----- > From: "David Harrington" > To: "'Jeffrey Hutzelman'" ; "'tom.petch'" > ; "'Juergen Schoenwaelder'" > ; > Sent: Sunday, March 01, 2009 3:58 PM > Subject: RE: [Isms] wg last call followup - sshtm > > > > Hi, > > > > > > > -----Original Message----- > > > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > > > Sent: Sunday, March 01, 2009 9:05 AM > > > To: David Harrington; 'tom.petch'; 'Juergen Schoenwaelder'; > > > isms@ietf.org > > > Cc: jhutz@cmu.edu > > > Subject: RE: [Isms] wg last call followup - sshtm > > > > > > --On Sunday, March 01, 2009 08:58:24 AM -0500 David Harrington > > > wrote: > > > > > > > Whoa!!!!!! > > > > > > > > There is NO securityName in the message. > > > > Where do you think the message contains a securityname? > > > > > > > > IN 4.2, TSM > > > > 3) Set securityParameters to a zero-length OCTET STRING > > ('0400'). > > > > > > > > > OK; I haven't had much sleep, so maybe my memory is wrong, > > > and I certainly > > > need to go back and re-read the draft. But, I think it is > > > essential to > > > actually transport the security name and level in the SNMP > > > message, and for > > > TSM to verify that they are the saem. > > > > The securityLevel and securityModel are transported in the message, > > and the specified securityModel will (presumably, but definitely in > > the case of USM and TSM) verify the securityLevel is at least as > > strong as specified in the message. > > > > securityName, on the other hand, is a security-model-dependent > > parameter, and only exist sin the message if the sending > TSM includes > > it in the message, and presumably the incoming TSM processes it. For > > USM, it is included because USM authenticates that securityname. In > > TSM, it is not included because TSM relies on the transport model to > > provide a proposed securityname in the tmSecurityName. TSM does not > > validate the tmSecurityName at all; it accepts it as being the > > securityName for subsequent use for access control for the > associated > > incoming message. > > > > For SSH, the two sides do not have to agree on the same > securityName. > > The principal known as alice in snmp entity#1 might be > known as bob in > > snmp entity#2. The securityname is a local construct. I don't think > > that was the intenrtion of the SNMPv3 WG, but the > asymmetric nature of > > SSH has forced it to be so, and the RFC34xx do not seem to require > > that it be so (despite my expectations). > > > > Basically, if the MIB information being sent in a message is from a > > local MIB, then verify that the local securityName is > allowed to send > > the data. There are three current applications that send > data from the > > local MIB - > > > > 1) NO - the securityName used for access control is a > prinsipal known > > tot he local system, via the NOTIFY-MIB, for example. ACM verifies > > that the local principal is allowed to send data off the > box. It does > > not matter to whom it is being sent; either they are allowed to send > > the data or not. > > > > 2) CR - the securityName used for ACM is based on the principal that > > was authenticated during the receipt of the message. If > > bob@example.com was authneticated by SSHTM, and SSHTM sets > > tmSecurityName to "bob" as a result (or to fred, or to barney, or to > > router@192.168.0.1), then the value passed by SSHTM in > tmSecurityName > > becomes securityName, and ACM uses that securityName. > > > > 3) proxy - I have not checked this thoroughly, but the information > > passed to the proxy application for an incoming message > should be the > > same as what would be passed to a CR for an incoming message. The > > information used for an outgoing message comes from the the > proxy-mib > > (and associated mibs) just like in the NO case. In some > instances, the > > same tabl;es are used for transportdomain/address and security > > parameters as the NO use case. > > > > The proxy use case is important if, say, SNMPv1 security > model is used > > within an enterprise network, but USM is used to send SNMP data over > > the Internet. The router that separates the enterpise > network form the > > Internet might act as the proxy. Proxy could be used if the > enterprise > > network used USM security model, and SSHTM+TSM was used to forward > > SNMP messages over the Internet. > > > > David > > I agree but my concern is the one Pasi expressed, that in the > Command Generator, > the application will send a Request with securityName of > alice and the Response > within the Command Generator (forget CR, that I do not have a > problem with) will > have a securityName of bob. Pasi called it surprising, I > would suggest > unacceptable, and in need either of preventing or of warning > people of the > consequences. > > And I think we also need a warning that the two engines can > have different views > of securityName, I think that that is not something to be > expected from the > RFC341x series. > > Tom Petch > > > > > > > Otherwise, among other > > > things, you > > > can run into the situation Tom describes, where the two ends > > > disagree on > > > what the securityName is. > > > > > > -- Jeff > > > > > > > From jhutz@cmu.edu Mon Mar 2 10:25:42 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF2D28C271 for ; Mon, 2 Mar 2009 10:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 BLV21g10rFze for ; Mon, 2 Mar 2009 10:25:41 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id C20BC28C228 for ; Mon, 2 Mar 2009 10:25:41 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n22IPUX2008651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 13:25:30 -0500 (EST) Date: Mon, 02 Mar 2009 13:25:30 -0500 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" , "'Juergen Schoenwaelder'" , isms@ietf.org Message-ID: In-Reply-To: <200903020217.n222HDpd017530@grapenut.srv.cs.cmu.edu> References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <003e01c99aa8$f70bd1e0$0601a8c0@allison> <200903020217.n222HDpd017530@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:25:43 -0000 --On Sunday, March 01, 2009 09:17:06 PM -0500 David Harrington wrote: > Hi, > > I have the same concerns. I feel very uneasy about this. > > I think that the way to resolve it is to have sshtm record the > SnmpSSHAddress and the tmSecurityName for outgoing messages, and match > them up to incoming messages. If the principal identity matches the > user part of an SnmpSSHAddress in email format, and that is different > than the tmSecurityName used with that transport adddress for the > outgoing message, then use the tmSecurityName that was used for the > corresponding outgoing message. > > If we send the message to "bob@remote.org", then I presume the > response will come back from "bob" at remote.com's address. NONONO. If we send the message to "bob@remote.org", then we are sending the message to the host remote.org, and using "bob" as _our_ SSH username for use in authenticating to that host. It is _not_ an email address, and "bob" is not the name of the agent we're sending to. It is the name the agent we're sending to (actually, the SSH server we're connecting to) uses to describe _us_. If we send a message... ... the response will come back _over the same ssh session_. Period. We don't get a response back from a particular IP address or hostname or user. We get a response back over the channel _we_ opened. This is exactly what tmSameSecurity is fore. From ietfdbh@comcast.net Mon Mar 2 11:32:23 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396143A6C35 for ; Mon, 2 Mar 2009 11:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 0hZoTA2svhWW for ; Mon, 2 Mar 2009 11:32:22 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 2E32C3A6836 for ; Mon, 2 Mar 2009 11:32:22 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA04.westchester.pa.mail.comcast.net with comcast id NDPH1b0080Fqzac54KYpSV; Mon, 02 Mar 2009 19:32:49 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA08.westchester.pa.mail.comcast.net with comcast id NKZu1b00G0UQ6dC3UKZud4; Mon, 02 Mar 2009 19:33:54 +0000 From: "David Harrington" To: References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <003e01c99aa8$f70bd1e0$0601a8c0@allison> <200903020217.n222HDpd017530@grapenut.srv.cs.cmu.edu> Date: Mon, 2 Mar 2009 14:32:47 -0500 Message-ID: <11b201c99b6d$aaf95fa0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmbZEctfvC2aA2/S7uLFtw1KBSWdQACS4SA Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:32:23 -0000 Alright, let me write up some introductory text that describes this. IIRC, I think I already edited the EOP to reflect this, based on Wes's comments. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Monday, March 02, 2009 1:26 PM > To: David Harrington; 'tom.petch'; 'Juergen Schoenwaelder'; > isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] wg last call followup - sshtm > > --On Sunday, March 01, 2009 09:17:06 PM -0500 David Harrington > wrote: > > > Hi, > > > > I have the same concerns. I feel very uneasy about this. > > > > I think that the way to resolve it is to have sshtm record the > > SnmpSSHAddress and the tmSecurityName for outgoing > messages, and match > > them up to incoming messages. If the principal identity matches the > > user part of an SnmpSSHAddress in email format, and that is > different > > than the tmSecurityName used with that transport adddress for the > > outgoing message, then use the tmSecurityName that was used for the > > corresponding outgoing message. > > > > If we send the message to "bob@remote.org", then I presume the > > response will come back from "bob" at remote.com's address. > > NONONO. If we send the message to "bob@remote.org", then we > are sending > the message to the host remote.org, and using "bob" as _our_ > SSH username > for use in authenticating to that host. It is _not_ an email > address, and > "bob" is not the name of the agent we're sending to. It is > the name the > agent we're sending to (actually, the SSH server we're > connecting to) uses > to describe _us_. > > If we send a message... > > ... the response will come back _over the same ssh session_. Period. > We don't get a response back from a particular IP address or > hostname or > user. We get a response back over the channel _we_ opened. This is > exactly what tmSameSecurity is fore. > From wjhns1@hardakers.net Mon Mar 2 11:48:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C733A694D for ; Mon, 2 Mar 2009 11:48:41 -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.111, 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 jo-iT8weTkIW for ; Mon, 2 Mar 2009 11:48:40 -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 4436F3A6ABC for ; Mon, 2 Mar 2009 11:48:03 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id C86BC399B44; Mon, 2 Mar 2009 11:48:28 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <003e01c99aa8$f70bd1e0$0601a8c0@allison> <200903020217.n222HDpd017530@grapenut.srv.cs.cmu.edu> Date: Mon, 02 Mar 2009 11:48:28 -0800 In-Reply-To: (Jeffrey Hutzelman's message of "Mon, 02 Mar 2009 13:25:30 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:48:41 -0000 >>>>> On Mon, 02 Mar 2009 13:25:30 -0500, Jeffrey Hutzelman said: This is the important part that everyone needs to understand. I'm sort of confused why we're rehashing stuff that was long ago discussed and even agreed upon (I thought by a fairly big majority of the people!). JH> ... the response will come back _over the same ssh session_. Period. JH> We don't get a response back from a particular IP address or hostname JH> or user. We get a response back over the channel _we_ opened. This JH> is exactly what tmSameSecurity is fore. Stream based transports like SSH or even DTLS (which is defining a cryptographic stream, even if it's not a packet based stream like a TCP stream) performs things in an order: 1) start up the stream, sharing and negotiating information like certificates, names, passwords, options, etc. Alice <---- ----> Bob The result of this negotiation is almost always some sort of "handle" and in most implementations is a file-descriptor socket at the heart of it all (IE, an integer number identifying the stream to the kernel/what-have-you). 2) Send traffic through the stream. It's important to note that pretty much every protocol *does not send the user name /etc again*. It'd be highly redundant to keep sending messages saying "oh, and this is from Bob again". The stream user on one side is expected to know that already (regardless of whether they initiated or accepted the connection). 3) close the connection upon request For the SSHTM we just recently added wording (I thought; I have yet to check the new draft) that basically says that the tmSecurityName needs to be cached/consistent during the life of a session. That way when Alice sends a first message with a securityName of "alice" but that says "open bob@foo.com" where bob@ is the SshTransportAddress convention, alice's stack remembers that "alice" is the security name for the lifetime of the session on our end. When it gets *any* messages from the other side, it passes up "alice" as the tmSecurityName in the upward-bound traveling tmStateReference. If alice didn't want it this way and actually wanted "bob" to be securityName, she would have set the initial tmStateRerence's tmSecurityName correctly. It'd be *her* fault for not tying them together. -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Mon Mar 2 11:49:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FE23A69AD for ; Mon, 2 Mar 2009 11:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.097, 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 Y6pzxxUKia4F for ; Mon, 2 Mar 2009 11:49:17 -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 74E0B3A694D for ; Mon, 2 Mar 2009 11:49:17 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D3334399BA4; Mon, 2 Mar 2009 11:49:43 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <003e01c99aa8$f70bd1e0$0601a8c0@allison> <101a01c99adc$fc63eea0$0600a8c0@china.huawei.com> Date: Mon, 02 Mar 2009 11:49:43 -0800 In-Reply-To: <101a01c99adc$fc63eea0$0600a8c0@china.huawei.com> (David Harrington's message of "Sun, 1 Mar 2009 21:17:06 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:49:18 -0000 >>>>> On Sun, 1 Mar 2009 21:17:06 -0500, "David Harrington" said: DH> I think that the way to resolve it is to have sshtm record the DH> SnmpSSHAddress and the tmSecurityName for outgoing messages, and match DH> them up to incoming messages. I don't think you need to cache the address. And I thought a recent patch had required we cache the securityName (I forcefully say this is the DTLS draft). -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Mon Mar 2 11:49:51 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D35F3A6ABC for ; Mon, 2 Mar 2009 11:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.086, 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 ko7WZUs9AiLm for ; Mon, 2 Mar 2009 11:49:51 -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 AD8A63A69AD for ; Mon, 2 Mar 2009 11:49:50 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 16454399BA4; Mon, 2 Mar 2009 11:50:17 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> Date: Mon, 02 Mar 2009 11:50:17 -0800 In-Reply-To: (Jeffrey Hutzelman's message of "Sun, 01 Mar 2009 11:25:52 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:49:51 -0000 >>>>> On Sun, 01 Mar 2009 11:25:52 -0500, Jeffrey Hutzelman said: JH> I'm still short on sleep, but this sounds sane to me, and I'm fairly JH> convinced there is not a problem -- as long as we believe it's OK that JH> the two parties to a transation might not use the same securityName. Which, I'll say again: we already agreed upon as a WG that it was OK. -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Mon Mar 2 11:55:25 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FAA93A6ABC for ; Mon, 2 Mar 2009 11:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.078, 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 cS+Stl2mbalO for ; Mon, 2 Mar 2009 11:55:24 -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 65DD03A694D for ; Mon, 2 Mar 2009 11:55:24 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 93679399B44; Mon, 2 Mar 2009 11:55:50 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu> <790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu> <200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu> <009C7BF23F5B9C5373B3C6C1@atlantis.pc.cs.cmu.edu> <003d01c99aa8$f5e6d9e0$0601a8c0@allison> Date: Mon, 02 Mar 2009 11:55:50 -0800 In-Reply-To: <003d01c99aa8$f5e6d9e0$0601a8c0@allison> (tom petch's message of "Sun, 1 Mar 2009 21:04:05 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:55:25 -0000 >>>>> On Sun, 1 Mar 2009 21:04:05 +0100, "tom.petch" said: tp> In particular, it creates the 'Pasi problem', Command Generator tp> sends a Request with securityName of Alice, gets a Reponse with tp> securityName of Bob. No! That never happens. A CG that opens a request with a securityName of "Alice" but a transport address of "bob@example.com" will get back a securityName of "Alice", ***NOT*** Bob. -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Mon Mar 2 12:14:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84113A6901 for ; Mon, 2 Mar 2009 12:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, TVD_PH_SUBJ_META=0] 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 gP5Midg09dcB for ; Mon, 2 Mar 2009 12:14:17 -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 CF1083A6882 for ; Mon, 2 Mar 2009 12:14:17 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id C0C15399B44 for ; Mon, 2 Mar 2009 12:14:43 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Mon, 02 Mar 2009 12:14:41 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] security name relevant text from the current SSH draft and needed changes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:14:18 -0000 >From the address TC: The beginning of the address specification may contain a username followed by an '@' (ASCII character 0x40). This portion of the address will indicate the user name that should be used when authenticating to an SSH server. If missing, the SNMP securityName should be used. After the optional user name field and '@' character comes the hostname or IP address. >From the Incoming EOP: 1. The SSH Transport Model queries the SSH engine, in an implementation-dependent manner, to determine the transportAddress, the principal name authenticated by SSH, and a session identifier. The transportAddress must be consistent during the life of a SSH session. By default on the server side of a SSH connection, the principal name is the value of the user name field of the SSH_MSG_USERAUTH_REQUEST message for which a SSH_MSG_USERAUTH_SUCCESS has been sent. How this name is extracted from the SSH environment is implementation-dependent. 2. Create a tmStateReference cache for subsequent reference to the information. [...] tmSecurityName = the ssh principal name received by the SSH server or sent from a SSH client. [...] So, after reading this it does look like something is wrong here and could be interpreted incorrectly from what I believe we all agreed upon. Most of this is related to the "or" clause in that last sentence. I believe the final tmSecurityName line should read (there may be other text that needs to change too, but this is the important one): tmSecurityName = the tmSecurityName associated with the session, if the session was previously established, or the ssh principal name received by the SSH server for new incoming connections. In short when receiving a message, the processing should be: Is this a new incoming connection? Yes: set the tmSecurityName to the SSH user name and cache it for future use for the "No" case (*) below. No(*): set this to the cached tmSecurityName For outgoing messages: Cache the tmSecurityName pulled from the tmStateReference for use when replies come back from the session in (*) above. At no point will the Yes clause above be triggered if we're opening the connection. Disallow all future outgoing messages for this session (identified by the tmSessionID) to use a tmSecurityName other than the cached one. I think this logic should meet what everyone is expecting, based on previously agreed upon consensus. If the above looks good logic wise, I'll even offer to check what text needs to be modified and submit a fast proposal for fixing it. Note that the ID cut-off for a -15 is imminent. -- Wes Hardaker Sparta, Inc. From jhutz@cmu.edu Mon Mar 2 14:35:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA403A6A09 for ; Mon, 2 Mar 2009 14:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 LVah5NNKPcUS for ; Mon, 2 Mar 2009 14:35:30 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 4A01428C27B for ; Mon, 2 Mar 2009 14:35:30 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n22MZqaf017208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 17:35:52 -0500 (EST) Date: Mon, 02 Mar 2009 17:35:52 -0500 From: Jeffrey Hutzelman To: Wes Hardaker , isms@ietf.org Message-ID: <8EE2F4047370B38725D237F6@minbar.fac.cs.cmu.edu> In-Reply-To: <200903022014.n22KEnTp023769@toasties.srv.cs.cmu.edu> References: <200903022014.n22KEnTp023769@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] security name relevant text from the current SSH draft and needed changes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 22:35:31 -0000 --On Monday, March 02, 2009 12:14:41 PM -0800 Wes Hardaker wrote: > I think this logic should meet what everyone is expecting, based on > previously agreed upon consensus. If the above looks good logic wise, > I'll even offer to check what text needs to be modified and submit a > fast proposal for fixing it. Note that the ID cut-off for a -15 is > imminent. Yes, I believe that correctly captures the way I have understood the protocol to work all along, and how I believe we have agreed it should work. The one bit that confused me was that I thought the SNMPv3 message carried a security name, in which case it would be necessary to verify that that name matched the one provided by the transport layer. But David assures me this is not the case, which means the problem goes away. -- Jeff From wjhns1@hardakers.net Mon Mar 2 16:17:04 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B7D28C11C for ; Mon, 2 Mar 2009 16:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_57=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 eGvw4EIwaNPQ for ; Mon, 2 Mar 2009 16:17:03 -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 63ECA3A6896 for ; Mon, 2 Mar 2009 16:17:03 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D4A38399B44; Mon, 2 Mar 2009 16:17:29 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200903022014.n22KEnTp023769@toasties.srv.cs.cmu.edu> <8EE2F4047370B38725D237F6@minbar.fac.cs.cmu.edu> Date: Mon, 02 Mar 2009 16:17:29 -0800 In-Reply-To: <8EE2F4047370B38725D237F6@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 02 Mar 2009 17:35:52 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] security name relevant text from the current SSH draft and needed changes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 00:17:04 -0000 >>>>> On Mon, 02 Mar 2009 17:35:52 -0500, Jeffrey Hutzelman said: JH> The one bit that confused me was that I thought the SNMPv3 message JH> carried a security name, in which case it would be necessary to verify JH> that that name matched the one provided by the transport layer. But JH> David assures me this is not the case, which means the problem goes JH> away. It does not carry a securityName. The packet basically is broken down as (I created a cheat-sheet years ago when SNMPv3 was first being developed in order to understand it all): SNMPv3Message ::= SEQUENCE { msgVersion INTEGER { snmpv3 (3) }, msgGlobalData HeaderData, msgID INTEGER (0..2147483647), msgMaxSize INTEGER (484..2147483647), msgFlags OCTET STRING (SIZE(1)), msgSecurityModel INTEGER (0..2147483647) msgSecurityParameters OCTET STRING, msgData ScopedPduData ... The msgSecurityModel valrue in the global headers is a field that all v3 messages contain. The msgSecurityParameters is functionally an opaque field that the SM gets to put whatever it wants into it. For USM, the user name and other parameters are put into it. For TSM, we're putting nothing (it becomes an empty octet string). So no, there is user information in snmpv3 packet itself unless the SM puts it in there. -- Wes Hardaker Sparta, Inc. From j.schoenwaelder@jacobs-university.de Tue Mar 3 00:37:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E3528C138 for ; Tue, 3 Mar 2009 00:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 XK0Bcdco8RUr for ; Tue, 3 Mar 2009 00:37:35 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DC2FE28C0D8 for ; Tue, 3 Mar 2009 00:37:34 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41ECCC0052; Tue, 3 Mar 2009 09:38:01 +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 l9ECkzXeqLBp; Tue, 3 Mar 2009 09:37:54 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44211C000A; Tue, 3 Mar 2009 09:37:54 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 37C369D3F00; Tue, 3 Mar 2009 09:37:53 +0100 (CET) Date: Tue, 3 Mar 2009 09:37:53 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090303083753.GA2803@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Wes Hardaker , "tom.petch" , isms@ietf.org, Jeffrey Hutzelman References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu> <790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu> <200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu> <009C7BF23F5B9C5373B3C6C1@atlantis.pc.cs.cmu.edu> <003d01c99aa8$f5e6d9e0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] wg last call followup - e-mail address 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: , X-List-Received-Date: Tue, 03 Mar 2009 08:37:36 -0000 On Mon, Mar 02, 2009 at 11:55:50AM -0800, Wes Hardaker wrote: > >>>>> On Sun, 1 Mar 2009 21:04:05 +0100, "tom.petch" said: > > tp> In particular, it creates the 'Pasi problem', Command Generator > tp> sends a Request with securityName of Alice, gets a Reponse with > tp> securityName of Bob. > > No! That never happens. A CG that opens a request with a securityName > of "Alice" but a transport address of "bob@example.com" will get back a > securityName of "Alice", ***NOT*** Bob. Wes or DBH, can you point to the exact place in the IDs where this is described? We need to move this discussion to the concrete text in the documents. If we find text that handles this, we are done and can close this technical issue. If not, we hopefully get closer to know what text needs to be added where. So far I understand: - There should be a better motivation why user@host addresses are supported (to make NOs work better). - We need to make sure that the EoP provide a consistent securityName for SNMP applications using this feature. Can we please sort this out quickly? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Tue Mar 3 06:27:33 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CC23A699D for ; Tue, 3 Mar 2009 06:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.083, 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 BdAZN+A-wIB7 for ; Tue, 3 Mar 2009 06:27:32 -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 67C4C3A6887 for ; Tue, 3 Mar 2009 06:27:32 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 968A839A0FA; Tue, 3 Mar 2009 06:27:59 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu> <790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu> <200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu> <009C7BF23F5B9C5373B3C6C1@atlantis.pc.cs.cmu.edu> <003d01c99aa8$f5e6d9e0$0601a8c0@allison> <20090303083753.GA2803@elstar.iuhb02.iu-bremen.de> Date: Tue, 03 Mar 2009 06:27:59 -0800 In-Reply-To: <20090303083753.GA2803@elstar.iuhb02.iu-bremen.de> (Juergen Schoenwaelder's message of "Tue, 3 Mar 2009 09:37:53 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 14:27:33 -0000 >>>>> On Tue, 3 Mar 2009 09:37:53 +0100, Juergen Schoenwaelder said: WH> No! That never happens. A CG that opens a request with a securityName WH> of "Alice" but a transport address of "bob@example.com" will get back a WH> securityName of "Alice", ***NOT*** Bob. JS> Wes or DBH, can you point to the exact place in the IDs where this is JS> described? If you'll look at the other message I sent (Subject: "security name relevant text from the current SSH draft and needed changes"), I listed the text where it sort-of-ish says the above. I also suggested that the text needs to be changed and suggested the beginnings of that text. Jeff agreed with me. Read the logical steps in that and if it's agreed that's what we meant, then we should change the wording to reflect that so we can move on. JS> - There should be a better motivation why user@host addresses are JS> supported (to make NOs work better). I'm not sure how much we need to concentrate on documenting motivations for each small item. But putting such text in wouldn't hurt. -- Wes Hardaker Sparta, Inc. From cfinss@dial.pipex.com Tue Mar 3 07:10:52 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1FD3A6405 for ; Tue, 3 Mar 2009 07:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.865, 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 etyOTnxGFuPD for ; Tue, 3 Mar 2009 07:10:50 -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 A7FB73A68B2 for ; Tue, 3 Mar 2009 07:10:50 -0800 (PST) X-Trace: 136712482/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.186/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.186 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: As4EACHXrEk+vBO6/2dsb2JhbACDIkKKBcpJB4N/Bg X-IronPort-AV: E=Sophos;i="4.38,296,1233532800"; d="scan'208";a="136712482" X-IP-Direction: IN Received: from 1cust186.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.186]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Mar 2009 15:11:13 +0000 Message-ID: <007701c99c09$b4725400$0601a8c0@allison> From: "tom.petch" To: , "Wes Hardaker" References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu> <790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu> <200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu> <009C7BF23F5B9C5373B3C6C1@atlantis.pc.cs.cmu.edu> <003d01c99aa8$f5e6d9e0$0601a8c0@allison> <20090303083753.GA2803@elstar.iuhb02.iu-bremen.de> Date: Tue, 3 Mar 2009 14:27:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:10:52 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Wes Hardaker" Cc: "tom.petch" ; ; "Jeffrey Hutzelman" Sent: Tuesday, March 03, 2009 9:37 AM Subject: Re: [Isms] wg last call followup - e-mail address > On Mon, Mar 02, 2009 at 11:55:50AM -0800, Wes Hardaker wrote: > > >>>>> On Sun, 1 Mar 2009 21:04:05 +0100, "tom.petch" said: > > > > tp> In particular, it creates the 'Pasi problem', Command Generator > > tp> sends a Request with securityName of Alice, gets a Reponse with > > tp> securityName of Bob. > > > > No! That never happens. A CG that opens a request with a securityName > > of "Alice" but a transport address of "bob@example.com" will get back a > > securityName of "Alice", ***NOT*** Bob. > > Wes or DBH, can you point to the exact place in the IDs where this is > described? > By way of contrast, I can point to the logic that says it does, based on my understanding of the wording in the current drafts (either or both of which could be wrong). And I see a post by Pasi - later echoed by dbh - listing this precise occurrent which reassures me that my reading, sadly, is correct. AFAICT the wording came from Wes and has been accurately incorporated by David into the I-D. But it would be really really helpful if we had consensus on whether this is acceptable or not. Wes is the first to say not, Pasi didn't, I sat on the fence. If it is unacceptable, I can produce any number of EOPs that fix it, but I think that producing EOPs and then having to reverse engineer the design and then to speculate on the requirements is one reason why I am disappointed with progress. But you know that:-) So let's have a design and then the EOPs and a requirement as well would be lovely. > We need to move this discussion to the concrete text in the documents. > If we find text that handles this, we are done and can close this > technical issue. If not, we hopefully get closer to know what text > needs to be added where. > > So far I understand: > > - There should be a better motivation why user@host addresses are > supported (to make NOs work better). > Yes please, a requirement, in -tmsm (yes, really). My less facetious take is "The transportAddress, as passed by the application may take the form user@example.com:port The 'user' part may be used as a user address to establish a transport and then be used by the remote engine as securityName. The local engine still uses securityName; two names are now in use, one for the local engine and the other for the remote engine. The use case for this is when, as with Notifications, the access control check is performed in the local engine, using the local securityName, as opposed to a Command Responder when the access control check is performed in the remote engine, using the name supplied as part of the transportAddress and associated security credentials." I do not think that I have grasped the point of this yet; I well know the Notification problem but how does this solve it? securityName is never authenticated so is this a solution? > - We need to make sure that the EoP provide a consistent securityName > for SNMP applications using this feature. > > Can we please sort this out quickly? Wish we could but be aware Juergen that I have a further stack of comments in this area, since e-mail format (yes Jeff, I know this is not e-mail:-) addresses have been added. The EOPs do some odd things and I think that they need clarifying or changing or both. But these are the big two, how and why, and if we agree on them, then the rest becomes clearer for me. The others mostly revolve around transport addresses, when the user@ is or is not there and what then happens Pushing out another I-D before the deadline is likely, IMHO, to delay things. Tom Petch > > /js > From cfinss@dial.pipex.com Tue Mar 3 07:10:52 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0243A6405 for ; Tue, 3 Mar 2009 07:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, J_CHICKENPOX_57=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 c2HFqipQrdkI for ; Tue, 3 Mar 2009 07:10:51 -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 4986D3A6984 for ; Tue, 3 Mar 2009 07:10:51 -0800 (PST) X-Trace: 136712497/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.186/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.186 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: As4EACHXrEk+vBO6/2dsb2JhbACDIkKKBcpJB4JPDIEkBoZH X-IronPort-AV: E=Sophos;i="4.38,296,1233532800"; d="scan'208";a="136712497" X-IP-Direction: IN Received: from 1cust186.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.186]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Mar 2009 15:11:17 +0000 Message-ID: <007801c99c09$b5a814e0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , "Jeffrey Hutzelman" References: <200903022014.n22KEnTp023769@toasties.srv.cs.cmu.edu><8EE2F4047370B38725D237F6@minbar.fac.cs.cmu.edu> Date: Tue, 3 Mar 2009 14:34:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] security name relevant text from the current SSH draftand needed changes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:10:52 -0000 ----- Original Message ----- From: "Wes Hardaker" To: "Jeffrey Hutzelman" Cc: Sent: Tuesday, March 03, 2009 1:17 AM Subject: Re: [Isms] security name relevant text from the current SSH draftand needed changes > >>>>> On Mon, 02 Mar 2009 17:35:52 -0500, Jeffrey Hutzelman said: > > JH> The one bit that confused me was that I thought the SNMPv3 message > JH> carried a security name, in which case it would be necessary to verify > JH> that that name matched the one provided by the transport layer. But > JH> David assures me this is not the case, which means the problem goes > JH> away. > > It does not carry a securityName. The packet basically is broken down > as (I created a cheat-sheet years ago when SNMPv3 was first being > developed in order to understand it all): > > SNMPv3Message ::= SEQUENCE { > msgVersion INTEGER { snmpv3 (3) }, > msgGlobalData HeaderData, > msgID INTEGER (0..2147483647), > msgMaxSize INTEGER (484..2147483647), > msgFlags OCTET STRING (SIZE(1)), > msgSecurityModel INTEGER (0..2147483647) > msgSecurityParameters OCTET STRING, > msgData ScopedPduData > ... > > The msgSecurityModel valrue in the global headers is a field that all v3 > messages contain. The msgSecurityParameters is functionally an opaque > field that the SM gets to put whatever it wants into it. For USM, the > user name and other parameters are put into it. For TSM, we're putting > nothing (it becomes an empty octet string). So no, there is user > information in snmpv3 packet itself unless the SM puts it in there. > And it really fascinates me, that after all this time, some think that the name is there. That sort of tells me it should be, life would be straightforward if it was, and the way I see user@example.com:port (and Windows has just told me that this is an e-mail address which is why I keep saying e-mail format address :-) is that is exactly what we are doing. 'user' is the name that we do not have in the PDU so we are using a backdoor to get it from local to remote engine. It's a philosophical point but that is how I see it. Ah well, we chose the difficult way of doing it and at this stage I want to make that work, not go back and put 'user' into isms securityParameters. No jokes, this is me being serious. Tom Petch > -- > Wes Hardaker > Sparta, Inc. From cfinss@dial.pipex.com Tue Mar 3 07:10:53 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96943A6B18 for ; Tue, 3 Mar 2009 07:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.790, 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 1rylvorZRplj for ; Tue, 3 Mar 2009 07:10:53 -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 CD12A3A6405 for ; Tue, 3 Mar 2009 07:10:52 -0800 (PST) X-Trace: 136712506/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.186/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.186 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: As4EACHXrEk+vBO6/2dsb2JhbACDIkKKBcpJB4N/BoZH X-IronPort-AV: E=Sophos;i="4.38,296,1233532800"; d="scan'208";a="136712506" X-IP-Direction: IN Received: from 1cust186.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.186]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Mar 2009 15:11:18 +0000 Message-ID: <007901c99c09$b6cd0ce0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , "Jeffrey Hutzelman" References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu><80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu><0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> Date: Tue, 3 Mar 2009 14:58:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:10:53 -0000 ----- Original Message ----- From: "Wes Hardaker" To: "Jeffrey Hutzelman" Cc: "David Harrington" ; "'tom.petch'" ; "'Juergen Schoenwaelder'" ; Sent: Monday, March 02, 2009 8:50 PM Subject: Re: wg last call followup - sshtm > >>>>> On Sun, 01 Mar 2009 11:25:52 -0500, Jeffrey Hutzelman said: > > JH> I'm still short on sleep, but this sounds sane to me, and I'm fairly > JH> convinced there is not a problem -- as long as we believe it's OK that > JH> the two parties to a transation might not use the same securityName. > > Which, I'll say again: we already agreed upon as a WG that it was OK. Weell, I was asleep at the time:-( I am confident that it was never called out as an issue and rough consensus declared, that I would have noticed. May be it was at an IETF meeting, I am rarely at those. Whatever, I am not against it, just need to clear we have rough consensus on it. In which case, it demands a mention in the architecture, ie tmsm, since I expect it to be a surprise to some users of this. Tom Petch > -- > Wes Hardaker > Sparta, Inc. From cfinss@dial.pipex.com Tue Mar 3 07:10:57 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F353A6984 for ; Tue, 3 Mar 2009 07:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, 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 YCG3blZBuEB0 for ; Tue, 3 Mar 2009 07:10:56 -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 B8B5E28C207 for ; Tue, 3 Mar 2009 07:10:55 -0800 (PST) X-Trace: 136712516/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.186/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.186 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: As4EACHXrEk+vBO6/2dsb2JhbACDIkKKBcpJB4JPDIEkBoZH X-IronPort-AV: E=Sophos;i="4.38,296,1233532800"; d="scan'208";a="136712516" X-IP-Direction: IN Received: from 1cust186.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.186]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Mar 2009 15:11:20 +0000 Message-ID: <007a01c99c09$b7c130e0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , "Jeffrey Hutzelman" References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu><80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu><0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com><003e01c99aa8$f70bd1e0$0601a8c0@allison><200903020217.n222HDpd017530@grapenut.srv.cs.cmu.edu> Date: Tue, 3 Mar 2009 15:05:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:10:57 -0000 Wes You probably have the text in sshtm s.5.2 4) 2) in mind which, unlike this e-mail, makes no mention of caching the tmSecurityName. Hence the problem. alice is not recorded anywhere and so cannot be presented to the application with the Response message. Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: "Jeffrey Hutzelman" Cc: "David Harrington" ; "'tom.petch'" ; "'Juergen Schoenwaelder'" ; Sent: Monday, March 02, 2009 8:48 PM Subject: Re: wg last call followup - sshtm > >>>>> On Mon, 02 Mar 2009 13:25:30 -0500, Jeffrey Hutzelman said: > > This is the important part that everyone needs to understand. I'm sort > of confused why we're rehashing stuff that was long ago discussed and > even agreed upon (I thought by a fairly big majority of the people!). > > JH> ... the response will come back _over the same ssh session_. Period. > JH> We don't get a response back from a particular IP address or hostname > JH> or user. We get a response back over the channel _we_ opened. This > JH> is exactly what tmSameSecurity is fore. > > Stream based transports like SSH or even DTLS (which is defining a > cryptographic stream, even if it's not a packet based stream like a TCP > stream) performs things in an order: > > 1) start up the stream, sharing and negotiating information like > certificates, names, passwords, options, etc. > > Alice <---- ----> Bob > > The result of this negotiation is almost always some sort of "handle" > and in most implementations is a file-descriptor socket at the heart > of it all (IE, an integer number identifying the stream to the > kernel/what-have-you). > > 2) Send traffic through the stream. It's important to note that pretty > much every protocol *does not send the user name /etc again*. It'd > be highly redundant to keep sending messages saying "oh, and this is > from Bob again". The stream user on one side is expected to know > that already (regardless of whether they initiated or accepted the > connection). > > 3) close the connection upon request > > > For the SSHTM we just recently added wording (I thought; I have yet to > check the new draft) that basically says that the tmSecurityName needs > to be cached/consistent during the life of a session. That way when > Alice sends a first message with a securityName of "alice" but that says > "open bob@foo.com" where bob@ is the SshTransportAddress convention, > alice's stack remembers that "alice" is the security name for the > lifetime of the session on our end. When it gets *any* messages from > the other side, it passes up "alice" as the tmSecurityName in the > upward-bound traveling tmStateReference. > > > If alice didn't want it this way and actually wanted "bob" to be > securityName, she would have set the initial tmStateRerence's > tmSecurityName correctly. It'd be *her* fault for not tying them > together. > > -- > Wes Hardaker > Sparta, Inc. From cfinss@dial.pipex.com Tue Mar 3 07:10:59 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FCD33A6835 for ; Tue, 3 Mar 2009 07:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, TVD_PH_SUBJ_META=0] 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 JFP77atf5lNf for ; Tue, 3 Mar 2009 07:10:58 -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 8BBB23A6984 for ; Tue, 3 Mar 2009 07:10:57 -0800 (PST) X-Trace: 136712532/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.186/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.186 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: As4EACHXrEk+vBO6/2dsb2JhbACDIkKKBbs2B48MB4JPDIEkBg X-IronPort-AV: E=Sophos;i="4.38,296,1233532800"; d="scan'208";a="136712532" X-IP-Direction: IN Received: from 1cust186.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.186]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Mar 2009 15:11:23 +0000 Message-ID: <007b01c99c09$b93a1540$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: Date: Tue, 3 Mar 2009 15:08:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] security name relevant text from the current SSH draft andneeded changes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:10:59 -0000 ----- Original Message ----- From: "Wes Hardaker" To: Sent: Monday, March 02, 2009 9:14 PM Subject: [Isms] security name relevant text from the current SSH draft andneeded changes > From the address TC: > > The beginning of the address specification may contain a > username followed by an '@' (ASCII character 0x40). This > portion of the address will indicate the user name that should > be used when authenticating to an SSH server. If missing, the > SNMP securityName should be used. After the optional user name > field and '@' character comes the hostname or IP address. > In passing, I think it wrong to have to read the TC to find how the EOP works. Hence the indignation in my first message over the first piece of text that a user of isms will find that refers to e-mail format addresses. That text must come at least as early as s.3 of ssstm; but I think tmsm is the really right place. > From the Incoming EOP: > > 1. The SSH Transport Model queries the SSH engine, in an > implementation-dependent manner, to determine the > transportAddress, the principal name authenticated by SSH, and a > session identifier. The transportAddress must be consistent > during the life of a SSH session. > > By default on the server side of a SSH connection, the principal > name is the value of the user name field of the > SSH_MSG_USERAUTH_REQUEST message for which a > SSH_MSG_USERAUTH_SUCCESS has been sent. How this name is > extracted from the SSH environment is implementation-dependent. > > 2. Create a tmStateReference cache for subsequent reference to the > information. > > [...] > > tmSecurityName = the ssh principal name received by the SSH > server or sent from a SSH client. > > [...] > > So, after reading this it does look like something is wrong here and > could be interpreted incorrectly from what I believe we all agreed upon. > Most of this is related to the "or" clause in that last sentence. > > I believe the final tmSecurityName line should read (there may be other > text that needs to change too, but this is the important one): > > tmSecurityName = the tmSecurityName associated with the > session, if the session was previously established, or the ssh > principal name received by the SSH server for new incoming > connections > > In short when receiving a message, the processing should be: > > Is this a new incoming connection? > > Yes: set the tmSecurityName to the SSH user name and cache it for > future use for the "No" case (*) below. > > No(*): set this to the cached tmSecurityName > > > For outgoing messages: > > Cache the tmSecurityName pulled from the tmStateReference for use when > replies come back from the session in (*) above. At no point will the > Yes clause above be triggered if we're opening the connection. > > Disallow all future outgoing messages for this session (identified by > the tmSessionID) to use a tmSecurityName other than the cached one. > We have not got a cache!!! We started many years ago with a session cache, but the EOPs have forced that into a message cache; which it has to be else mappings get lost. Note that the EOPs rightly call for a new one to be created for each inbound message. So now we need to reinvent the session cache. And we need to be very careful about how we identify entries since we took several years to get that right with the message cache. Forget servers and CRs, the problem is CG. When the first Request message crosses the API into sshtm, we check using securityName and transportAddress. That is all we have. When ssh successfully opens a session, we have a tmSessionID (we need text added to s.3 about this). I say that securityName+transportAddress (alice+bob@...)uniquely identify a session, ditto tmSessionID and the relationship MUST be one to one. Then sshtm checks for the absence of an entry in the cache, creates one; ssh then generates tmSessionID which it or more likely sshtm inserts into the cache (I find the current text on tmSessionID unclear). For inbound Responses, ssh identifes the session to sshtm by tmSessionID and sshtm can then extract the securityName and pass it up the stack as tmSecurityName Consequence? alice+bob@example.com:notifyport bob+bob@example.com:requestport alice+bob@example.com:requestport will generate three separate sessions, but I am assuming that that is the intended requirement. > > > I think this logic should meet what everyone is expecting, based on > previously agreed upon consensus. If the above looks good logic wise, > I'll even offer to check what text needs to be modified and submit a > fast proposal for fixing it. Note that the ID cut-off for a -15 is > imminent. > Please no, forget the cutoff, let's get this right. Tom Petch > Wes Hardaker > Sparta, Inc. From j.schoenwaelder@jacobs-university.de Tue Mar 3 07:50:34 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA443A67BD for ; Tue, 3 Mar 2009 07:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-0.181, 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 PFUgBIb79wHi for ; Tue, 3 Mar 2009 07:50:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5C81C3A6905 for ; Tue, 3 Mar 2009 07:50:33 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFEC6C0061; Tue, 3 Mar 2009 16:50:59 +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 YCVXhrIVC39v; Tue, 3 Mar 2009 16:50:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB4F9C0024; Tue, 3 Mar 2009 16:50:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B7CFB9D4A7D; Tue, 3 Mar 2009 16:50:50 +0100 (CET) Date: Tue, 3 Mar 2009 16:50:50 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090303155050.GE3487@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "tom.petch" , Wes Hardaker , isms@ietf.org, Jeffrey Hutzelman References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu> <790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu> <200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu> <009C7BF23F5B9C5373B3C6C1@atlantis.pc.cs.cmu.edu> <003d01c99aa8$f5e6d9e0$0601a8c0@allison> <20090303083753.GA2803@elstar.iuhb02.iu-bremen.de> <007701c99c09$b4725400$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007701c99c09$b4725400$0601a8c0@allison> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Jeffrey Hutzelman , isms@ietf.org Subject: Re: [Isms] wg last call followup - e-mail address 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: , X-List-Received-Date: Tue, 03 Mar 2009 15:50:34 -0000 On Tue, Mar 03, 2009 at 02:27:15PM +0100, tom.petch wrote: > > Wes or DBH, can you point to the exact place in the IDs where this is > > described? > > > By way of contrast, I can point to the logic that says it does, based on my > understanding of the wording in the current drafts (either or both of which > could be wrong). And I see a post by Pasi - later echoed by dbh - listing this > precise occurrent which reassures me that my reading, sadly, is correct. AFAICT > the wording came from Wes and has been accurately incorporated by David into the > I-D. Sorry, I have trouble to follow... > But it would be really really helpful if we had consensus on whether this is > acceptable or not. Wes is the first to say not, Pasi didn't, I sat on the > fence. If it is unacceptable, I can produce any number of EOPs that fix it, but > I think that producing EOPs and then having to reverse engineer the design and > then to speculate on the requirements is one reason why I am disappointed with > progress. But you know that:-) So let's have a design and then the EOPs and a > requirement as well would be lovely. > > > We need to move this discussion to the concrete text in the documents. > > If we find text that handles this, we are done and can close this > > technical issue. If not, we hopefully get closer to know what text > > needs to be added where. > > > > So far I understand: > > > > - There should be a better motivation why user@host addresses are > > supported (to make NOs work better). > > Yes please, a requirement, in -tmsm (yes, really). My less facetious take is > > "The transportAddress, as passed by the application may take the form > user@example.com:port > The 'user' part may be used as a user address to establish a transport and then > be used by the remote engine as securityName. The local engine still uses > securityName; two names are now in use, one for the local engine and the other > for the remote engine. > > The use case for this is when, as with Notifications, the access control check > is performed in the local engine, using the local securityName, as opposed to a > Command Responder when the access control check is performed in the remote > engine, using the name supplied as part of the transportAddress and associated > security credentials." > > I do not think that I have grasped the point of this yet; I well know the > Notification problem but how does this solve it? securityName is never > authenticated so is this a solution? I think Jeff pretty much explained why support user@host helps with notifications. The point is that for notifications, access control uses securityName to identify the notification receiver while SSH uses the SSH user name to identify the notification sender. In many cases, these will not be the same. So the user@host format allows to make this important distinction. Is this understandable? Do you support this motivation? If yes, can the document editors make sure appropriate text is added to the secshell document? > > - We need to make sure that the EoP provide a consistent securityName > > for SNMP applications using this feature. > > > > Can we please sort this out quickly? > > Wish we could but be aware Juergen that I have a further stack of comments in > this area, since e-mail format (yes Jeff, I know this is not e-mail:-) addresses > have been added. The EOPs do some odd things and I think that they need > clarifying or changing or both. But these are the big two, how and why, and if > we agree on them, then the rest becomes clearer for me. > > The others mostly revolve around transport addresses, when the user@ is or is > not there and what then happens > > Pushing out another I-D before the deadline is likely, IMHO, to delay things. We need to resolve this issue and it better be done quickly. We have several days to get this straight. The ISMS WG has been crawling for a too long time and I am not interested in continuing this. Tell me whether you understand and agree/disagree with the motivation for the user@host format. Once we have an answer on this, we can look where changes to the EoP are required. And we still have several days for sorting this out. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Tue Mar 3 08:16:11 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4668C3A6A0C for ; Tue, 3 Mar 2009 08:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.077, 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 VAr22ABmiGh0 for ; Tue, 3 Mar 2009 08:16:10 -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 5AFD83A69D6 for ; Tue, 3 Mar 2009 08:16:09 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 8C69839A121; Tue, 3 Mar 2009 08:16:36 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> Date: Tue, 03 Mar 2009 08:16:36 -0800 In-Reply-To: <007901c99c09$b6cd0ce0$0601a8c0@allison> (tom petch's message of "Tue, 3 Mar 2009 14:58:09 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeffrey Hutzelman , isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:16:11 -0000 It was heavily discussed in Dublin and on the mailing list prior to Dublin (and I thought afterward too, but I'm not positive). tp> In which case, it demands a mention in the architecture, ie tmsm, tp> since I expect it to be a surprise to some users of this. It is a SSH specific thing. It does not relate to every possible TM and thus doesn't belong in TMSM. For example, the DTLS draft I've placed in the repository doesn't make use of the convention. It's specific to the SSHTM's address TC. -- Wes Hardaker Sparta, Inc. From dave.shield@googlemail.com Tue Mar 3 08:30:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C463A6A0C for ; Tue, 3 Mar 2009 08:30:31 -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 2XibvZ7G7t+2 for ; Tue, 3 Mar 2009 08:30:28 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 08F153A68A5 for ; Tue, 3 Mar 2009 08:30:27 -0800 (PST) Received: by bwz26 with SMTP id 26so2440348bwz.37 for ; Tue, 03 Mar 2009 08:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=MvQvSwlU9H48FdLzA26eFGb3oFWgU9QDrX1ZbjBVXVk=; b=RMB3gOQOGS0QmbYGrp9O0S3g35dnODO667GRN8Yt/iX1cRbMZ1C403onJyQANeaZAn vKp515ZYEue74FHLnUG9sKgVliWSxCS0o7SLEf2DqlQb6yTubzZ9vHmITwjvYEDks3I0 Ui2kFK7uDoKBhHXFFvNjnekckyBaU2lxOD26s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=evmNqjutLL12aY/ep2afMtCJWamX8wZ6kWcHRU3mSEHwrqOk6pmqVE85rdjGHER22x 5BSTKTBt5yn4vqfJ6DBIfwSqCq02XNQO6JJMqVxNtP5SqIM3EsZqFCTn2GPJ+shd2bGF T9MRH9ASAyujJpRB7RDXtfOkHaUnKPFGWytlA= MIME-Version: 1.0 Sender: dave.shield@googlemail.com Received: by 10.181.222.1 with SMTP id z1mr2593707bkq.112.1236097837158; Tue, 03 Mar 2009 08:30:37 -0800 (PST) In-Reply-To: References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> Date: Tue, 3 Mar 2009 16:30:37 +0000 X-Google-Sender-Auth: a4123d0d1a6d05f6 Message-ID: From: Dave Shield To: Wes Hardaker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:30:31 -0000 2009/3/3 Wes Hardaker : > It is a SSH specific thing. Is it inherently specific to *just* SSH? Or might it conceivably be relevant to some other secure transports as well? > =A0It does not relate to every possible TM and > thus doesn't belong in TMSM. That doesn't necessarily follow. If it's only ever going to apply to SSH (and not to any other possible TM), then I'd agree - this belongs in the SSH draft (and nowhere else). But if a similar situation could potentially arise in some other TMs, then it's worth briefly covering the basic principles in TMSM (while mentioning that this may not be relevant to all TMs) The detailed syntax of how (and whether) a particular TM can specify this information obviously belongs in the specs for that individual TM. But if it's likely to arise in more than one TM, then it doesn't feel unreasonable to prepare the ground in the overview document. Dave Disclaimer: I haven't actually read the last couple of drafts yet. From jhutz@cmu.edu Tue Mar 3 08:49:25 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0398528C2C2 for ; Tue, 3 Mar 2009 08:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 lMgP4pahWy+K for ; Tue, 3 Mar 2009 08:49:24 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 1808428C2BC for ; Tue, 3 Mar 2009 08:49:24 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (173-115-63-122.pools.spcsdns.net [173.115.63.122]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n23Gng5Q009784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 11:49:43 -0500 (EST) Date: Tue, 03 Mar 2009 11:49:41 -0500 From: Jeffrey Hutzelman To: "tom.petch" , Wes Hardaker Message-ID: <6AFA2D41695D387356D732BA@atlantis.pc.cs.cmu.edu> In-Reply-To: <007801c99c09$b5a814e0$0601a8c0@allison> References: <200903022014.n22KEnTp023769@toasties.srv.cs.cmu.edu> <8EE2F4047370B38725D237F6@minbar.fac.cs.cmu.edu> <007801c99c09$b5a814e0$0601a8c0@allison> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] security name relevant text from the current SSH draftand needed changes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:49:25 -0000 --On Tuesday, March 03, 2009 02:34:03 PM +0100 "tom.petch" wrote: > And it really fascinates me, that after all this time, some think that > the name is there. Well, of course the name isn't there if the SM gets to decide. I'm not an SNMP expert, though, and for some reason I was under the impression this was present in part of the SNMPv3 message that is not under the SM's control. > That sort of tells me it should be No, the fact that I was under the impression that part of the SNMPv3 message format was designed badly does not mean that it _should_ be designed badly. > 'user' is the name that we do not have in the PDU so we are using > a backdoor to get it from local to remote engine. No. In that example, 'user' is a name that is completely meaningless to SNMP, but is required by ssh, so we're using a backdoor to get it from the local engine to the local SSH client. -- Jeff From ietfdbh@comcast.net Tue Mar 3 08:56:52 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE55128C2C2 for ; Tue, 3 Mar 2009 08:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 Dh7BNhzrgw5F for ; Tue, 3 Mar 2009 08:56:51 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 30B7928C272 for ; Tue, 3 Mar 2009 08:56:51 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Nfrd1b04S0bG4ec57gxK5c; Tue, 03 Mar 2009 16:57:19 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id Ngx81b00D0UQ6dC3Pgx8lD; Tue, 03 Mar 2009 16:57:09 +0000 From: "David Harrington" To: , "'tom.petch'" References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu><790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu><200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu><009C7BF23F5B9C5373B3C6C1@atlantis.pc.cs.cmu.edu><003d01c99aa8$f5e6d9e0$0601a8c0@allison><20090303083753.GA2803@elstar.iuhb02.iu-bremen.de><007701c99c09$b4725400$0601a8c0@allison> <20090303155050.GE3487@elstar.iuhb02.iu-bremen.de> Date: Tue, 3 Mar 2009 11:57:16 -0500 Message-ID: <139701c99c21$1c516540$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090303155050.GE3487@elstar.iuhb02.iu-bremen.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmcF9w9n0uQRaxdSk6EHXiHuNF7EwAAwlLQ Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:56:53 -0000 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, March 03, 2009 10:51 AM > To: tom.petch > Cc: Jeffrey Hutzelman; isms@ietf.org > Subject: Re: [Isms] wg last call followup - e-mail address > > On Tue, Mar 03, 2009 at 02:27:15PM +0100, tom.petch wrote: > > > > Wes or DBH, can you point to the exact place in the IDs > where this is > > > described? > > > > > By way of contrast, I can point to the logic that says it > does, based on my > > understanding of the wording in the current drafts (either > or both of which > > could be wrong). And I see a post by Pasi - later echoed > by dbh - listing this > > precise occurrent which reassures me that my reading, > sadly, is correct. AFAICT > > the wording came from Wes and has been accurately > incorporated by David into the > > I-D. > > Sorry, I have trouble to follow... Wes explained it to me, and wrote the text about the securityName and address being associated with the session that is opened, and it must remain consistent. I understood (eventually) and we modified the ID with Wes's text. > > > But it would be really really helpful if we had consensus > on whether this is > > acceptable or not. Wes is the first to say not, Pasi > didn't, I sat on the > > fence. If it is unacceptable, I can produce any number of > EOPs that fix it, but > > I think that producing EOPs and then having to reverse > engineer the design and > > then to speculate on the requirements is one reason why I > am disappointed with > > progress. But you know that:-) So let's have a design and > then the EOPs and a > > requirement as well would be lovely. I agree that it is not obvious why we are doing this, or what the implications are, and they need to be spelled out better. Wes and I are working on this now. I think the current discussion is missing the major motivation for this - it is not about NOs, it is about SSH. This is the way SSH works, and we need to acommodate it. It comes into play mostly with NOs, because with NOs, we initiated the session using an SSH user@ format stroed in a MIB module. It could be used just as well by a CG or a proxy application - any application that initiates the SSH session. > > > > > We need to move this discussion to the concrete text in > the documents. > > > If we find text that handles this, we are done and can close this > > > technical issue. If not, we hopefully get closer to know what text > > > needs to be added where. > > > > > > So far I understand: > > > > > > - There should be a better motivation why user@host addresses are > > > supported (to make NOs work better). > > > > Yes please, a requirement, in -tmsm (yes, really). My > less facetious take is (no, really) - this is a SSH-specific behavior, and belongs in the secshell document, not in tsms. It does NOT apply to USM. It may or may not apply to other secure transports. And other secure transports might use a different format for specifying the transport user to be authenticated. This format and its processing is specific to SSH, SSHTM, and SnmpSSHDomain addresses. Some of your recommended text looks good to me; other parts not. I will try to make sure we get an explanation in the (sechell) document in a manner that satifies you. > > > > "The transportAddress, as passed by the application may > take the form > > user@example.com:port > > The 'user' part may be used as a user address to establish > a transport and then > > be used by the remote engine as securityName. The local > engine still uses > > securityName; two names are now in use, one for the local > engine and the other > > for the remote engine. > > > > The use case for this is when, as with Notifications, the > access control check > > is performed in the local engine, using the local > securityName, as opposed to a > > Command Responder when the access control check is > performed in the remote > > engine, using the name supplied as part of the > transportAddress and associated > > security credentials." > > > > I do not think that I have grasped the point of this yet; I > well know the > > Notification problem but how does this solve it? > securityName is never > > authenticated so is this a solution? securityName is not authenticated for an outgoing notification. The MIB that contains data that requires access control is the same MIB that contains a MIB module with the securityName to use for access control. We have to trust that operators will not put a securityName into the Target-mib et al, that is not allowed to send notifications. The ACM can be used to finetune which notifications that specified securityName can send. The only important decision for ACM is whether the securityName-principal is allowed to send notifications with specific managed objects in them. **The intended receiver of the notification is unimportant to access control. The address is not a parameter in the ACM subsystem ASI: statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context containing variableName IN variableName -- OID for the managed object ) For incoming requests, the securityName represents the principal authenticated by the security model (possibly by delegating that responsibility to a secure transport model). And that authenticated principal is requesting access to the data in the MIB, and we do access control on that (principal, request). For incoming notifications, the securityName represents the authenticated principal. SNMP doesn't care very much because we do not do access control on incoming notifications. For RFC3413-proxy, we do not open the PDU, so we do no access control. We just forward the PDU as is, based on the administratively configured PROXY-MIB. Some of this discussion should be added to clarify the relationships for models like SSHTM. > > I think Jeff pretty much explained why support user@host helps with > notifications. The point is that for notifications, access control > uses securityName to identify the notification receiver while SSH uses > the SSH user name to identify the notification sender. In many cases, > these will not be the same. So the user@host format allows to make > this important distinction. Is this understandable? Do you support > this motivation? If yes, can the document editors make sure > appropriate text is added to the secshell document? > > > > - We need to make sure that the EoP provide a consistent > securityName > > > for SNMP applications using this feature. > > > > > > Can we please sort this out quickly? > > > > Wish we could but be aware Juergen that I have a further > stack of comments in > > this area, since e-mail format (yes Jeff, I know this is > not e-mail:-) addresses > > have been added. The EOPs do some odd things and I think > that they need > > clarifying or changing or both. But these are the big two, > how and why, and if > > we agree on them, then the rest becomes clearer for me. > > > > The others mostly revolve around transport addresses, when > the user@ is or is > > not there and what then happens The user@ is present all the way from the application to the transport model. The transport model breaks it apart. We need to ensure that it is present in the transportAddress passed via the (non-tmStateReference) parameters in the ASIs for incoming messages, so the MPM can match responses to outstanding requests. The tmStateReference's tmSecurityName needs to reflect the authenticated principal (which will not be in the user@ form). > > > > Pushing out another I-D before the deadline is likely, > IMHO, to delay things. > > We need to resolve this issue and it better be done quickly. We have > several days to get this straight. The ISMS WG has been crawling for a > too long time and I am not interested in continuing this. > > Tell me whether you understand and agree/disagree with the motivation > for the user@host format. Once we have an answer on this, we can look > where changes to the EoP are required. And we still have several days > for sorting this out. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Tue Mar 3 09:15:09 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBD53A6911 for ; Tue, 3 Mar 2009 09:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 BwswnDLq4NRb for ; Tue, 3 Mar 2009 09:15:08 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id B014B28C0E7 for ; Tue, 3 Mar 2009 09:15:08 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Nfrd1b01B0mv7h057hFcMl; Tue, 03 Mar 2009 17:15:36 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id NhFb1b00q0UQ6dC3XhFc59; Tue, 03 Mar 2009 17:15:36 +0000 From: "David Harrington" To: "'tom.petch'" , "'Wes Hardaker'" , "'Jeffrey Hutzelman'" References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu><80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu><0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com><003e01c99aa8$f70bd1e0$0601a8c0@allison><200903020217.n222HDpd017530@grapenut.srv.cs.cmu.edu> <007a01c99c09$b7c130e0$0601a8c0@allison> Date: Tue, 3 Mar 2009 12:15:34 -0500 Message-ID: <13aa01c99c23$aa66c4e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <007a01c99c09$b7c130e0$0601a8c0@allison> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmcElEOMDlF4C4VREuTV1yStU0ngQADvDwA Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:15:09 -0000 Hi, Actually, I think it is incorrect to say that no mention is made of caching the tmSecurityName. The openSession takes a tmStateReference that already contains a tmSecurityName, and openSession adds the corresponding tmSessionID to the tmStateReference cache. This binds the tmTransportAddress and the tmSecurityName and the tmSessionID together. When a response is received, it will be received over the existing session. And by looking up the tmSessionID, we find both the corresponding tmSecurityName and the correspnding "user@" transportAddress to pass up the stack. Apparently you didn't find that obvious ;-) We'll try to make it more obvious. > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Tuesday, March 03, 2009 9:05 AM > To: Wes Hardaker; Jeffrey Hutzelman > Cc: David Harrington; 'Juergen Schoenwaelder'; isms@ietf.org > Subject: Re: wg last call followup - sshtm > > Wes > > You probably have the text in sshtm s.5.2 4) 2) in mind > which, unlike this > e-mail, makes no mention of caching the tmSecurityName. Hence > the problem. alice > is not recorded anywhere and so cannot be presented to the > application with the > Response message. > > Tom Petch > > > ----- Original Message ----- > From: "Wes Hardaker" > To: "Jeffrey Hutzelman" > Cc: "David Harrington" ; "'tom.petch'" > ; "'Juergen Schoenwaelder'" > ; > Sent: Monday, March 02, 2009 8:48 PM > Subject: Re: wg last call followup - sshtm > > > > >>>>> On Mon, 02 Mar 2009 13:25:30 -0500, Jeffrey Hutzelman > > said: > > > > This is the important part that everyone needs to > understand. I'm sort > > of confused why we're rehashing stuff that was long ago > discussed and > > even agreed upon (I thought by a fairly big majority of the > people!). > > > > JH> ... the response will come back _over the same ssh > session_. Period. > > JH> We don't get a response back from a particular IP > address or hostname > > JH> or user. We get a response back over the channel _we_ > opened. This > > JH> is exactly what tmSameSecurity is fore. > > > > Stream based transports like SSH or even DTLS (which is defining a > > cryptographic stream, even if it's not a packet based > stream like a TCP > > stream) performs things in an order: > > > > 1) start up the stream, sharing and negotiating information like > > certificates, names, passwords, options, etc. > > > > Alice <---- ----> Bob > > > > The result of this negotiation is almost always some > sort of "handle" > > and in most implementations is a file-descriptor > socket at the heart > > of it all (IE, an integer number identifying the stream to the > > kernel/what-have-you). > > > > 2) Send traffic through the stream. It's important to > note that pretty > > much every protocol *does not send the user name /etc > again*. It'd > > be highly redundant to keep sending messages saying > "oh, and this is > > from Bob again". The stream user on one side is > expected to know > > that already (regardless of whether they initiated or > accepted the > > connection). > > > > 3) close the connection upon request > > > > > > For the SSHTM we just recently added wording (I thought; I > have yet to > > check the new draft) that basically says that the > tmSecurityName needs > > to be cached/consistent during the life of a session. That way when > > Alice sends a first message with a securityName of "alice" > but that says > > "open bob@foo.com" where bob@ is the SshTransportAddress convention, > > alice's stack remembers that "alice" is the security name for the > > lifetime of the session on our end. When it gets *any* > messages from > > the other side, it passes up "alice" as the tmSecurityName in the > > upward-bound traveling tmStateReference. > > > > > > If alice didn't want it this way and actually wanted "bob" to be > > securityName, she would have set the initial tmStateRerence's > > tmSecurityName correctly. It'd be *her* fault for not tying them > > together. > > > > -- > > Wes Hardaker > > Sparta, Inc. > > From wjhns1@hardakers.net Tue Mar 3 09:19:24 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1AF3A6919 for ; Tue, 3 Mar 2009 09:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.072, 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 v88NRIZCSzC6 for ; Tue, 3 Mar 2009 09:19:23 -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 AF0F23A6B6A for ; Tue, 3 Mar 2009 09:18:33 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 231CE399A89; Tue, 3 Mar 2009 09:19:01 -0800 (PST) From: Wes Hardaker To: Dave Shield Organization: Sparta References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> Date: Tue, 03 Mar 2009 09:19:00 -0800 In-Reply-To: (Dave Shield's message of "Tue, 3 Mar 2009 16:30:37 +0000") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:19:24 -0000 >>>>> On Tue, 3 Mar 2009 16:30:37 +0000, Dave Shield said: >> It is a SSH specific thing. DS> Is it inherently specific to *just* SSH? DS> Or might it conceivably be relevant to DS> some other secure transports as well? It may be. But the TMSM doc is relevant to them all. It's a design decision to be made per-transport. And it greatly depends on the architecture of the transport address. Now, on the other hand asymmetric identities is something that is likely to be common to most modern transports (including DTLS, but the details are quite different). Talking about that aspect generically certainly could go into the TSMS draft if we wanted to slow things down even further. I, personally, think the draft is good enough for a proposed standard as is and we can decide to fluff it up further for draft status if it's needed. -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Tue Mar 3 09:26:02 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D158F3A6B26 for ; Tue, 3 Mar 2009 09:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.067, 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 bGvUzdRspRrA for ; Tue, 3 Mar 2009 09:26:02 -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 061C13A6B1E for ; Tue, 3 Mar 2009 09:26:02 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 79139399A89 for ; Tue, 3 Mar 2009 09:26:29 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Tue, 03 Mar 2009 09:26:29 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:26:02 -0000 I've hacked up the secshell draft to fix the issue with respect to the need for a consistent tmSecurtyName. If nothing else, I think this discussion has been a good one because it's highlighted that the tmSecurityName must be consistent for the life of the session and we didn't state that clearly in the -14 draft. It was roughly stated in the text in some obscure ways that I'm not at all sure that implementations would have gotten it right. Here's a URL for the diffs (obviously: ignore the not-relevant changes introduced by date changes, etc): http://tools.ietf.org//rfcdiff?url1=http://www.hardakers.net/temp/draft-ietf-isms-secshell-14.txt&url2=http://www.hardakers.net/temp/draft-ietf-isms-secshell-15wes.txt -- Wes Hardaker Sparta, Inc. From jhutz@cmu.edu Tue Mar 3 12:08:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA093A67F9 for ; Tue, 3 Mar 2009 12:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 Eh9Jya2gFvkG for ; Tue, 3 Mar 2009 12:08:35 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id C9B9F28C15F for ; Tue, 3 Mar 2009 12:08:35 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (173-115-63-122.pools.spcsdns.net [173.115.63.122]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n23K8tgp016874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 15:08:57 -0500 (EST) Date: Tue, 03 Mar 2009 15:08:55 -0500 From: Jeffrey Hutzelman To: Wes Hardaker , Dave Shield Message-ID: <899608A34D028DF144F6D93C@atlantis.pc.cs.cmu.edu> In-Reply-To: <200903031719.n23HJtd3027069@toasties.srv.cs.cmu.edu> References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> <200903031719.n23HJtd3027069@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:08:36 -0000 --On Tuesday, March 03, 2009 09:19:00 AM -0800 Wes Hardaker wrote: >>>>>> On Tue, 3 Mar 2009 16:30:37 +0000, Dave Shield >>>>>> said: > >>> It is a SSH specific thing. > > DS> Is it inherently specific to *just* SSH? > DS> Or might it conceivably be relevant to > DS> some other secure transports as well? > > It may be. But the TMSM doc is relevant to them all. It's a design > decision to be made per-transport. And it greatly depends on the > architecture of the transport address. > > Now, on the other hand asymmetric identities is something that is likely > to be common to most modern transports (including DTLS, but the details > are quite different). Talking about that aspect generically certainly > could go into the TSMS draft if we wanted to slow things down even > further. I, personally, think the draft is good enough for a proposed > standard as is and we can decide to fluff it up further for draft status > if it's needed. I agree. Let's avoid premature generalization here. From cfinss@dial.pipex.com Tue Mar 3 12:44:39 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E193A689E for ; Tue, 3 Mar 2009 12:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.401, 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 TWKRKm2vJrE2 for ; Tue, 3 Mar 2009 12:44:38 -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 BAA833A684A for ; Tue, 3 Mar 2009 12:44:37 -0800 (PST) X-Trace: 191000442/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.188/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.188 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: As4EAF8lrUk+vBG8/2dsb2JhbACDIkKKBMocB4N/BoZH X-IronPort-AV: E=Sophos;i="4.38,297,1233532800"; d="scan'208";a="191000442" X-IP-Direction: IN Received: from 1cust188.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.188]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Mar 2009 20:45:02 +0000 Message-ID: <016601c99c38$56046500$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Wes Hardaker'" , "'Jeffrey Hutzelman'" References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu><80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu><0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com><003e01c99aa8$f70bd1e0$0601a8c0@allison><200903020217.n222HDpd017530@grapenut.srv.cs.cmu.edu> <007a01c99c09$b7c130e0$0601a8c0@allison> <13aa01c99c23$aa66c4e0$0600a8c0@china.huawei.com> Date: Tue, 3 Mar 2009 20:10:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:44:39 -0000 ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; "'Wes Hardaker'" ; "'Jeffrey Hutzelman'" Cc: "'Juergen Schoenwaelder'" ; Sent: Tuesday, March 03, 2009 6:15 PM Subject: RE: wg last call followup - sshtm > Actually, I think it is incorrect to say that no mention is made of > caching the tmSecurityName. > > The openSession takes a tmStateReference that already contains a > tmSecurityName, and openSession adds the corresponding tmSessionID to > the tmStateReference cache. This binds the tmTransportAddress and the > tmSecurityName and the tmSessionID together. > > When a response is received, it will be received over the existing > session. And by looking up the tmSessionID, we find both the > corresponding tmSecurityName and the correspnding "user@" > transportAddress to pass up the stack. > > Apparently you didn't find that obvious ;-) Well now, you can if you have a session cache whose entries remain invariant for the duration of the session. Which is not what the I-Ds currently say to me. 5.1 2) says create a tmStateReference cache and that is now the thrust, that a tmStateReference cache entry is created per inbound message and only lasts for the duration of the transaction as opposed to a cache entry that is per session and lasts for the duration of the session. I think that such a cache must now exist but see it as too much of a stretch to read that meaning into the current text. We are, I hope, writing this for those who have not spent five years working on it. Recall too that in November you said . "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." So I am now proposing - see another of my e-mails - a different use for tmSessionID, that it is used as a session identifier between sshtm and ssh in a Command Generator so as to match the request and response sessions, nothing to do with sameSecurity in a Command Responder. Also note that s.3 says " SSH sessions are uniquely identified within the SSH Transport Model by the combination of tmTransportAddress and tmSecurityName associated with each session." and this must now mean except when sessions are uniquely identified by tmSessionID so I have a sentence to add there as well to the effect that there must be a one-to-one correspondence between the unique tmTransportAddress+tmSecurityName and the unique tmSessionId. And as I already asked, why has openSession been changed to statusInformation = openSession( IN tmStateReference -- transport information to be used OUT tmStateReference -- transport information to be used IN maxMessageSize -- of the sending SNMP entity ) Or is this the obvious statement that the three parameters are cached together:-) Tom Petch > We'll try to make it more obvious. > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Tuesday, March 03, 2009 9:05 AM > > To: Wes Hardaker; Jeffrey Hutzelman > > Cc: David Harrington; 'Juergen Schoenwaelder'; isms@ietf.org > > Subject: Re: wg last call followup - sshtm > > > > Wes > > From cfinss@dial.pipex.com Tue Mar 3 12:44:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFED3A684A for ; Tue, 3 Mar 2009 12:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.684, 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 mewfAhlamRsG for ; Tue, 3 Mar 2009 12:44:37 -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 F00F23A682A for ; Tue, 3 Mar 2009 12:44:36 -0800 (PST) X-Trace: 191000433/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.188/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.188 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: As4EAF8lrUk+vBG8/2dsb2JhbACDIkKKBMocB4N/BoZH X-IronPort-AV: E=Sophos;i="4.38,297,1233532800"; d="scan'208";a="191000433" X-IP-Direction: IN Received: from 1cust188.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.188]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Mar 2009 20:45:01 +0000 Message-ID: <016501c99c38$54f035e0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , "Dave Shield" References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu><80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu><0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com><007901c99c09$b6cd0ce0$0601a8c0@allison> Date: Tue, 3 Mar 2009 18:47:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:44:41 -0000 ----- Original Message ----- From: "Wes Hardaker" To: "Dave Shield" Cc: Sent: Tuesday, March 03, 2009 6:19 PM Subject: Re: [Isms] wg last call followup - sshtm > >>>>> On Tue, 3 Mar 2009 16:30:37 +0000, Dave Shield said: > > >> It is a SSH specific thing. > > DS> Is it inherently specific to *just* SSH? > DS> Or might it conceivably be relevant to > DS> some other secure transports as well? > > It may be. But the TMSM doc is relevant to them all. It's a design > decision to be made per-transport. And it greatly depends on the > architecture of the transport address. > > Now, on the other hand asymmetric identities is something that is likely > to be common to most modern transports (including DTLS, but the details > are quite different). Talking about that aspect generically certainly > could go into the TSMS draft if we wanted to slow things down even > further. I, personally, think the draft is good enough for a proposed > standard as is and we can decide to fluff it up further for draft status > if it's needed. > Wes Look in tsm and you will find the e-mail format address there along with a brief explanation of what it is about. You might not find it at first, but it is there so it is not just in the sshtm I-D. And what it is about is having different securityName in sender and receiver which to me is a change to the architecture. I would have thought that RFC341x precluded it somewhere, but, like dbh, I cannot see anything to stop us. But I do see it as different enough to need documenting, and tmsm is the place to make architectural comments. Tom Petch > -- > Wes Hardaker > Sparta, Inc. From cfinss@dial.pipex.com Tue Mar 3 12:44:42 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABDE3A682A for ; Tue, 3 Mar 2009 12:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.357, 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 Dqg-sKWtjdkI for ; Tue, 3 Mar 2009 12:44:41 -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 65E143A69CE for ; Tue, 3 Mar 2009 12:44:40 -0800 (PST) X-Trace: 191000456/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.188/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.188 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: As4EAF8lrUk+vBG8/2dsb2JhbACDIkKKBMocB4JPDIEkBg X-IronPort-AV: E=Sophos;i="4.38,297,1233532800"; d="scan'208";a="191000456" X-IP-Direction: IN Received: from 1cust188.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.188]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Mar 2009 20:45:05 +0000 Message-ID: <016701c99c38$573a25e0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200903011326.n21DQ3lU013796@raisinbran.srv.cs.cmu.edu><790ACD14D0EE10599A2B2EE0@atlantis.pc.cs.cmu.edu><200903011430.n21EUFO4024727@toasties.srv.cs.cmu.edu><009C7BF23F5B9C5373B3C6C1@atlantis.pc.cs.cmu.edu><003d01c99aa8$f5e6d9e0$0601a8c0@allison><20090303083753.GA2803@elstar.iuhb02.iu-bremen.de><007701c99c09$b4725400$0601a8c0@allison> <20090303155050.GE3487@elstar.iuhb02.iu-bremen.de> <139701c99c21$1c516540$0600a8c0@china.huawei.com> Date: Tue, 3 Mar 2009 20:41:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] wg last call followup - e-mail address X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:44:42 -0000 Tom Petch ----- Original Message ----- From: "David Harrington" To: ; "'tom.petch'" Cc: "'Jeffrey Hutzelman'" ; Sent: Tuesday, March 03, 2009 5:57 PM Subject: RE: [Isms] wg last call followup - e-mail address > > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, March 03, 2009 10:51 AM > > To: tom.petch > > Cc: Jeffrey Hutzelman; isms@ietf.org > > Subject: Re: [Isms] wg last call followup - e-mail address > > > > On Tue, Mar 03, 2009 at 02:27:15PM +0100, tom.petch wrote: > > > > Sorry, I > > > But it would be really really helpful if we had consensus > > on whether this is > > > acceptable or not. Wes is the first to say not, Pasi > > didn't, I sat on the > > > fence. If it is unacceptable, I can produce any number of > > EOPs that fix it, but > > > I think that producing EOPs and then having to reverse > > engineer the design and > > > then to speculate on the requirements is one reason why I > > am disappointed with > > > progress. But you know that:-) So let's have a design and > > then the EOPs and a > > > requirement as well would be lovely. > > I agree that it is not obvious why we are doing this, or what the > implications are, and they need to be spelled out better. Wes and I > are working on this now. > > I think the current discussion is missing the major motivation for > this - it is not about NOs, it is about SSH. This is the way SSH > works, and we need to acommodate it. It comes into play mostly with > NOs, because with NOs, we initiated the session using an SSH user@ > format stroed in a MIB module. It could be used just as well by a CG > or a proxy application - any application that initiates the SSH > session. > > > > > We need to move this discussion to the concrete text in > > the documents. > > > > If we find text that handles this, we are done and can close > this > > > > technical issue. If not, we hopefully get closer to know what > text > > > > needs to be added where. > > > > > > > > So far I understand: > > > > > > > > - There should be a better motivation why user@host addresses > are > > > > supported (to make NOs work better). > > > > > > Yes please, a requirement, in -tmsm (yes, really). My > > less facetious take is > > (no, really) - this is a SSH-specific behavior, and belongs in the > secshell document, not in tsms. It does NOT apply to USM. It may or > may not apply to other secure transports. And other secure transports > might use a different format for specifying the transport user to be > authenticated. This format and its processing is specific to SSH, > SSHTM, and SnmpSSHDomain addresses. As in my other response to Dave and Wes, this format of address is in tsm along with a brief explanation thereof and again, I think it could be of general architectural use so would put it in tmsm. I agree that it does not apply to USM but I do not find that argument persuasive; I suspect that there is much in tmsm that does not apply to USM, even though the aim is to retrofit a transport subsystem that is SM neutral. But the my first aim is to have it somewhere. > > Some of your recommended text looks good to me; other parts not. I > will try to make sure we get an explanation in the (sechell) document > in a manner that satifies you. > > > > > > > "The transportAddress, as passed by the application may > > take the form > > > user@example.com:port > > > The 'user' part may be used as a user address to establish > > a transport and then > > > be used by the remote engine as securityName. The local > > engine still uses > > > securityName; two names are now in use, one for the local > > engine and the other > > > for the remote engine. > > > > > > The use case for this is when, as with Notifications, the > > access control check > > > is performed in the local engine, using the local > > securityName, as opposed to a > > > Command Responder when the access control check is > > performed in the remote > > > engine, using the name supplied as part of the > > transportAddress and associated > > > security credentials." > > > > > > I do not think that I have grasped the point of this yet; I > > well know the > > > Notification problem but how does this solve it? > > securityName is never > > > authenticated so is this a solution? > > securityName is not authenticated for an outgoing notification. The That was a missing brick in the wall for me; I assumed that something was needed but could never see how so rather lost interest in secure Notifications. Perhaps worth a mention in Security Considerations. It is not that the I-Ds say anything else but that the outcome is not obvious and may come as a surprise to some. > MIB that contains data that requires access control is the same MIB > that contains a MIB module with the securityName to use for access > control. We have to trust that operators will not put a securityName > into the Target-mib et al, that is not allowed to send notifications. > The ACM can be used to finetune which notifications that specified > securityName can send. The only important decision for ACM is whether > the securityName-principal is allowed to send notifications with > specific managed objects in them. > > **The intended receiver of the notification is unimportant to access > control. The address is not a parameter in the ACM subsystem ASI: > > statusInformation = -- success or errorIndication > isAccessAllowed( > IN securityModel -- Security Model in use > IN securityName -- principal who wants to access > IN securityLevel -- Level of Security > IN viewType -- read, write, or notify view > IN contextName -- context containing variableName > IN variableName -- OID for the managed object > ) > > For incoming requests, the securityName represents the principal > authenticated by the security model (possibly by delegating that > responsibility to a secure transport model). And that authenticated > principal is requesting access to the data in the MIB, and we do > access control on that (principal, request). > > For incoming notifications, the securityName represents the > authenticated principal. SNMP doesn't care very much because we do not > do access control on incoming notifications. > > For RFC3413-proxy, we do not open the PDU, so we do no access control. > We just forward the PDU as is, based on the administratively > configured PROXY-MIB. > > Some of this discussion should be added to clarify the relationships > for models like SSHTM. > > > > > I think Jeff pretty much explained why support user@host helps with > > notifications. The point is that for notifications, access control > > uses securityName to identify the notification receiver while SSH > uses > > the SSH user name to identify the notification sender. In many > cases, > > these will not be the same. So the user@host format allows to make > > this important distinction. Is this understandable? Do you support > > this motivation? If yes, can the document editors make sure > > appropriate text is added to the secshell document? > > > > > > - We need to make sure that the EoP provide a consistent > > securityName > > > > for SNMP applications using this feature. > > > > > > > > Can we please sort this out quickly? > > > > > > Wish we could but be aware Juergen that I have a further > > stack of comments in > > > this area, since e-mail format (yes Jeff, I know this is > > not e-mail:-) addresses > > > have been added. The EOPs do some odd things and I think > > that they need > > > clarifying or changing or both. But these are the big two, > > how and why, and if > > > we agree on them, then the rest becomes clearer for me. > > > > > > The others mostly revolve around transport addresses, when > > the user@ is or is > > > not there and what then happens > > The user@ is present all the way from the application to the transport > model. The transport model breaks it apart. We need to ensure that it > is present in the transportAddress passed via the > (non-tmStateReference) parameters in the ASIs for incoming messages, > so the MPM can match responses to outstanding requests. Yes that is what I read in the I-D; what I think could be clearer is 5.1 2) tmTransportAddress = the address the message originated from, which Jeff's e-mail confirms for me means example.com, not the IP address thereof, not the e-mail format (and without the port?) and which, for the ssh client, is certainly NOT the address the message originated from but rather the address that was passed to ssh in openSession. The new paragraph that comes later starting "(If the session was not opened locally ..." is the key to understanding this but by the time I get there, other ideas have been confirmed in my mind by sentences like the one above. Not an easy read. Tom Petch > The tmStateReference's tmSecurityName needs to reflect the > authenticated principal (which will not be in the user@ form). > > > /js From wjhns1@hardakers.net Tue Mar 3 13:25:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26E03A6A7A for ; Tue, 3 Mar 2009 13:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.063, 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 fhLhorMQBe-Z for ; Tue, 3 Mar 2009 13:25:16 -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 B3C403A69CE for ; Tue, 3 Mar 2009 13:25:16 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 167AC399A89; Tue, 3 Mar 2009 13:25:43 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> <200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu> <80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu> <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> Date: Tue, 03 Mar 2009 13:25:43 -0800 In-Reply-To: <016501c99c38$54f035e0$0601a8c0@allison> (tom petch's message of "Tue, 3 Mar 2009 18:47:27 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 21:25:17 -0000 >>>>> On Tue, 3 Mar 2009 18:47:27 +0100, "tom.petch" said: tp> And what it is about is having different securityName in sender and tp> receiver which to me is a change to the architecture. I would have tp> thought that RFC341x precluded it somewhere, but, like dbh, I cannot tp> see anything to stop us. But I do see it as different enough to tp> need documenting, and tmsm is the place to make architectural tp> comments. In USM the securityName is explicitly passed and thus is the same on both sides. 341x would be broken if it specified they had to be identical on both sides, because it would prevent us from doing useful things like we're doing today. For SSHTM it actually turns out that the user name presented by ssh can be useful in deriving a tmSecurityName. If you look at the slides I presented in Dublin about the DTLSTM, you'll see it discusses why this isn't as straight forward for DTLS and the mappings are quite a bit more complex because DTLS doesn't hand a principal name to the infrastructure (it only hands a certificate which fields that are potentially much larger than a usable securityName). All that being said, I actually don't object to wording be added that much. But I don't think it's needed, and I don't think it's important from an interoperability point of view. I do think it will slow down the progress of these drafts which have been worked on for way too long and the ADs are rightfully pushing the WG to complete. If you wish to add text to the document I strongly suggest you propose the text and identify where it should go immediately so we can consider it. If no one is willing to propose text then I don't think it should hold up the documents because it's not a "technical" problem. -- Wes Hardaker Sparta, Inc. From j.schoenwaelder@jacobs-university.de Tue Mar 3 14:30:48 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140C23A6B2B for ; Tue, 3 Mar 2009 14:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 mkwjvbN+KBhR for ; Tue, 3 Mar 2009 14:30:47 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D1C693A6B24 for ; Tue, 3 Mar 2009 14:30:46 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE905C008B; Tue, 3 Mar 2009 23:31: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 HRqukT4dOkYN; Tue, 3 Mar 2009 23:31:07 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48596C006F; Tue, 3 Mar 2009 23:31:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3C22C9D5658; Tue, 3 Mar 2009 23:31:06 +0100 (CET) Date: Tue, 3 Mar 2009 23:31:06 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090303223106.GA5648@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , Dave Shield , isms@ietf.org References: <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016501c99c38$54f035e0$0601a8c0@allison> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm 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: , X-List-Received-Date: Tue, 03 Mar 2009 22:30:48 -0000 On Tue, Mar 03, 2009 at 06:47:27PM +0100, tom.petch wrote: > Look in tsm and you will find the e-mail format address there along > with a brief explanation of what it is about. You might not find it > at first, but it is there so it is not just in the sshtm I-D. Can you please tell us where? It helps me a lot if people try to be explicit. > And what it is about is having different securityName in sender and > receiver which to me is a change to the architecture. I would have > thought that RFC341x precluded it somewhere, but, like dbh, I cannot > see anything to stop us. But I do see it as different enough to > need documenting, and tmsm is the place to make architectural > comments. [Speaking as technical contributor.] Since RFC3411 is silent about this (or RFC341x if you want), it can't be a change of the architecture. I also believe the user@host feature should be SSH transport specific at this point in time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Tue Mar 3 16:09:54 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE8528C302 for ; Tue, 3 Mar 2009 16:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 xpR8SIxTIhuh for ; Tue, 3 Mar 2009 16:09:53 -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 9BEE228C2AC for ; Tue, 3 Mar 2009 16:09:52 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA09.westchester.pa.mail.comcast.net with comcast id NbvC1b00J17dt5G59oAM3s; Wed, 04 Mar 2009 00:10:21 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id NoAL1b00F0UQ6dC3ZoALzl; Wed, 04 Mar 2009 00:10:20 +0000 From: "David Harrington" To: , "'tom.petch'" References: <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com><007901c99c09$b6cd0ce0$0601a8c0@allison><016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> Date: Tue, 3 Mar 2009 19:10:19 -0500 Message-ID: <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090303223106.GA5648@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmcT9I3VBPYEVqtQ6OFubAmOvu72gACuviQ Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:09:54 -0000 Hi, I was totally confused by this whole thing myself. Then, to answer a question from Joe, I researched it fairly thorughly through the RFC341x series and realized my whole understanding was wrong, and then explained it to Joe, who finally understood it. Now Tom has a problem. (And I still slip into my old understanding and have to remember this new approach). I expect that most operators will have an understanding similar to my original understanding, which I think was the original intention of the SNMPv3 WG. I think we are turning things on their head here, and we better be sure operators understand. Just to put some reality into this, I suspect the documents have lots of places where the text is inconsistent as the result of this user@ usage. An example is the usage in the examples in TSM: The following example will configure the Notification Originator to send informs to a Notification Receiver at rtr-nyc4@192.0.2.1:PPP using the securityName "alice". "alice" is the name for the recipient from the standpoint of the notification originator, and is used for processing access controls before sending a notification."rtr-nyc4" is the name for the recipient from the standpoint of the notification receiver. alice is actually the sender, not the recipient. That one obviously slipped by. I think it is unrealistic to expect that we will have this all sorted out, and find all the incorrect usages, by the end of this week. I do not expect to have another revision by deadline. If Wes or Joe are available and in a masochistic mood, maybe they'll get another revision done. The next revision we publish will have to explain this whole thing better so we are all on the same page (see there is a benefit to only having 6 people in the WG; imagine the difficulty if more had to be on the same page). Text welcome. Then we can really start to fine-tooth-comb these documents for inconsistencies. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, March 03, 2009 5:31 PM > To: tom.petch > Cc: isms@ietf.org > Subject: Re: [Isms] wg last call followup - sshtm > > On Tue, Mar 03, 2009 at 06:47:27PM +0100, tom.petch wrote: > > > Look in tsm and you will find the e-mail format address there along > > with a brief explanation of what it is about. You might not find it > > at first, but it is there so it is not just in the sshtm I-D. > > Can you please tell us where? It helps me a lot if people try to be > explicit. > > > And what it is about is having different securityName in sender and > > receiver which to me is a change to the architecture. I would have > > thought that RFC341x precluded it somewhere, but, like dbh, I cannot > > see anything to stop us. But I do see it as different enough to > > need documenting, and tmsm is the place to make architectural > > comments. > > [Speaking as technical contributor.] > > Since RFC3411 is silent about this (or RFC341x if you want), it can't > be a change of the architecture. I also believe the user@host feature > should be SSH transport specific at this point in time. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Tue Mar 3 16:20:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7453D3A6907 for ; Tue, 3 Mar 2009 16:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 CTFn8Bpt1wJS for ; Tue, 3 Mar 2009 16:20:40 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 6A6B73A67B4 for ; Tue, 3 Mar 2009 16:20:40 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Nfrd1b02G17dt5G57oM8GV; Wed, 04 Mar 2009 00:21:08 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id NoM81b00T0UQ6dC3ZoM8bj; Wed, 04 Mar 2009 00:21:08 +0000 From: "David Harrington" To: "'tom.petch'" , "'Wes Hardaker'" , "'Jeffrey Hutzelman'" References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de><200902282050.n1SKoiNK028275@grapenut.srv.cs.cmu.edu><80DC81EC28A8208000C75503@atlantis.pc.cs.cmu.edu><0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com><003e01c99aa8$f70bd1e0$0601a8c0@allison><200903020217.n222HDpd017530@grapenut.srv.cs.cmu.edu> <007a01c99c09$b7c130e0$0601a8c0@allison> <13aa01c99c23$aa66c4e0$0600a8c0@china.huawei.com> <016601c99c38$56046500$0601a8c0@allison> Date: Tue, 3 Mar 2009 19:21:07 -0500 Message-ID: <14c101c99c5f$1cf42bc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <016601c99c38$56046500$0601a8c0@allison> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmcQPF70s6igx2ST7aAfUshlXrVoQAHPSUw Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:20:41 -0000 Hi Tom, > > Actually, I think it is incorrect to say that no mention is made of > > caching the tmSecurityName. > > > > The openSession takes a tmStateReference that already contains a > > tmSecurityName, and openSession adds the corresponding > tmSessionID to > > the tmStateReference cache. This binds the > tmTransportAddress and the > > tmSecurityName and the tmSessionID together. > > > > When a response is received, it will be received over the existing > > session. And by looking up the tmSessionID, we find both the > > corresponding tmSecurityName and the correspnding "user@" > > transportAddress to pass up the stack. > > > > Apparently you didn't find that obvious ;-) > > Well now, you can if you have a session cache whose entries > remain invariant for > the duration of the session. Which is not what the I-Ds > currently say to me. Hmmm. Is it the odd-numbered or even-numbered drafts that always have the MIB reappear? > 5.1 2) says create a tmStateReference cache and that is now > the thrust, that a > tmStateReference cache entry is created per inbound message > and only lasts for > the duration of the transaction as opposed to a cache entry > that is per session > and lasts for the duration of the session. I think that such > a cache must now > exist but see it as too much of a stretch to read that > meaning into the current > text. I think it is one of the many "implementation-dependent" cop-outs. > We are, I hope, writing this for those who have not > spent five years > working on it. If we work on it a bit longer, maybe SNMP will be declared Historic and we can all go home. > > Recall too that in November you said . > "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." I was lost and now I'm found. Yup, we'll have to clean up those types of statements in the text. > > So I am now proposing - see another of my e-mails - a > different use for > tmSessionID, that it is used as a session identifier between > sshtm and ssh in a > Command Generator so as to match the request and response > sessions, nothing to > do with sameSecurity in a Command Responder. Yup. > > Also note that s.3 says > " SSH sessions are uniquely identified within the SSH Transport Model > by the combination of tmTransportAddress and tmSecurityName > associated with each session." > and this must now mean except when sessions are uniquely identified by > tmSessionID so I have a sentence to add there as well to the > effect that there > must be a one-to-one correspondence between the unique > tmTransportAddress+tmSecurityName and the unique tmSessionId. Uh. maybe. I'm tired. I'll need sleep before concurring with this. > > And as I already asked, why has openSession been changed to > > statusInformation = > openSession( > IN tmStateReference -- transport information to be used > OUT tmStateReference -- transport information to be used > IN maxMessageSize -- of the sending SNMP entity > ) > > Or is this the obvious statement that the three parameters are cached > together:-) Yup. The EOP gets hard to read (grin) if we pass individual parameters in this interface. > > Tom Petch > > We'll try to make it more obvious. > > > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Tuesday, March 03, 2009 9:05 AM > > > To: Wes Hardaker; Jeffrey Hutzelman > > > Cc: David Harrington; 'Juergen Schoenwaelder'; isms@ietf.org > > > Subject: Re: wg last call followup - sshtm > > > > > > Wes > > > > > > From j.schoenwaelder@jacobs-university.de Tue Mar 3 23:24:03 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998BA28C2A6 for ; Tue, 3 Mar 2009 23:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.127, 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 33G1Esw9dmou for ; Tue, 3 Mar 2009 23:24:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 46F5A3A6A22 for ; Tue, 3 Mar 2009 23:24:02 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF03BC008C; Wed, 4 Mar 2009 08:24:29 +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 SnK7MhURjwu0; Wed, 4 Mar 2009 08:24:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE357C008B; Wed, 4 Mar 2009 08:24:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9DC959D5BDB; Wed, 4 Mar 2009 08:24:22 +0100 (CET) Date: Wed, 4 Mar 2009 08:24:22 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090304072422.GA6045@elstar.local> Mail-Followup-To: David Harrington , "'tom.petch'" , isms@ietf.org References: <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm 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: , X-List-Received-Date: Wed, 04 Mar 2009 07:24:03 -0000 On Tue, Mar 03, 2009 at 07:10:19PM -0500, David Harrington wrote: > new approach). I expect that most operators will have an understanding > similar to my original understanding, which I think was the original > intention of the SNMPv3 WG. I think we are turning things on their > head here, and we better be sure operators understand. The operators I know quite well how to use SSHs user@host notation and only few worry about SNMP's _an_ architecture. > I think it is unrealistic to expect that we will have this all sorted > out, and find all the incorrect usages, by the end of this week. I do > not expect to have another revision by deadline. If Wes or Joe are > available and in a masochistic mood, maybe they'll get another > revision done. [chair hat on] If it is not possible to sort this out by Monday, I expect that this will be resolved via email between the ID cutoff and the IETF meeting. This WG has a tendency to defer things to the next IETF meeting and during the WG meeting people figure out that working on the details of the text in the documents is too difficult and should be done after the IETF meeting. We need to break this cycle. The ID repository opens up again when the IETF meeting starts and I like to have documents posted at that time latest that have all technical issues resolved (and so far it seems the user@host notation is the only thing left). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Wed Mar 4 03:16:03 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A373A6B4F for ; Wed, 4 Mar 2009 03:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.643, 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 NovZV8NvNc8d for ; Wed, 4 Mar 2009 03:16:02 -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 00E813A69F9 for ; Wed, 4 Mar 2009 03:16:01 -0800 (PST) X-Trace: 225142021/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.181/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.181 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: AhsFAIPxrUk+vBG1/2dsb2JhbACDIkOKBclCB4QBBg X-IronPort-AV: E=Sophos;i="4.38,300,1233532800"; d="scan'208";a="225142021" X-IP-Direction: IN Received: from 1cust181.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.181]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Mar 2009 11:16:26 +0000 Message-ID: <005601c99cb2$112ad020$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: Date: Wed, 4 Mar 2009 11:13:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 11:16:03 -0000 Wes I tried the URL and got http 404. Something of a relief as I do not relish the prospect of another day spent reverse engineering EOPs:-) What I would prefer is rough consensus from everyone on the issues we have discussed, to whit: 1) the securityName used for a transaction in the local SNMP engine may not be the same as that used in the remote engine; this may occur when e-mail format addresses (user@example.com:port) are used 2) the securityName remains the same for the duration of a transaction (message sent and message(s) received) within a single engine 3) the securityName is not authenticated within a Notification Originator 4) the transportAddress used in the ASIs to establish a session must appear unchanged in the ASIs for all subsequent messages over that session 5) the tmTransportAddress as passed in tmState may vary between the outgoing and incoming messages of a transaction; this may occur when e-mail format addresses are used 6) tmSessionID uniquely identifies an SSH session within an engine both for current sessions and for sessions that have existed recently or may be setup in the near future, remains unchanged for the duration of that session and may be used anywhere in the engine where it is necessary to identify a session 7) when an application uses securityName+e-mail format transportAddress with transportDomain snmpSSHDomain, then alice+bob@example.com:request alice+bob@example.com:notify bob+bob@example.com:request bob+example.com:request will result in four separate SSH sessions 8) the transportAddress MUST include a port; omitting the port is an error Agreeing points in this format makes it much easier for me to verify that EOPs do what we want, and to propose amended text as and when they do not eg all references to example.com MUST be changed to example.com:port:-) Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: Sent: Tuesday, March 03, 2009 6:26 PM Subject: [Isms] Proposed text changes for the secshell draft > > I've hacked up the secshell draft to fix the issue with respect to the > need for a consistent tmSecurtyName. If nothing else, I think this > discussion has been a good one because it's highlighted that the > tmSecurityName must be consistent for the life of the session and we > didn't state that clearly in the -14 draft. It was roughly stated in > the text in some obscure ways that I'm not at all sure that > implementations would have gotten it right. > > Here's a URL for the diffs (obviously: ignore the not-relevant changes > introduced by date changes, etc): > > http://tools.ietf.org//rfcdiff?url1=http://www.hardakers.net/temp/draft-ietf-ism s-secshell-14.txt&url2=http://www.hardakers.net/temp/draft-ietf-isms-secshell-15 wes.txt > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From cfinss@dial.pipex.com Wed Mar 4 06:02:56 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27ED3A6B85 for ; Wed, 4 Mar 2009 06:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.620, 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 4H0Ia0Cyyu56 for ; Wed, 4 Mar 2009 06:02:55 -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 D190C3A68F5 for ; Wed, 4 Mar 2009 06:02:54 -0800 (PST) X-Trace: 191205272/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.182/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.182 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: AsAEACAZrkk+vBO2/2dsb2JhbACDIopJygYHglEMgSQG X-IronPort-AV: E=Sophos;i="4.38,301,1233532800"; d="scan'208";a="191205272" X-IP-Direction: IN Received: from 1cust182.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.182]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Mar 2009 14:03:20 +0000 Message-ID: <01f201c99cc9$61b85640$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com><007901c99c09$b6cd0ce0$0601a8c0@allison><016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> Date: Wed, 4 Mar 2009 12:45:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 14:02:56 -0000 ----- Original Message ----- From: "David Harrington" To: ; "'tom.petch'" Sent: Wednesday, March 04, 2009 1:10 AM Subject: RE: [Isms] wg last call followup - sshtm > I was totally confused by this whole thing myself. Then, to answer a > question from Joe, I researched it fairly thorughly through the > RFC341x series and realized my whole understanding was wrong, and then > explained it to Joe, who finally understood it. Now Tom has a problem. > (And I still slip into my old understanding and have to remember this > new approach). I expect that most operators will have an understanding > similar to my original understanding, which I think was the original > intention of the SNMPv3 WG. I think we are turning things on their > head here, and we better be sure operators understand. > > Just to put some reality into this, I suspect the documents have lots > of places where the text is inconsistent as the result of this user@ > usage. > > An example is the usage in the examples in TSM: > The following example will configure the Notification Originator to > send informs to a Notification Receiver at rtr-nyc4@192.0.2.1:PPP > using the securityName "alice". "alice" is the name for the > recipient > from the standpoint of the notification originator, and is used for > processing access controls before sending a notification."rtr-nyc4" > is the name for the recipient from the standpoint of the > notification > receiver. > > alice is actually the sender, not the recipient. That one obviously > slipped by. David, Actually, I see this one as ok:-) It tells me that there is a recipient and that the identifier for that recipient has two values, one, alice is used in the NO, the other, rtr-nyc4, is used in the NR. Well, ok as in correct, less ok as in is it easy to read and understand. I mentally duplicate that text replacing recipient with originator and that is also ok ie I import the Architecture/USM thinking that a transaction has one principal only now we use two different identifiers for that principal, one in NO, the other in NR. Whereas, as I say in my e-mail to Juergen, I cannot get the right meaning out of the e-mail he posted yesterday. "The point is that for notifications, access control uses securityName to identify the notification receiver while SSH uses the SSH user name to identify the notification sender. In many cases, these will not be the same. So the user@host format allows to make this important distinction. Is this understandable?" That does seem back to front to me but perhaps there is a reading of that that I am missing. Tom Petch > I think it is unrealistic to expect that we will have this all sorted > out, and find all the incorrect usages, by the end of this week. I do > not expect to have another revision by deadline. If Wes or Joe are > available and in a masochistic mood, maybe they'll get another > revision done. > > The next revision we publish will have to explain this whole thing > better so we are all on the same page (see there is a benefit to only > having 6 people in the WG; imagine the difficulty if more had to be on > the same page). Text welcome. Then we can really start to > fine-tooth-comb these documents for inconsistencies. > > dbh > From cfinss@dial.pipex.com Wed Mar 4 06:02:56 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886823A68F5 for ; Wed, 4 Mar 2009 06:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=0.297, 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 T0TVrfDV+MUi for ; Wed, 4 Mar 2009 06:02:55 -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 7D59D3A6AAF for ; Wed, 4 Mar 2009 06:02:55 -0800 (PST) X-Trace: 191205293/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.182/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.182 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: AsAEACAZrkk+vBO2/2dsb2JhbACDIopJugUJj3gBBoJQgTEG X-IronPort-AV: E=Sophos;i="4.38,301,1233532800"; d="scan'208";a="191205293" X-IP-Direction: IN Received: from 1cust182.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.182]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Mar 2009 14:03:22 +0000 Message-ID: <01f301c99cc9$62b41b60$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com> <0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu> <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> Date: Wed, 4 Mar 2009 13:53:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 14:02:56 -0000 Juergen Apologies for being coy. I had just said that if you read the documents in a logical order (RFC341x tmsm tsm sshtm), then the statement I flagged in sshtm 5.1 2) is the first a reader will encounter of this format and for me that, is too late. Having it in the sshtmTC (as Wes pointed out) is also inadequate IMHO. As dbh has now pointed out, I was alluding to the appendix in tsm which, being an appendix, I also see as inadequate; I would not expect to read the appendices on my first pass through the document set:-(. In this instance, the information is there, but boy, do I have to work to find it. Placing that 'first encounter' in sshtm s.3 and rewording it slightly makes a world of difference to the ease of understanding for me. I would also reword 5.1 2) which says either 'If the session was not opened locally with a user@example.com ...'. or 'If the session is a client session, and openSession used a tmTransportAddress of the "user@example.com" format' which forces me to stop and think, are there other alternatives?; maybe there are, so what happens then?. By contrast, having 'If the session is a client session and openSession used a tmTransport Address of the user@example.com:port'' against 'In all other cases, ...' well, I find that so much clearer. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "Wes Hardaker" ; "Dave Shield" ; Sent: Tuesday, March 03, 2009 11:31 PM Subject: Re: [Isms] wg last call followup - sshtm > On Tue, Mar 03, 2009 at 06:47:27PM +0100, tom.petch wrote: > > > Look in tsm and you will find the e-mail format address there along > > with a brief explanation of what it is about. You might not find it > > at first, but it is there so it is not just in the sshtm I-D. > > Can you please tell us where? It helps me a lot if people try to be > explicit. > > > And what it is about is having different securityName in sender and > > receiver which to me is a change to the architecture. I would have > > thought that RFC341x precluded it somewhere, but, like dbh, I cannot > > see anything to stop us. But I do see it as different enough to > > need documenting, and tmsm is the place to make architectural > > comments. > > [Speaking as technical contributor.] > > Since RFC3411 is silent about this (or RFC341x if you want), it can't > be a change of the architecture. I also believe the user@host feature > should be SSH transport specific at this point in time. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From cfinss@dial.pipex.com Wed Mar 4 06:02:58 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0465D28C1A1 for ; Wed, 4 Mar 2009 06:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.587, 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 YJ3YTcOqkOx8 for ; Wed, 4 Mar 2009 06:02:57 -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 E8FF63A68F5 for ; Wed, 4 Mar 2009 06:02:56 -0800 (PST) X-Trace: 191205304/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.182/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.182 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: AsAEACAZrkk+vBO2/2dsb2JhbACDIopJygYHglEMgSQG X-IronPort-AV: E=Sophos;i="4.38,301,1233532800"; d="scan'208";a="191205304" X-IP-Direction: IN Received: from 1cust182.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.182]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Mar 2009 14:03:23 +0000 Message-ID: <01f401c99cc9$63b781a0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , "David Harrington" References: <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <20090304072422.GA6045@elstar.local> Date: Wed, 4 Mar 2009 13:59:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 14:02:58 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David Harrington" Cc: "'tom.petch'" ; Sent: Wednesday, March 04, 2009 8:24 AM Subject: Re: [Isms] wg last call followup - sshtm > On Tue, Mar 03, 2009 at 07:10:19PM -0500, David Harrington wrote: > > > new approach). I expect that most operators will have an understanding > > similar to my original understanding, which I think was the original > > intention of the SNMPv3 WG. I think we are turning things on their > > head here, and we better be sure operators understand. > > The operators I know quite well how to use SSHs user@host notation and > only few worry about SNMP's _an_ architecture. Yes, and that is a concern for me. When user@host was first mooted, I recall a comment, Jeff I think, that this format was a commonplace in ssh. This means that people will have expectations which isms may or may not meet. I do not know what those expectations are. I have trawled the documentation of various manufacturers - eg Cisco, Juniper - for what they can do with ssh and see no reference to it. This does not surprise me, I probably need an programmer's guide with ssh APIs in it, not the sort of thing Cisco would put on its web site. Doubtless such a thing is available in a toolkit for Linux but that is not an area I am comfortable in. So instead I want a little more clarity in our documentation so that those coming from an ssh background with an intimate knowledge of what user@host will do for them, can see whether or not we do what they expect. Note too that yesterday, you said "The point is that for notifications, access control uses securityName to identify the notification receiver while SSH uses the SSH user name to identify the notification sender. In many cases, these will not be the same. So the user@host format allows to make this important distinction. Is this understandable?" Understandable yes, but this appears to be the exact opposite of my current thinking. I think that securityName identifies the principal in the notification sender/originator and SSH user name identifies the principal in the notification receiver. Which way round is going to be the expectation of all those SSH experts? Tom Petch > /js From ietfdbh@comcast.net Wed Mar 4 07:27:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3D83A6C98 for ; Wed, 4 Mar 2009 07:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 ZtDFkI-6UT5o for ; Wed, 4 Mar 2009 07:27:35 -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 43C033A69A7 for ; Wed, 4 Mar 2009 07:27:35 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA05.westchester.pa.mail.comcast.net with comcast id P31b1b00v1GhbT8553U4l2; Wed, 04 Mar 2009 15:28:04 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id P3U31b00y0UQ6dC3T3U3UY; Wed, 04 Mar 2009 15:28:04 +0000 From: "David Harrington" To: References: <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <20090304072422.GA6045@elstar.local> Date: Wed, 4 Mar 2009 10:28:02 -0500 Message-ID: <15dc01c99cdd$cf1cdad0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090304072422.GA6045@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmcmkOcEoCEJVVlSRmmAxJ44o7JXwAQkyaQ Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 15:27:36 -0000 Hi, > > The operators I know quite well how to use SSHs user@host notation and > only few worry about SNMP's _an_ architecture. Agreed. But SNMPv3 was designed with a rather symmetric model of security, and we need to be sure to verify that assumptions of that model do not permeate our documents, such as that the securityName for notifications gets authenticated. I may have allowed some to slip in that i should not have, and we need to be sure others who make similar assumptions are straightened out by our clear and unambiguous text. > > > I think it is unrealistic to expect that we will have this > all sorted > > out, and find all the incorrect usages, by the end of this > week. I do > > not expect to have another revision by deadline. If Wes or Joe are > > available and in a masochistic mood, maybe they'll get another > > revision done. > > [chair hat on] > > If it is not possible to sort this out by Monday, I expect that this > will be resolved via email between the ID cutoff and the IETF meeting. I am not sure there is much left to sort out. I think there is significant work in modifying the document. And I have competing priorities for this week. Assuming my other priorities do not use all my time, I expect that we can get a new revision done before the IETF meeting. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From wjhns1@hardakers.net Wed Mar 4 07:34:52 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4518F3A6CB8 for ; Wed, 4 Mar 2009 07:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.060, 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 HBAn7AIQxvOK for ; Wed, 4 Mar 2009 07:34:51 -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 2429A3A6CB7 for ; Wed, 4 Mar 2009 07:34:51 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id AAA9039A121; Wed, 4 Mar 2009 07:35:19 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <005601c99cb2$112ad020$0601a8c0@allison> Date: Wed, 04 Mar 2009 07:35:19 -0800 In-Reply-To: <005601c99cb2$112ad020$0601a8c0@allison> (tom petch's message of "Wed, 4 Mar 2009 11:13:38 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 15:34:52 -0000 >>>>> On Wed, 4 Mar 2009 11:13:38 +0100, "tom.petch" said: tp> I tried the URL and got http 404. Arg! but I can get to them directly and it worked yesterday. Try this one instead: http://www.hardakers.net/temp/ismsdiff.html and if that fails (probably due to DNS changes) try: http://www.ws6z.com/ismsdiff.html tp> 1) the securityName used for a transaction in the local SNMP engine tp> may not be the same as that used in the remote engine; this may tp> occur when e-mail format addresses (user@example.com:port) are used This has already been well discussed and consensus was agreed upon. tp> 2) the securityName remains the same for the duration of a tp> transaction (message sent and message(s) received) within a single tp> engine The changes I proposed should make this more clear. tp> 3) the securityName is not authenticated within a Notification Originator It never was in any SM. The V3 architecture never allows it to be. The VACM is checked before it's authenticated. The connection, however, has to operate as expected with the expected keys being used on the other side (be it the keys are USM secret keys or SSH/DTLS public/private keys). If the other side doesn't have the right keys based on your configured transport address, the notification won't get delivered because the connection will fail. tp> 4) the transportAddress used in the ASIs to establish a session must appear tp> unchanged in the ASIs for all subsequent messages over that session True and documented. And probably even more clear in my proposed text. tp> 5) the tmTransportAddress as passed in tmState may vary between the tp> outgoing and tp> incoming messages of a transaction; this may occur when e-mail tp> format addresses are used tp> 6) tmSessionID uniquely identifies an SSH session within an engine both for tp> current sessions and for sessions that have existed recently or may tp> be setup in the near future, remains unchanged for the duration of tp> that session and may be used anywhere in the engine where it is tp> necessary to identify a session session ID's are unique, I agree. In the DTLS draft I actually tried to put very careful wording describing their usage. Time doesn't matter too much in an implementation. The important thing is that at any given time a session ID must be unique. That means that even if the session closed but a reference exists elsewhere in the software to it, it can't be reused. So I disagree with the fuzzy wording "or maybe be set up in the near future". The issue is with existing references. Once all references have been cleared, the session ID can be safely reused. tp> 7) when an application uses securityName+e-mail format transportAddress with tp> transportDomain snmpSSHDomain, then tp> alice+bob@example.com:request tp> alice+bob@example.com:notify tp> bob+bob@example.com:request tp> bob+example.com:request tp> will result in four separate SSH sessions Correct, and I believe the document already specifies this. The modified one hopefully makes it more clear. You might add just example.com:request to your list to make it more complete if you like. tp> 8) the transportAddress MUST include a port; omitting the port is an error That's already documented in the TC, but I agree. tp> Agreeing points in this format makes it much easier for me to verify tp> that EOPs do what we want, and to propose amended text as and when tp> they do not eg all references to example.com MUST be changed to tp> example.com:port:-) That's a good point. The examples need to include a port number. Other than that, though, I think you're re-iterating what the working group has already agreed upon. So, with your new found consistency in place do you see any issues with the text in my proposed modifications? -- Wes Hardaker Sparta, Inc. From j.schoenwaelder@jacobs-university.de Wed Mar 4 07:40:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E08F3A6CD2 for ; Wed, 4 Mar 2009 07:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 QTTZi0sOsxr4 for ; Wed, 4 Mar 2009 07:40:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E1C8D3A6CD9 for ; Wed, 4 Mar 2009 07:40:08 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84DDBC00A6; Wed, 4 Mar 2009 16:40:36 +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 gdxj6a8OEjkN; Wed, 4 Mar 2009 16:40: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 E2CC2C00AA; Wed, 4 Mar 2009 16:40:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9C0819D6892; Wed, 4 Mar 2009 16:40:22 +0100 (CET) Date: Wed, 4 Mar 2009 16:40:22 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090304154022.GC6881@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , isms@ietf.org References: <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <20090304072422.GA6045@elstar.local> <01f401c99cc9$63b781a0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f401c99cc9$63b781a0$0601a8c0@allison> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm 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: , X-List-Received-Date: Wed, 04 Mar 2009 15:40:10 -0000 On Wed, Mar 04, 2009 at 01:59:09PM +0100, tom.petch wrote: > Yes, and that is a concern for me. When user@host was first mooted, > I recall a comment, Jeff I think, that this format was a commonplace > in ssh. This means that people will have expectations which isms may > or may not meet. I do not know what those expectations are. I have > trawled the documentation of various manufacturers - eg Cisco, > Juniper - for what they can do with ssh and see no reference to it. > This does not surprise me, I probably need an programmer's guide > with ssh APIs in it, not the sort of thing Cisco would put on its > web site. Doubtless such a thing is available in a toolkit for > Linux but that is not an area I am comfortable in. > > So instead I want a little more clarity in our documentation so that > those coming from an ssh background with an intimate knowledge of > what user@host will do for them, can see whether or not we do what > they expect. Take your average Unix system and do 'man ssh' and the user@host syntax pops up immediately. On Windows, you find graphical clients that tend to ask for Host: User: Password: and this is the same thing in a GUI. Since this is a client issue, the Cisco's of the world probably do not spend much effort documenting this (but I actually did find screenshots on Cisco web pages). SSH's user@host notation is very wide-spread if you ask me. You clearly do not need a programmer's eye to use it. > Note too that yesterday, you said > > "The point is that for notifications, access control > uses securityName to identify the notification receiver while SSH uses > the SSH user name to identify the notification sender. In many cases, > these will not be the same. So the user@host format allows to make > this important distinction. Is this understandable?" > > Understandable yes, but this appears to be the exact opposite of my > current thinking. I think that securityName identifies the > principal in the notification sender/originator and SSH user name > identifies the principal in the notification receiver. When you send a notification, the ACM filters on the identity of the receiver. We worked this out quite some time ago. In other words, I have a securityName on the NO, say "trapsink" and I apply access control such that "trapsink" only gets what it is allowed to see. When I use SSH to connect to the NR, the SSH user name is used by the NR to identify the sender of the notification while the notification sender has to verify that the hostkey matches the expected hostkey associated with the SSH transport address. So the binding between the securityName "trapsink" on the NO and the SSH transport address given by the local configuration is really the important part from the notification sender's perspective. > Which way round is going to be the expectation of all those SSH > experts? They will understand that by putting "user@host" into the SSH transport address, the NO will authenticate as "user" to the NR running on "host". This is straight forward. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Wed Mar 4 07:54:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AFF3A6B3C for ; Wed, 4 Mar 2009 07:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 JHCyQW0aLjze for ; Wed, 4 Mar 2009 07:54:17 -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 2F33F3A6AF1 for ; Wed, 4 Mar 2009 07:54:17 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA01.westchester.pa.mail.comcast.net with comcast id Nzvy1b0031GhbT8513umd2; Wed, 04 Mar 2009 15:54:46 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id P3um1b0020UQ6dC3T3umz3; Wed, 04 Mar 2009 15:54:46 +0000 From: "David Harrington" To: "'tom.petch'" , References: <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com><007901c99c09$b6cd0ce0$0601a8c0@allison><016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <01f201c99cc9$61b85640$0601a8c0@allison> Date: Wed, 4 Mar 2009 10:54:44 -0500 Message-ID: <15f501c99ce1$8a015e90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <01f201c99cc9$61b85640$0601a8c0@allison> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: Acmc0h4rnmb9j0xZQMKiQfTE2qwCcAADNk9A Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 15:54:18 -0000 Hi Tom, inline. > > I was totally confused by this whole thing myself. Then, to answer a > > question from Joe, I researched it fairly thorughly through the > > RFC341x series and realized my whole understanding was > wrong, and then > > explained it to Joe, who finally understood it. Now Tom has > a problem. > > (And I still slip into my old understanding and have to > remember this > > new approach). I expect that most operators will have an > understanding > > similar to my original understanding, which I think was the original > > intention of the SNMPv3 WG. I think we are turning things on their > > head here, and we better be sure operators understand. > > [...] > > alice is actually the sender, not the recipient. That one obviously > > slipped by. > > David, > > Actually, I see this one as ok:-) It tells me that there is > a recipient and > that the identifier for that recipient has two values, one, > alice is used in the > NO, the other, rtr-nyc4, is used in the NR. And that is the confusion I had (or have) as well. I think saying that alice is the recipient is wrong, if the bob@ format is used. In USM, the sender and recipient are the same. In SSHTM, the sender and recipient are the same, **if** a user@ address is not used. In SSHTM, if a bob@examp;e.com:PPP address is used, then alice is the sender and "bob" is the recipient. > Well, ok as in > correct, less ok as > in is it easy to read and understand. I mentally duplicate > that text replacing > recipient with originator and that is also ok ie I import the > Architecture/USM > thinking that a transaction has one principal only now we use > two different > identifiers for that principal, one in NO, the other in NR. > > Whereas, as I say in my e-mail to Juergen, I cannot get the > right meaning out of > the e-mail he posted yesterday. > > "The point is that for notifications, access control > uses securityName to identify the notification receiver while SSH uses > the SSH user name to identify the notification sender. In many cases, > these will not be the same. So the user@host format allows to make > this important distinction. Is this understandable?" > > That does seem back to front to me but perhaps there is a > reading of that that I > am missing. I believe that for notifications, SNMP uses securityname for access control for the message **sender** not the notification receiver. Because in USM the sender and receiver securityName/principal is the same, this concept of access control for the sender, not the recipient, did not come easy. And if Juergen said "access control uses securityName to identify the notification receiver", then he is also working under the same bad assumptions I was working under before I grok'd the new reality. > > Tom Petch > > > I think it is unrealistic to expect that we will have this > all sorted > > out, and find all the incorrect usages, by the end of this > week. I do > > not expect to have another revision by deadline. If Wes or Joe are > > available and in a masochistic mood, maybe they'll get another > > revision done. > > > > The next revision we publish will have to explain this whole thing > > better so we are all on the same page (see there is a > benefit to only > > having 6 people in the WG; imagine the difficulty if more > had to be on > > the same page). Text welcome. Then we can really start to > > fine-tooth-comb these documents for inconsistencies. > > > > dbh > > > > > From wjhns1@hardakers.net Wed Mar 4 08:59:47 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65FA928C243 for ; Wed, 4 Mar 2009 08:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.057, 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 odBlcE2A8wZd for ; Wed, 4 Mar 2009 08:59:46 -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 BD69E28C100 for ; Wed, 4 Mar 2009 08:59:46 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 630B139A122; Wed, 4 Mar 2009 09:00:15 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com> <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <20090304072422.GA6045@elstar.local> <15dc01c99cdd$cf1cdad0$0600a8c0@china.huawei.com> Date: Wed, 04 Mar 2009 09:00:15 -0800 In-Reply-To: <15dc01c99cdd$cf1cdad0$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 4 Mar 2009 10:28:02 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 16:59:47 -0000 >>>>> On Wed, 4 Mar 2009 10:28:02 -0500, "David Harrington" said: DH> I think there is significant work in modifying the document. I don't think so, assuming you're talking about the SSH document. In order to make the changes I made and posted yesterday (and again today) I reviewed every place that securityName was mentioned in the SSH document. There isn't a huge number of references to it and the ones I found were quickly modified. It sounds like there is "some" consensus that the TMSM document doesn't need references to the user@ syntax since it's SSH specific. If the TSM document contains an @ reference, I'd suggest we remove it. It's SSH specific. -- Wes Hardaker Sparta, Inc. From jhutz@cmu.edu Wed Mar 4 10:08:37 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9343A6D1B for ; Wed, 4 Mar 2009 10:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbkhSW+Fpzln for ; Wed, 4 Mar 2009 10:08:36 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 833563A698D for ; Wed, 4 Mar 2009 10:08:34 -0800 (PST) Received: from 68-247-180-249.pools.spcsdns.net (174-147-215-117.pools.spcsdns.net [174.147.215.117]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n24I8h7E013368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 13:08:45 -0500 (EST) Date: Wed, 04 Mar 2009 13:08:43 -0500 From: Jeffrey Hutzelman To: "tom.petch" , Wes Hardaker , isms@ietf.org Message-ID: In-Reply-To: <200903041116.n24BGZYU007374@toasties.srv.cs.cmu.edu> References: <200903041116.n24BGZYU007374@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:08:37 -0000 --On Wednesday, March 04, 2009 11:13:38 AM +0100 "tom.petch" wrote: > 5) the tmTransportAddress as passed in tmState may vary between the > outgoing and incoming messages of a transaction; this may occur when > e-mail format addresses are used Why would this ever happen? On an incoming SSH connection, the tmTransportAddress is constructed from the actual IP address and port of the remote peer and will never include a username part. The transport address used for sending a reply, if any, will always be the same as the one from which the incoming message was received. On an outgoing SSH connection, the transport address is provided by the application. Any incoming messages received on that connection should be given the same tmTransportAddress that was used to establish the connection. There is no magic here -- when you open a TCP connection, you assume any data received on it came from the peer to whom you opened the connection; you don't violate layering and examine the IP packets carrying every octet. As for the test, I fully agree with Wes's replies. -- Jeff From cfinss@dial.pipex.com Wed Mar 4 12:33:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0364428C499 for ; Wed, 4 Mar 2009 12:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] 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 Bii2giQjQ2Uu for ; Wed, 4 Mar 2009 12:33:44 -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 5F01328C498 for ; Wed, 4 Mar 2009 12:32:50 -0800 (PST) X-Trace: 81376300/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.233/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.233 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: AsAEANxzrkk+vBHp/2dsb2JhbACDIopKylwHglEMgSQG X-IronPort-AV: E=Sophos;i="4.38,302,1233532800"; d="scan'208";a="81376300" X-IP-Direction: IN Received: from 1cust233.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.233]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Mar 2009 20:33:16 +0000 Message-ID: <00f601c99cff$da5ea8c0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "Juergen Schoenwaelder" References: <0fca01c99a75$ca30d9a0$0600a8c0@china.huawei.com><0EC6E6F12C9FCFFF421435BB@atlantis.pc.cs.cmu.edu><0fdb01c99a7e$3d217750$0600a8c0@china.huawei.com><007901c99c09$b6cd0ce0$0601a8c0@allison><016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <01f201c99cc9$61b85640$0601a8c0@allison> <15f501c99ce1$8a015e90$0600a8c0@china.huawei.com> Date: Wed, 4 Mar 2009 20:26:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 20:33:45 -0000 ---- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; Cc: Sent: Wednesday, March 04, 2009 4:54 PM Subject: RE: [Isms] wg last call followup - sshtm > Hi Tom, > > > > I was totally confused by this whole thing myself. Then, to answer > a > > > question from Joe, I researched it fairly thorughly through the > > > RFC341x series and realized my whole understanding was > > wrong, and then > > > explained it to Joe, who finally understood it. Now Tom has > > a problem. > > > (And I still slip into my old understanding and have to > > remember this > > > new approach). I expect that most operators will have an > > understanding > > > similar to my original understanding, which I think was the > original > > > intention of the SNMPv3 WG. I think we are turning things on their > > > head here, and we better be sure operators understand. > > > > [...] > > > alice is actually the sender, not the recipient. That one > obviously > > > slipped by. > > > > David, > > > > Actually, I see this one as ok:-) It tells me that there is > > a recipient and > > that the identifier for that recipient has two values, one, > > alice is used in the > > NO, the other, rtr-nyc4, is used in the NR. > > And that is the confusion I had (or have) as well. I think saying that > alice is the recipient is wrong, if the bob@ format is used. > > In USM, the sender and recipient are the same. > In SSHTM, the sender and recipient are the same, **if** a user@ > address is not used. > In SSHTM, if a bob@examp;e.com:PPP address is used, then alice is the > sender and "bob" is the recipient. > Right, but as I said in the bit you elided, I am comfortable turning the roles round in my head and use sender instead of recipient in the paragraph from the tsm appendix can understand it whether alice is referred to as sender or recipient. To me, it's a philsophical tangle. I understand the mechanics and agree they work but also see that what wording makes sense may depend on somewhat abstract views of identity and identifier. So I am happy to see the wording in tsm changed as long as we spell out the mechanics so that they are clear, which I think the appendix does already. But I also want to see free standing text about this, in the main body of the I-Ds, no later than sshtm section 3, and again I think that the example of access control and Notifications needs including so that regardless of the words used, the steps an implementation must follow are unambiguous. Tom Petch > > > Well, ok as in > > correct, less ok as > > in is it easy to read and understand. I mentally duplicate > > that text replacing > > recipient with originator and that is also ok ie I import the > > Architecture/USM > > thinking that a transaction has one principal only now we use > > two different > > identifiers for that principal, one in NO, the other in NR. > > > > Whereas, as I say in my e-mail to Juergen, I cannot get the > > right meaning out of > > the e-mail he posted yesterday. > > > > "The point is that for notifications, access control > > uses securityName to identify the notification receiver while SSH > uses > > the SSH user name to identify the notification sender. In many > cases, > > these will not be the same. So the user@host format allows to make > > this important distinction. Is this understandable?" > > > > That does seem back to front to me but perhaps there is a > > reading of that that I > > am missing. > > I believe that for notifications, SNMP uses securityname for access > control for the message **sender** not the notification receiver. > > Because in USM the sender and receiver securityName/principal is the > same, this concept of access control for the sender, not the > recipient, did not come easy. And if Juergen said "access control uses > securityName to identify the notification receiver", then he is also > working under the same bad assumptions I was working under before I > grok'd the new reality. > > > > > Tom Petch > > > > > I think it is unrealistic to expect that we will have this > > all sorted > > > out, and find all the incorrect usages, by the end of this > > week. I do > > > not expect to have another revision by deadline. If Wes or Joe are > > > available and in a masochistic mood, maybe they'll get another > > > revision done. > > > > > > The next revision we publish will have to explain this whole thing > > > better so we are all on the same page (see there is a > > benefit to only > > > having 6 people in the WG; imagine the difficulty if more > > had to be on > > > the same page). Text welcome. Then we can really start to > > > fine-tooth-comb these documents for inconsistencies. > > > > > > dbh > > > > > > > > > > From cfinss@dial.pipex.com Wed Mar 4 12:33:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3590B28C498 for ; Wed, 4 Mar 2009 12:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_NJABL_PROXY=1.643] 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 44tLBYT70vtP for ; Wed, 4 Mar 2009 12:33:44 -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 54D9028C496 for ; Wed, 4 Mar 2009 12:32:49 -0800 (PST) X-Trace: 81376292/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.233/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.233 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: AsAEANxzrkk+vBHp/2dsb2JhbACDIopKumQEBY9vAQaCUAEECIEkBg X-IronPort-AV: E=Sophos;i="4.38,302,1233532800"; d="scan'208";a="81376292" X-IP-Direction: IN Received: from 1cust233.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.233]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Mar 2009 20:33:14 +0000 Message-ID: <00f501c99cff$d9308900$0601a8c0@allison> From: "tom.petch" To: References: <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <20090304072422.GA6045@elstar.local> <01f401c99cc9$63b781a0$0601a8c0@allison> <20090304154022.GC6881@elstar.local> Date: Wed, 4 Mar 2009 20:21:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 20:33:45 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "David Harrington" ; Sent: Wednesday, March 04, 2009 4:40 PM Subject: Re: [Isms] wg last call followup - sshtm > On Wed, Mar 04, 2009 at 01:59:09PM +0100, tom.petch wrote: > > > Yes, and that is a concern for me. When user@host was first mooted, > > I recall a comment, Jeff I think, that this format was a commonplace > > in ssh. This means that people will have expectations which isms may > > or may not meet. I do not know what those expectations are. I have > > trawled the documentation of various manufacturers - eg Cisco, > > Juniper - for what they can do with ssh and see no reference to it. > > This does not surprise me, I probably need an programmer's guide > > with ssh APIs in it, not the sort of thing Cisco would put on its > > web site. Doubtless such a thing is available in a toolkit for > > Linux but that is not an area I am comfortable in. > > > > So instead I want a little more clarity in our documentation so that > > those coming from an ssh background with an intimate knowledge of > > what user@host will do for them, can see whether or not we do what > > they expect. > > Take your average Unix system and do 'man ssh' and the user@host > syntax pops up immediately. On Windows, you find graphical clients > that tend to ask for > > Host: > User: > Password: > > and this is the same thing in a GUI. Since this is a client issue, the > Cisco's of the world probably do not spend much effort documenting > this (but I actually did find screenshots on Cisco web pages). SSH's I will look again > user@host notation is very wide-spread if you ask me. You clearly do > not need a programmer's eye to use it. > > > Note too that yesterday, you said > > > > "The point is that for notifications, access control > > uses securityName to identify the notification receiver while SSH uses > > the SSH user name to identify the notification sender. In many cases, > > these will not be the same. So the user@host format allows to make > > this important distinction. Is this understandable?" > > > > Understandable yes, but this appears to be the exact opposite of my > > current thinking. I think that securityName identifies the > > principal in the notification sender/originator and SSH user name > > identifies the principal in the notification receiver. > > When you send a notification, the ACM filters on the identity of the > receiver. We worked this out quite some time ago. In other words, I > have a securityName on the NO, say "trapsink" and I apply access > control such that "trapsink" only gets what it is allowed to see. > When I use SSH to connect to the NR, the SSH user name is used by the > NR to identify the sender of the notification while the notification > sender has to verify that the hostkey matches the expected hostkey > associated with the SSH transport address. So the binding between the > securityName "trapsink" on the NO and the SSH transport address given > by the local configuration is really the important part from the > notification sender's perspective. Ok, I now see that explanation too. I understand and agree the mechanics so as long as those are called out, as they are eg in the tsm appendix, then I can live with the terminology. I see the terminology of roles as more like a question of philosophy, of identity and identifiers, and as long as we get the mechanics across clearly, then the terminology actually used does not matter. I will re-read those long e-mails of Wes from 2006 again, something I do every so often, to see how our thinking on Notifications has evolved. Tom Petch > > > Which way round is going to be the expectation of all those SSH > > experts? > > They will understand that by putting "user@host" into the SSH > transport address, the NO will authenticate as "user" to the NR > running on "host". This is straight forward. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From cfinss@dial.pipex.com Wed Mar 4 12:33:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E6828C496 for ; Wed, 4 Mar 2009 12:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] 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 Tc1+T3ysGWzz for ; Wed, 4 Mar 2009 12:33:44 -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 6413E28C49A for ; Wed, 4 Mar 2009 12:32:51 -0800 (PST) X-Trace: 81376305/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.233/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.233 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: AsAEANxzrkk+vBHp/2dsb2JhbACDIopKumUHj3AHhAEGhks X-IronPort-AV: E=Sophos;i="4.38,302,1233532800"; d="scan'208";a="81376305" X-IP-Direction: IN Received: from 1cust233.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.233]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Mar 2009 20:33:18 +0000 Message-ID: <00f701c99cff$dba53280$0601a8c0@allison> From: "tom.petch" To: "Jeffrey Hutzelman" , "Wes Hardaker" , References: <200903041116.n24BGZYU007374@toasties.srv.cs.cmu.edu> Date: Wed, 4 Mar 2009 20:28:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: jhutz@cmu.edu Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 20:33:45 -0000 ----- Original Message ----- From: "Jeffrey Hutzelman" To: "tom.petch" ; "Wes Hardaker" ; Subject: Re: [Isms] Proposed text changes for the secshell draft > --On Wednesday, March 04, 2009 11:13:38 AM +0100 "tom.petch" > wrote: > > > 5) the tmTransportAddress as passed in tmState may vary between the > > outgoing and incoming messages of a transaction; this may occur when > > e-mail format addresses are used > > Why would this ever happen? On an incoming SSH connection, the > tmTransportAddress is constructed from the actual IP address and port of > the remote peer and will never include a username part. The transport > address used for sending a reply, if any, will always be the same as the > one from which the incoming message was received. > > On an outgoing SSH connection, the transport address is provided by the > application. Any incoming messages received on that connection should be > given the same tmTransportAddress that was used to establish the > connection. There is no magic here -- when you open a TCP connection, you > assume any data received on it came from the peer to whom you opened the > connection; you don't violate layering and examine the IP packets carrying > every octet. > Jeff It happens because EOPs say it happens, and I do not see a problem with it. In a Command Generator, securityName alice, transportAddress bob@example.com:port, application sends a request. As per sshtm EOP 5.1.2) " If the session is a client session, and openSession used a tmTransportAddress of the "user@example.com" format, the transportAddress passed in the receiveMessage ASI MUST match the "user@example.com" tmTransportAddress used to open the session; this will be different than the address reported by SSH for the incoming message.) and "tmTransportAddress = the address the message originated from, determined in an implementation-dependent way from SSH." which together tell me that bob@example.com:port is passed as transportAddress in the ASI while example.com:port sans bob goes in tmTransportAddress and the cache off to tsm. That is what the wording tells me; I do not have a problem with this - tsm s.5 makes no use of tmTransportAddress - but wanted to check that this was everyone else's expectation, that this is not another surprise. Thanks for checking them all Tom Petch > As for the test, I fully agree with Wes's replies. > > -- Jeff From jhutz@cmu.edu Wed Mar 4 13:45:34 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910DC28C353 for ; Wed, 4 Mar 2009 13:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 E5uWfFTUW90A for ; Wed, 4 Mar 2009 13:45:33 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 8B5AF28C32A for ; Wed, 4 Mar 2009 13:45:33 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n24LjhtF021341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 16:45:43 -0500 (EST) Date: Wed, 04 Mar 2009 16:45:43 -0500 From: Jeffrey Hutzelman To: "tom.petch" , Wes Hardaker , isms@ietf.org Message-ID: <11A5BC42A73E48477AADD4EE@minbar.fac.cs.cmu.edu> In-Reply-To: <00f701c99cff$dba53280$0601a8c0@allison> References: <200903041116.n24BGZYU007374@toasties.srv.cs.cmu.edu> <00f701c99cff$dba53280$0601a8c0@allison> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 21:45:34 -0000 --On Wednesday, March 04, 2009 08:28:35 PM +0100 "tom.petch" wrote: > ----- Original Message ----- > From: "Jeffrey Hutzelman" > To: "tom.petch" ; "Wes Hardaker" > ; > Subject: Re: [Isms] Proposed text changes for the secshell draft > >> --On Wednesday, March 04, 2009 11:13:38 AM +0100 "tom.petch" >> wrote: >> >> > 5) the tmTransportAddress as passed in tmState may vary between the >> > outgoing and incoming messages of a transaction; this may occur when >> > e-mail format addresses are used >> >> Why would this ever happen? On an incoming SSH connection, the >> tmTransportAddress is constructed from the actual IP address and port of >> the remote peer and will never include a username part. The transport >> address used for sending a reply, if any, will always be the same as the >> one from which the incoming message was received. >> >> On an outgoing SSH connection, the transport address is provided by the >> application. Any incoming messages received on that connection should be >> given the same tmTransportAddress that was used to establish the >> connection. There is no magic here -- when you open a TCP connection, >> you assume any data received on it came from the peer to whom you opened >> the connection; you don't violate layering and examine the IP packets >> carrying every octet. >> > > Jeff > > It happens because EOPs say it happens, and I do not see a problem with > it. > > In a Command Generator, securityName alice, transportAddress > bob@example.com:port, application sends a request. > > As per sshtm EOP 5.1.2) > " If > the session is a client session, and openSession used a > tmTransportAddress of the "user@example.com" format, the > transportAddress passed in the receiveMessage ASI MUST match the > "user@example.com" tmTransportAddress used to open the session; > this will be different than the address reported by SSH for the > incoming message.) This is nonsensical, and so needs to be fixed. SSH does not report an address for an incoming message; it doesn't even deal in messages at the layer at which we talk to it. On an incoming connection, SSH can generally tell you the address the client connected from. This is generally reported once, not every time you read a byte. On an outgoing connection, it's generally your problem to keep track of what you connected to. Again, SSH doesn't tell you every time you read a byte that it came from the server you connected to; remembering that is your problem. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA From wjhns1@hardakers.net Wed Mar 4 14:02:42 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5343A6D33 for ; Wed, 4 Mar 2009 14:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.054, 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 H9fK-CBFGMpF for ; Wed, 4 Mar 2009 14:02:36 -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 D7A1D3A6CB0 for ; Wed, 4 Mar 2009 14:02:32 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id A3C3639A122 for ; Wed, 4 Mar 2009 14:03:01 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Wed, 04 Mar 2009 14:03:01 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] Proposed changes to draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 22:02:42 -0000 Here are some proposed changes to the TSM document that removes the reference to the user@ in the example in appendix A. Does anyone see any issues with these changes: http://www.hardakers.net/temp/tsm-diffs.html -- Wes Hardaker Sparta, Inc. From ietfdbh@comcast.net Wed Mar 4 14:23:56 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F1E3A6CBE for ; Wed, 4 Mar 2009 14:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 n5IY4zRGrBP4 for ; Wed, 4 Mar 2009 14:23:56 -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 EF74F3A6CAB for ; Wed, 4 Mar 2009 14:23:55 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA01.westchester.pa.mail.comcast.net with comcast id P7cQ1b00W0mv7h051AQRMW; Wed, 04 Mar 2009 22:24:25 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id PAQR1b0030UQ6dC3XAQR4i; Wed, 04 Mar 2009 22:24:25 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: Date: Wed, 4 Mar 2009 17:24:23 -0500 Message-ID: <179301c99d17$f8fd2c80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmdFRPet7WCRrtVQxeRjzBlEVgi8QAArwEg Subject: Re: [Isms] Proposed changes to draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 22:23:57 -0000 I'm OK with these changes. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Wednesday, March 04, 2009 5:03 PM > To: isms@ietf.org > Subject: [Isms] Proposed changes to > draft-ietf-isms-transport-security-model > > > Here are some proposed changes to the TSM document that removes the > reference to the user@ in the example in appendix A. Does anyone see > any issues with these changes: > > http://www.hardakers.net/temp/tsm-diffs.html > > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From jhutz@cmu.edu Wed Mar 4 14:49:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC853A67F9 for ; Wed, 4 Mar 2009 14:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.326 X-Spam-Level: X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 LYfr3qE61ZoW for ; Wed, 4 Mar 2009 14:49:30 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 4CA1D3A6B44 for ; Wed, 4 Mar 2009 14:49:30 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n24MnsKZ022872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 17:49:54 -0500 (EST) Date: Wed, 04 Mar 2009 17:49:54 -0500 From: Jeffrey Hutzelman To: David Harrington , "'Wes Hardaker'" , isms@ietf.org Message-ID: <277426CDC9CFB6F9BB5895C1@minbar.fac.cs.cmu.edu> In-Reply-To: <200903042224.n24MOTNB000350@raisinbran.srv.cs.cmu.edu> References: <200903042224.n24MOTNB000350@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] Proposed changes to draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 22:49:31 -0000 --On Wednesday, March 04, 2009 05:24:23 PM -0500 David Harrington wrote: > I'm OK with these changes. Mee too From wjhns1@hardakers.net Wed Mar 4 17:31:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDE63A68E1 for ; Wed, 4 Mar 2009 17:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.051, 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 n5+zMj9kLmOC for ; Wed, 4 Mar 2009 17:31:45 -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 EE49E3A67EE for ; Wed, 4 Mar 2009 17:31:44 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D942339A124 for ; Wed, 4 Mar 2009 17:32:13 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Wed, 04 Mar 2009 17:32:13 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] Proposed SSHTM document modifications: take 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: , X-List-Received-Date: Thu, 05 Mar 2009 01:31:45 -0000 I've again modified the SSH document to take into account more of the discussion from the last 24 hours or so. The user@ text is discussed in section 3 now, with more information about the motivations and usage model. The step wording has been cleaned up a bit more since my last post. And finally, there is some new text in the security considerations to discuss the issues as well (which I rewrote at least 3 times trying to make it sound ok). Diff Comparison: http://www.hardakers.net/temp/isms-ssh.html Full draft: http://www.hardakers.net/temp/draft-ietf-isms-secshell-15wes.2.txt -- Wes Hardaker Sparta, Inc. From j.schoenwaelder@jacobs-university.de Thu Mar 5 01:48:48 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2376A28C297 for ; Thu, 5 Mar 2009 01:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.128, 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 ENoiXxUPAj4s for ; Thu, 5 Mar 2009 01:48:47 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2CE8928C285 for ; Thu, 5 Mar 2009 01:48:46 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC428C006D; Thu, 5 Mar 2009 10:49:14 +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 SzvD-na4nuSp; Thu, 5 Mar 2009 10:49: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 A68CDC00CC; Thu, 5 Mar 2009 10:49:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 63ED49D762D; Thu, 5 Mar 2009 10:49:02 +0100 (CET) Date: Thu, 5 Mar 2009 10:49:02 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090305094902.GB7971@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes to draft-ietf-isms-transport-security-model 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: , X-List-Received-Date: Thu, 05 Mar 2009 09:48:48 -0000 On Wed, Mar 04, 2009 at 02:03:01PM -0800, Wes Hardaker wrote: > > Here are some proposed changes to the TSM document that removes the > reference to the user@ in the example in appendix A. Does anyone see > any issues with these changes: > > http://www.hardakers.net/temp/tsm-diffs.html OK with me (speaking as technical contributor) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 5 01:50:15 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE1328C34A for ; Thu, 5 Mar 2009 01:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 95ems1L7ycUu for ; Thu, 5 Mar 2009 01:50:14 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 61A1F28C285 for ; Thu, 5 Mar 2009 01:50:14 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FD31C006D; Thu, 5 Mar 2009 10:50:43 +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 mRjGf1gmHxlu; Thu, 5 Mar 2009 10:50:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC5EFC0033; Thu, 5 Mar 2009 10:50:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B7F0D9D7698; Thu, 5 Mar 2009 10:50:35 +0100 (CET) Date: Thu, 5 Mar 2009 10:50:35 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090305095035.GC7971@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , isms@ietf.org References: <005601c99cb2$112ad020$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005601c99cb2$112ad020$0601a8c0@allison> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft 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: , X-List-Received-Date: Thu, 05 Mar 2009 09:50:15 -0000 On Wed, Mar 04, 2009 at 11:13:38AM +0100, tom.petch wrote: > 7) when an application uses securityName+e-mail format transportAddress with > transportDomain snmpSSHDomain, then > alice+bob@example.com:request > alice+bob@example.com:notify > bob+bob@example.com:request > bob+example.com:request > will result in four separate SSH sessions I do not know what you mean with the notations bob+bob@example.com:request so I can't tell I agree. > 8) the transportAddress MUST include a port; omitting the port is an error Why? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 5 01:55:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558FB3A690A for ; Thu, 5 Mar 2009 01:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 eTxSggfbj-ux for ; Thu, 5 Mar 2009 01:55:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 46B5B3A68FE for ; Thu, 5 Mar 2009 01:55:18 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35B35C00C2; Thu, 5 Mar 2009 10:55:47 +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 cArWSBXGtoU2; Thu, 5 Mar 2009 10:55:41 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E11DC0022; Thu, 5 Mar 2009 10:55:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 170099D76E2; Thu, 5 Mar 2009 10:55:40 +0100 (CET) Date: Thu, 5 Mar 2009 10:55:39 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090305095539.GA8180@elstar.local> Mail-Followup-To: David Harrington , "'tom.petch'" , isms@ietf.org References: <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <01f201c99cc9$61b85640$0601a8c0@allison> <15f501c99ce1$8a015e90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15f501c99ce1$8a015e90$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm 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: , X-List-Received-Date: Thu, 05 Mar 2009 09:55:19 -0000 On Wed, Mar 04, 2009 at 10:54:44AM -0500, David Harrington wrote: > > Actually, I see this one as ok:-) It tells me that there is a > > recipient and that the identifier for that recipient has two > > values, one, alice is used in the NO, the other, rtr-nyc4, is used > > in the NR. > > And that is the confusion I had (or have) as well. I think saying that > alice is the recipient is wrong, if the bob@ format is used. My understanding is that the NO creates the SSH session and this results in the following: - NO gets an authenticated SSH host identity - NR gets an authenticated SSH user name So in both cases (with or without the bob@ format), the NO does access control against a locally known securityName that is bound to an SSH transport address via local configuration and the engine has to make sure that the SSH host is getting properly authenticated before shipping the notification. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Thu Mar 5 05:53:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1856F3A6B64 for ; Thu, 5 Mar 2009 05:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 0PLfc+JHvRMf for ; Thu, 5 Mar 2009 05:53:35 -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 E15B03A6B33 for ; Thu, 5 Mar 2009 05:53:34 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA03.westchester.pa.mail.comcast.net with comcast id PNr21b0040bG4ec53Ru50g; Thu, 05 Mar 2009 13:54:05 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id PRtq1b00V0UQ6dC3PRtqB1; Thu, 05 Mar 2009 13:53:51 +0000 From: "David Harrington" To: , "'tom.petch'" References: <005601c99cb2$112ad020$0601a8c0@allison> <20090305095035.GC7971@elstar.local> Date: Thu, 5 Mar 2009 08:54:03 -0500 Message-ID: <18d101c99d99$d81bafa0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090305095035.GC7971@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: Acmdd9xVgi0T+9FZQZup6/ajYyljBAAIIwOA Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 13:53:36 -0000 Hi, > > 7) when an application uses securityName+e-mail format > transportAddress with > > transportDomain snmpSSHDomain, then > > alice+bob@example.com:request > > alice+bob@example.com:notify > > bob+bob@example.com:request > > bob+example.com:request > > will result in four separate SSH sessions Not neccessarily. > > alice+bob@example.com:request > > alice+bob@example.com:notify The transport model does not know the difference between a request and a notification. If the two addresses you provide are bob@example.com and bob@example.com, then it will presumably use the same session, not create a new one. However, if addresses require ports, and if the addresses provided are bob@example.com:161 and bob@example.com:162, then yes, these would be different addresses and require different sessions. Maybe your use of ":request" and ":notify" was meant to indicate the appropriate port#, not the message type. Have you checked the EOP that bob+bob@example.com:request and bob+example.com:request would result in different sessions? I haven't looked yet, and this one might not be clear. dbh From wjhns1@hardakers.net Thu Mar 5 06:34:21 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F38B3A69A7 for ; Thu, 5 Mar 2009 06:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.049, 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 D-NVfuFnfV5o for ; Thu, 5 Mar 2009 06:34:21 -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 107763A691A for ; Thu, 5 Mar 2009 06:34:21 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 80A2239A124; Thu, 5 Mar 2009 06:34:50 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <005601c99cb2$112ad020$0601a8c0@allison> <20090305095035.GC7971@elstar.local> <18d101c99d99$d81bafa0$0600a8c0@china.huawei.com> Date: Thu, 05 Mar 2009 06:34:50 -0800 In-Reply-To: <18d101c99d99$d81bafa0$0600a8c0@china.huawei.com> (David Harrington's message of "Thu, 5 Mar 2009 08:54:03 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 14:34:21 -0000 >>>>> On Thu, 5 Mar 2009 08:54:03 -0500, "David Harrington" said: DH> Have you checked the EOP that bob+bob@example.com:request and DH> bob+example.com:request would result in different sessions? I haven't DH> looked yet, and this one might not be clear. Can you please check the modified copies I posted late yesterday instead? -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Thu Mar 5 06:40:02 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9033A68DC for ; Thu, 5 Mar 2009 06:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.047, 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 O4nzyRW04B+p for ; Thu, 5 Mar 2009 06:40:02 -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 EECEF3A6809 for ; Thu, 5 Mar 2009 06:40:01 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 94D8039A124; Thu, 5 Mar 2009 06:40:31 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200903041116.n24BGZYU007374@toasties.srv.cs.cmu.edu> <00f701c99cff$dba53280$0601a8c0@allison> <11A5BC42A73E48477AADD4EE@minbar.fac.cs.cmu.edu> Date: Thu, 05 Mar 2009 06:40:31 -0800 In-Reply-To: <11A5BC42A73E48477AADD4EE@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 04 Mar 2009 16:45:43 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 14:40:02 -0000 >>>>> On Wed, 04 Mar 2009 16:45:43 -0500, Jeffrey Hutzelman said: >> As per sshtm EOP 5.1.2) >> " If >> the session is a client session, and openSession used a >> tmTransportAddress of the "user@example.com" format, the >> transportAddress passed in the receiveMessage ASI MUST match the >> "user@example.com" tmTransportAddress used to open the session; >> this will be different than the address reported by SSH for the >> incoming message.) JH> This is nonsensical, and so needs to be fixed. SSH does not report an JH> address for an incoming message; it doesn't even deal in messages at JH> the layer at which we talk to it. The lower level stack will report the address. You're right that the SSH protocol doesn't but the APIs do... The question is, what is the wording that it should be changed to. "...reported by the API for the incoming message." "...reported by the networking infrastructure for the incoming message." "...reported by the protocol stack for the incoming message." ... -- Wes Hardaker Sparta, Inc. From ietfdbh@comcast.net Thu Mar 5 08:25:37 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0CA828C314 for ; Thu, 5 Mar 2009 08:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 VFuPf2VSaTif for ; Thu, 5 Mar 2009 08:25:36 -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 053D43A6A76 for ; Thu, 5 Mar 2009 08:25:29 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id PNz61b0080ldTLk55US0ic; Thu, 05 Mar 2009 16:26:00 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA04.westchester.pa.mail.comcast.net with comcast id PURz1b00Q0UQ6dC3QURzBr; Thu, 05 Mar 2009 16:26:00 +0000 From: "David Harrington" To: "'Wes Hardaker'" , "'Jeffrey Hutzelman'" References: <200903041116.n24BGZYU007374@toasties.srv.cs.cmu.edu><00f701c99cff$dba53280$0601a8c0@allison><11A5BC42A73E48477AADD4EE@minbar.fac.cs.cmu.edu> Date: Thu, 5 Mar 2009 11:25:58 -0500 Message-ID: <18ee01c99daf$11465770$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmdoFhjghSZCXbwQEuF9+65HowWegADQsig Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:25:37 -0000 Hi, "...reported by the protocol stack for the session carrying the incoming message." ? "the remote address for the SSH session carrying the incoming message." ? When we act as the server and accept SSH session creation from a client, we would want to know the address of the client. But once established, the address of the session would not change. In an implementation-dependent manner, we need to get that, presumably from the SSH implementation, since it is SSH that negotiates the transport session. For incoming messages, regardless of SNMP message type, SSHTM should lookup the remote address for the SSH session and report that up the "SNMP stack". For a remote client, that address would presumably never be in the "bob@" format. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Thursday, March 05, 2009 9:41 AM > To: Jeffrey Hutzelman > Cc: isms@ietf.org > Subject: Re: [Isms] Proposed text changes for the secshell draft > > >>>>> On Wed, 04 Mar 2009 16:45:43 -0500, Jeffrey Hutzelman > said: > > >> As per sshtm EOP 5.1.2) > >> " If > >> the session is a client session, and openSession used a > >> tmTransportAddress of the "user@example.com" format, the > >> transportAddress passed in the receiveMessage ASI MUST match the > >> "user@example.com" tmTransportAddress used to open the session; > >> this will be different than the address reported by SSH for the > >> incoming message.) > > JH> This is nonsensical, and so needs to be fixed. SSH does > not report an > JH> address for an incoming message; it doesn't even deal in > messages at > JH> the layer at which we talk to it. > > The lower level stack will report the address. You're right that the > SSH protocol doesn't but the APIs do... The question is, what is the > wording that it should be changed to. > > "...reported by the API for the incoming message." > > "...reported by the networking infrastructure for the > incoming message." > > "...reported by the protocol stack for the incoming message." > > ... > > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Thu Mar 5 08:57:02 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0AD928C3CB for ; Thu, 5 Mar 2009 08:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 ZGvbnbLWrbM0 for ; Thu, 5 Mar 2009 08:57:02 -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 EFE6D28C3D4 for ; Thu, 5 Mar 2009 08:57:01 -0800 (PST) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA03.westchester.pa.mail.comcast.net with comcast id PSJJ1b00q1HzFnQ53UxYpj; Thu, 05 Mar 2009 16:57:32 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id PUxX1b00L0UQ6dC3aUxXGu; Thu, 05 Mar 2009 16:57:32 +0000 From: "David Harrington" To: References: <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <01f201c99cc9$61b85640$0601a8c0@allison> <15f501c99ce1$8a015e90$0600a8c0@china.huawei.com> <20090305095539.GA8180@elstar.local> Date: Thu, 5 Mar 2009 11:57:30 -0500 Message-ID: <18fd01c99db3$7906ded0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20090305095539.GA8180@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmdeJGHCvVZf9GgRI+a27Vr/0Uw5gAOXwkw Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:57:03 -0000 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, March 05, 2009 4:56 AM > To: David Harrington > Cc: 'tom.petch'; isms@ietf.org > Subject: Re: [Isms] wg last call followup - sshtm > > On Wed, Mar 04, 2009 at 10:54:44AM -0500, David Harrington wrote: > > > > Actually, I see this one as ok:-) It tells me that there is a > > > recipient and that the identifier for that recipient has two > > > values, one, alice is used in the NO, the other, rtr-nyc4, is used > > > in the NR. > > > > And that is the confusion I had (or have) as well. I think > saying that > > alice is the recipient is wrong, if the bob@ format is used. > > My understanding is that the NO creates the SSH session and this > results in the following: > > - NO gets an authenticated SSH host identity > - NR gets an authenticated SSH user name > > So in both cases (with or without the bob@ format), the NO does access > control against a locally known securityName that is bound to an SSH > transport address via local configuration and the engine has to make > sure that the SSH host is getting properly authenticated before > shipping the notification. OK. I do not think the draft states this adequately. Should we add a version of this last paragraph in the security considerations? in the SSH introduction? maybe section 3.3 for notifications and proxy? should we separate the notification case from the proxy case, since proxy does not do access control? What does the engine have to make sure of for proxy? dbh From wjhns1@hardakers.net Thu Mar 5 09:20:56 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5185128C17F for ; Thu, 5 Mar 2009 09:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.045, 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 SjkqBoQOsXDB for ; Thu, 5 Mar 2009 09:20:55 -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 A500028C1DE for ; Thu, 5 Mar 2009 09:20:55 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 4E2E239A129; Thu, 5 Mar 2009 09:21:25 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <007901c99c09$b6cd0ce0$0601a8c0@allison> <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <01f201c99cc9$61b85640$0601a8c0@allison> <15f501c99ce1$8a015e90$0600a8c0@china.huawei.com> <20090305095539.GA8180@elstar.local> <18fd01c99db3$7906ded0$0600a8c0@china.huawei.com> Date: Thu, 05 Mar 2009 09:21:25 -0800 In-Reply-To: <18fd01c99db3$7906ded0$0600a8c0@china.huawei.com> (David Harrington's message of "Thu, 5 Mar 2009 11:57:30 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:20:56 -0000 >>>>> On Thu, 5 Mar 2009 11:57:30 -0500, "David Harrington" said: >> So in both cases (with or without the bob@ format), the NO does DH> access >> control against a locally known securityName that is bound to an SSH >> transport address via local configuration and the engine has to make >> sure that the SSH host is getting properly authenticated before >> shipping the notification. DH> OK. I do not think the draft states this adequately. DH> Should we add a version of this last paragraph in the security DH> considerations? in the SSH introduction? maybe section 3.3 for DH> notifications and proxy? I tried to put something like that in the security considerations section for the document I posted yesterday. Does it meet your needs? DH> should we separate the notification case from the proxy case, since DH> proxy does not do access control? There are two separate cases: Clients that does access control before sending (NOs only) Those that don't (everything else) I wouldn't spell out proxies generically since they're already lumped into the other case. -- Wes Hardaker Sparta, Inc. From j.schoenwaelder@jacobs-university.de Thu Mar 5 10:12:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6722D28C4E9 for ; Thu, 5 Mar 2009 10:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.126, 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 eE+m5jNL5qhn for ; Thu, 5 Mar 2009 10:12:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 625B928C361 for ; Thu, 5 Mar 2009 10:12:17 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87BABC0109; Thu, 5 Mar 2009 19:12:46 +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 pt70aXPQzo42; Thu, 5 Mar 2009 19:12:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83AF1C00DC; Thu, 5 Mar 2009 19:12:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 518E99D8232; Thu, 5 Mar 2009 19:12:39 +0100 (CET) Date: Thu, 5 Mar 2009 19:12:39 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090305181238.GA9469@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSHTM document modifications: take 2 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: , X-List-Received-Date: Thu, 05 Mar 2009 18:12:18 -0000 On Wed, Mar 04, 2009 at 05:32:13PM -0800, Wes Hardaker wrote: > I've again modified the SSH document to take into account more of the > discussion from the last 24 hours or so. The user@ text is discussed in > section 3 now, with more information about the motivations and usage > model. The step wording has been cleaned up a bit more since my last > post. And finally, there is some new text in the security > considerations to discuss the issues as well (which I rewrote at least 3 > times trying to make it sound ok). Looks good. One small thing: Since outgoing messages may need to be sent to a different SSH principal name that does not or can not directly match the SNMPv3 security name, the SnmpSSHAddress Textual Convention specifies an optional SSH principal identity field to this mapping to occur. I suggest to replace "sent to" with "using" since the principal is really used to authenticate the NO to the NR and not the other way round. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 5 10:20:11 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401C03A692A for ; Thu, 5 Mar 2009 10:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.124, 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 PJ47AmjpqrGZ for ; Thu, 5 Mar 2009 10:20:10 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2C0483A68E3 for ; Thu, 5 Mar 2009 10:20:10 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78521C007E; Thu, 5 Mar 2009 19:20:39 +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 4ocUR8ffPF6R; Thu, 5 Mar 2009 19:20:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72702C00F4; Thu, 5 Mar 2009 19:20:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2B2989D82B3; Thu, 5 Mar 2009 19:20:32 +0100 (CET) Date: Thu, 5 Mar 2009 19:20:32 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090305182032.GA9525@elstar.local> Mail-Followup-To: Wes Hardaker , David Harrington , isms@ietf.org References: <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <01f201c99cc9$61b85640$0601a8c0@allison> <15f501c99ce1$8a015e90$0600a8c0@china.huawei.com> <20090305095539.GA8180@elstar.local> <18fd01c99db3$7906ded0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm 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: , X-List-Received-Date: Thu, 05 Mar 2009 18:20:11 -0000 On Thu, Mar 05, 2009 at 09:21:25AM -0800, Wes Hardaker wrote: > >>>>> On Thu, 5 Mar 2009 11:57:30 -0500, "David Harrington" said: > > >> So in both cases (with or without the bob@ format), the NO does > DH> access > >> control against a locally known securityName that is bound to an SSH > >> transport address via local configuration and the engine has to make > >> sure that the SSH host is getting properly authenticated before > >> shipping the notification. > > DH> OK. I do not think the draft states this adequately. > > DH> Should we add a version of this last paragraph in the security > DH> considerations? in the SSH introduction? maybe section 3.3 for > DH> notifications and proxy? > > I tried to put something like that in the security considerations > section for the document I posted yesterday. Does it meet your needs? I think the text you posted is adequate. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Thu Mar 5 12:08:39 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5597D3A6B30 for ; Thu, 5 Mar 2009 12:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.043, 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 NtyV7vMrNFwi for ; Thu, 5 Mar 2009 12:08:38 -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 B48413A6AA7 for ; Thu, 5 Mar 2009 12:08:38 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 5B48E39A129; Thu, 5 Mar 2009 12:09:08 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20090305181238.GA9469@elstar.local> Date: Thu, 05 Mar 2009 12:09:07 -0800 In-Reply-To: <20090305181238.GA9469@elstar.local> (Juergen Schoenwaelder's message of "Thu, 5 Mar 2009 19:12:39 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSHTM document modifications: take 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: , X-List-Received-Date: Thu, 05 Mar 2009 20:08:39 -0000 >>>>> On Thu, 5 Mar 2009 19:12:39 +0100, Juergen Schoenwaelder said: JS> I suggest to replace "sent to" with "using" since the principal is JS> really used to authenticate the NO to the NR and not the other way JS> round. Changed. Thanks! -- Wes Hardaker Sparta, Inc. From cfinss@dial.pipex.com Thu Mar 5 13:30:46 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A323A6BF4 for ; Thu, 5 Mar 2009 13:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, 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 k+WZwfal7JPF for ; Thu, 5 Mar 2009 13:30:45 -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 F2A943A6BEB for ; Thu, 5 Mar 2009 13:30:44 -0800 (PST) X-Trace: 191697728/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.198/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.198 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: AjYFAOvSr0k+vBPG/2dsb2JhbACDI0OKCcpUB4QBBg X-IronPort-AV: E=Sophos;i="4.38,308,1233532800"; d="scan'208";a="191697728" X-IP-Direction: IN Received: from 1cust198.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.198]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Mar 2009 21:31:11 +0000 Message-ID: <010101c99dd1$1b680f60$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "Juergen Schoenwaelder" References: <005601c99cb2$112ad020$0601a8c0@allison> <20090305095035.GC7971@elstar.local> <18d101c99d99$d81bafa0$0600a8c0@china.huawei.com> Date: Thu, 5 Mar 2009 21:22:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 21:30:46 -0000 ---- Original Message ----- From: "David Harrington" To: ; "'tom.petch'" Cc: Sent: Thursday, March 05, 2009 2:54 PM Subject: RE: [Isms] Proposed text changes for the secshell draft > > > 7) when an application uses securityName+e-mail format > > transportAddress with > > > transportDomain snmpSSHDomain, then > > > alice+bob@example.com:request > > > alice+bob@example.com:notify > > > bob+bob@example.com:request > > > bob+example.com:request > > > will result in four separate SSH sessions > > Not neccessarily. > > > > alice+bob@example.com:request > > > alice+bob@example.com:notify > > The transport model does not know the difference between a request and > a notification. If the two addresses you provide are bob@example.com > and bob@example.com, then it will presumably use the same session, not > create a new one. > > However, if addresses require ports, and if the addresses provided are > bob@example.com:161 and bob@example.com:162, then yes, these would be > different addresses and require different sessions. Maybe your use of > ":request" and ":notify" was meant to indicate the appropriate port#, > not the message type. > > Have you checked the EOP that bob+bob@example.com:request and > bob+example.com:request would result in different sessions? I haven't > looked yet, and this one might not be clear. David, Yes, my reading of the EOPs in sshtm-14 is that this last with the bobs will result in two sessions. I wanted to check that this is what is intended since for me it slightly surprising. On the question of port, I assume, as in my other e-mail to Juergen, that ports are required, basically because he, Juergen said so to you, David, so you could write the EOPs in February. And given two ports, I do not see any other way. Hence, assuming :request and :notify are different numeric values, then the EOPs say there will be two sessions. I was going to say x161 and x162 except that one of my outstanding comments is that IANA may take your request to be specifying hexadecimal so I used English but that is even less clear:-( Again, not quite what might be expected, especially that notifications and requests will always use different sessions so I want to check that this is what is wanted from the EOPs before I read the latest version from Wes(which takes me a good half day and so will be on Friday). Tom Petch > > dbh > From cfinss@dial.pipex.com Thu Mar 5 13:30:47 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D603A6AA7 for ; Thu, 5 Mar 2009 13:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.591, 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 VXEzo32gQNTf for ; Thu, 5 Mar 2009 13:30:46 -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 B787E3A6BF2 for ; Thu, 5 Mar 2009 13:30:45 -0800 (PST) X-Trace: 191697734/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.198/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.198 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: AjYFAOvSr0k+vBPG/2dsb2JhbACDI0OKCbsRCY86AQaBTIEEgTEG X-IronPort-AV: E=Sophos;i="4.38,308,1233532800"; d="scan'208";a="191697734" X-IP-Direction: IN Received: from 1cust198.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.198]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Mar 2009 21:31:12 +0000 Message-ID: <010201c99dd1$1c7c3e80$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , "Wes Hardaker" References: <016501c99c38$54f035e0$0601a8c0@allison><20090303223106.GA5648@elstar.local><14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com><01f201c99cc9$61b85640$0601a8c0@allison><15f501c99ce1$8a015e90$0600a8c0@china.huawei.com><20090305095539.GA8180@elstar.local><18fd01c99db3$7906ded0$0600a8c0@china.huawei.com> <20090305182032.GA9525@elstar.local> Date: Thu, 5 Mar 2009 21:23:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 21:30:47 -0000 I have not got round to content yet but I keep saying the mention of e-mail format addresses must appear in section 3 at the latest because that is where the identification of sessions for sshtm is introduced, 3.1.4, so introducing the e-mail format address there makes it so much clearer what is going to happen in the EOPs, it plants ideas in readers minds. Anywhere later is too late for me. The text I proposed was written to slot in there (and yes, with any enhacements dbh wants to make). Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Wes Hardaker" Cc: Sent: Thursday, March 05, 2009 7:20 PM Subject: Re: [Isms] wg last call followup - sshtm > On Thu, Mar 05, 2009 at 09:21:25AM -0800, Wes Hardaker wrote: > > >>>>> On Thu, 5 Mar 2009 11:57:30 -0500, "David Harrington" said: > > > > >> So in both cases (with or without the bob@ format), the NO does > > DH> access > > >> control against a locally known securityName that is bound to an SSH > > >> transport address via local configuration and the engine has to make > > >> sure that the SSH host is getting properly authenticated before > > >> shipping the notification. > > > > DH> OK. I do not think the draft states this adequately. > > > > DH> Should we add a version of this last paragraph in the security > > DH> considerations? in the SSH introduction? maybe section 3.3 for > > DH> notifications and proxy? > > > > I tried to put something like that in the security considerations > > section for the document I posted yesterday. Does it meet your needs? > > I think the text you posted is adequate. > > /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 cfinss@dial.pipex.com Thu Mar 5 13:30:48 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4803A6AA7 for ; Thu, 5 Mar 2009 13:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.274, 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 DttD5U6Oq7I8 for ; Thu, 5 Mar 2009 13:30:44 -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 3F0FA3A6AC0 for ; Thu, 5 Mar 2009 13:30:44 -0800 (PST) X-Trace: 191697722/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.198/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.198 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: AjYFAOvSr0k+vBPG/2dsb2JhbACDI0OKCcpUB4QBBg X-IronPort-AV: E=Sophos;i="4.38,308,1233532800"; d="scan'208";a="191697722" X-IP-Direction: IN Received: from 1cust198.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.198]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Mar 2009 21:31:09 +0000 Message-ID: <010001c99dd1$1a7d1320$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <005601c99cb2$112ad020$0601a8c0@allison> <20090305095035.GC7971@elstar.local> Date: Thu, 5 Mar 2009 21:20:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 21:30:48 -0000 Juergen Top posting on both your points. 'Omitting the port is an error' comes from last month, when, after we had agreed that sshtm would use two ports, dbh said he could not write the EOPs because he did not know how sshtm knew which one to use whereat you, Juergen, replied "The SnmpUDPAddress always contains a port number and the same is true for the formats defined in RFC 3419. So once you have an TAddress, everything should be fine." and indeed that is how I read the TC, user@ is optional, port is not, in sshtm And I see nothing about using a default port if one is not specified. So, I think from this that transportAddress will always include a port even though this is not specified in the body of the I-Ds, only implicit in the TC. If it does not, then I do not know how sshtm/ssh know which port to use. On the other point, my notation is securityName + transportAddress so I am saying that if an CG application uses securityName bob transportAddress bob@example.com:request and later securityName bob transportAddress example.com:request then this will send traffic over two separate ssh sessions. This is what I read in the EOPs and indeed, it is quite hard to do anything else assuming that responses must come back over the same session as the request with the same parameters to the application. But I wanted to check that this was not a surprise to some of us. If this is not intended, then what is? because we have more work to do. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "Wes Hardaker" ; Sent: Thursday, March 05, 2009 10:50 AM Subject: Re: [Isms] Proposed text changes for the secshell draft > On Wed, Mar 04, 2009 at 11:13:38AM +0100, tom.petch wrote: > > > 7) when an application uses securityName+e-mail format transportAddress with > > transportDomain snmpSSHDomain, then > > alice+bob@example.com:request > > alice+bob@example.com:notify > > bob+bob@example.com:request > > bob+example.com:request > > will result in four separate SSH sessions > > I do not know what you mean with the notations > bob+bob@example.com:request so I can't tell I agree. > > > 8) the transportAddress MUST include a port; omitting the port is an error > > Why? > > /js From jhutz@cmu.edu Thu Mar 5 13:35:51 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75313A68E3 for ; Thu, 5 Mar 2009 13:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 9f1mCW+GKUXu for ; Thu, 5 Mar 2009 13:35:51 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id DD18F3A6BC2 for ; Thu, 5 Mar 2009 13:35:50 -0800 (PST) Received: from 68-247-180-249.pools.spcsdns.net (173-101-73-244.pools.spcsdns.net [173.101.73.244]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n25LaGr2024369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 16:36:18 -0500 (EST) Date: Thu, 05 Mar 2009 16:36:16 -0500 From: Jeffrey Hutzelman To: isms@ietf.org Message-ID: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: [Isms] SSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 21:35:51 -0000 draft-ietf-isms-secshell-14.txt section 4.1.1 contains the following: 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 an SSH identity to a tmSecurityName, or to transform a tmSecurityName to an SSH identity. 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. This is not true; it is a misinterpretation of the details of operation of a particular SSH user authentication method which happen below the abstraction visible to SSHTM. While the GSS-API user authentication method described in RFC4462 does allow the "username" field on the wire to be empty, this is permitted only in cases where the SSH server (NOT a subsystem such as SNMP) is able to infer a username from the client's GSS-API credentials. SSH will always report an authenticated username. Similarly, if the SSH server allows the connection, it has determined that the client is authorized for the requested username. The claim that "the user name may not be verified by the server" would seem to be a reference to the "none" user authentication method, in which the server may choose to allow access with no further authentication. This is functionally equivalent to using password authentication but allowing any password, or using a well-known SNMP community string like "public" -- weak, but operating as designed. In no case should SSHTM "obtain the user name from other credentials exchanged during the SSH exchange"; this would be a serious violation of the abstraction boundary between SSHTM and SSH. I propose to eliminate these two paragraphs, and make the following change: OLD: On the SSH server side of a connection: The tmSecurityName SHOULD be the value of the user name field of the SSH_MSG_USERAUTH_REQUEST message for which a SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH user name is extracted from the SSH layer is implementation-dependent. NEW: On the SSH server side of a connection: The tmSecurityName SHOULD be the SSH user name. How the SSH user name is extracted from the SSH later is implementation-dependent. This eliminates the inappropriate reference to details of the SSH protocol, which is also an abstraction violation. SSHTM has no business knowing that the username came from a particular field of a particular SSH protocol message, especially when that may not actually be the case. -- Jeff From wjhns1@hardakers.net Thu Mar 5 13:49:20 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5683D3A682D for ; Thu, 5 Mar 2009 13:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.041, 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 roRuTOkQuxql for ; Thu, 5 Mar 2009 13:49:19 -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 9827F3A6849 for ; Thu, 5 Mar 2009 13:49:19 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 92FD839A129; Thu, 5 Mar 2009 13:49:49 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <005601c99cb2$112ad020$0601a8c0@allison> <20090305095035.GC7971@elstar.local> <010001c99dd1$1a7d1320$0601a8c0@allison> Date: Thu, 05 Mar 2009 13:49:49 -0800 In-Reply-To: <010001c99dd1$1a7d1320$0601a8c0@allison> (tom petch's message of "Thu, 5 Mar 2009 21:20:19 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 21:49:20 -0000 >>>>> On Thu, 5 Mar 2009 21:20:19 +0100, "tom.petch" said: tp> Top posting on both your points. I'm inline-posting in yours :-) tp> indeed that is how I read the TC, user@ is optional, port is not, in tp> sshtm That's definitely how the current TC is worded (and should be). They're a hostname followed by a ':' and a decimal port number. I think we are all in agreement about this at this point. tp> So, I think from this that transportAddress will always include a port tp> even though this is not specified in the body of the I-Ds, only tp> implicit in the TC. I actually think (whether it was intentional or not) this is a good thing. The EOPs should generically say "get the addressing information from the passed tmTransportAddress so that future TCs can be written to support IPv16 without rewriting the EOPs. tp> On the other point, my notation is securityName + transportAddress so tp> I am saying that if an CG application uses securityName bob tp> transportAddress bob@example.com:request and later securityName bob tp> transportAddress example.com:request then this will send traffic over tp> two separate ssh sessions. That is true. It could be rewritten to check for string matches, but honestly I think that would only make the wording even more confusing to account for that case. All other cases where tmSecurityName != user[@] MUST result in a different sessions for each (for security assurances). It'd be a pain to write not just because of the string comparison, but also because the transportAddress that gets handed back up would need to match the request that went out so you didn't confuse the application. It'd be easier, implementation and documentation-wise, to mandate that the transportAddress is always identical or else a new session is created. -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Thu Mar 5 13:50:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156DA3A6849 for ; Thu, 5 Mar 2009 13:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.040, 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 j2z-vvcCA0B0 for ; Thu, 5 Mar 2009 13:50:30 -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 6814D3A682D for ; Thu, 5 Mar 2009 13:50:30 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 621E239A129; Thu, 5 Mar 2009 13:51:00 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <016501c99c38$54f035e0$0601a8c0@allison> <20090303223106.GA5648@elstar.local> <14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com> <01f201c99cc9$61b85640$0601a8c0@allison> <15f501c99ce1$8a015e90$0600a8c0@china.huawei.com> <20090305095539.GA8180@elstar.local> <18fd01c99db3$7906ded0$0600a8c0@china.huawei.com> <20090305182032.GA9525@elstar.local> <010201c99dd1$1c7c3e80$0601a8c0@allison> Date: Thu, 05 Mar 2009 13:51:00 -0800 In-Reply-To: <010201c99dd1$1c7c3e80$0601a8c0@allison> (tom petch's message of "Thu, 5 Mar 2009 21:23:29 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 21:50:31 -0000 >>>>> On Thu, 5 Mar 2009 21:23:29 +0100, "tom.petch" said: tp> I have not got round to content yet but I keep saying the mention of tp> e-mail format addresses must appear in section 3 at the latest tp> because that is where the identification of sessions for sshtm is tp> introduced And I can tell you haven't read it yet, because it's discussed there now. -- Wes Hardaker Sparta, Inc. From jhutz@cmu.edu Thu Mar 5 13:59:55 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0963E3A694E for ; Thu, 5 Mar 2009 13:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 XjmUANjRL4dl for ; Thu, 5 Mar 2009 13:59:54 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 0391A3A69E8 for ; Thu, 5 Mar 2009 13:59:53 -0800 (PST) Received: from 68-247-180-249.pools.spcsdns.net (173-101-73-244.pools.spcsdns.net [173.101.73.244]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n25M08RK025138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 17:00:10 -0500 (EST) Date: Thu, 05 Mar 2009 17:00:08 -0500 From: Jeffrey Hutzelman To: David Harrington , j.schoenwaelder@jacobs-university.de, "'tom.petch'" Message-ID: In-Reply-To: <200903051354.n25Ds98K011695@raisinbran.srv.cs.cmu.edu> References: <005601c99cb2$112ad020$0601a8c0@allison> <20090305095035.GC7971@elstar.local> <200903051354.n25Ds98K011695@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 21:59:55 -0000 --On Thursday, March 05, 2009 08:54:03 AM -0500 David Harrington wrote: > Hi, > > >> > 7) when an application uses securityName+e-mail format >> transportAddress with >> > transportDomain snmpSSHDomain, then >> > alice+bob@example.com:request >> > alice+bob@example.com:notify >> > bob+bob@example.com:request >> > bob+example.com:request >> > will result in four separate SSH sessions > > Not neccessarily. > >> > alice+bob@example.com:request >> > alice+bob@example.com:notify > > The transport model does not know the difference between a request and > a notification. If the two addresses you provide are bob@example.com > and bob@example.com, then it will presumably use the same session, not > create a new one. > > However, if addresses require ports, and if the addresses provided are > bob@example.com:161 and bob@example.com:162, then yes, these would be > different addresses and require different sessions. Maybe your use of > ":request" and ":notify" was meant to indicate the appropriate port#, > not the message type. > > Have you checked the EOP that bob+bob@example.com:request and > bob+example.com:request would result in different sessions? I haven't > looked yet, and this one might not be clear. I believe the notation tom is using here is "securityname+transportaddress" with the transport address written as "[user@]host:port", as specified. In this model, yes, the tour examples given result in distinct sessions, because none of them have both the same securityName and the same transportAddress. The fact that "bob+bob@example.com:request" and "bob+example.com:request" will result in making SSH connections to the same host and port and using the same SSH username does _not_ make the SNMP transport addresses the same -- "bob@example.com:request" and "example.com:request" are still different. I believe the EOP are clear on this point. Particularly, section 5.2, step 4 says the following: 4. If there is no existing session corresponding to the tmTransportAddress and tmSecurityName, then call openSession() with the tmStateReference as a parameter. I do believe there are some ambiguities in that section, however. Wes's recent proposed changes address some of these, but not all: - The EOP are quite clear on what happens if there is _not_ an existing session, in steps 3 and 4, but nowhere is it stated that if there _is_ an existing session, it should be used. Particularly... + There does not appear to be any step which verifies that destTransportDomain and destTransportAddress are the same as the tmTransportDomain and tmTransportAddress obtained via the tmStateReference. + There does not appear to be any step which verifies that the destTransportDomain and tmTransportDomain are SSHTM. Is such a check required? + In step 3, if tmSameSecurity is true, we should search for a session which matches tmSessionID. If no such session is found, we should fail as currently described. If a session _is_ found, and does not match the tmTransportAddress and tmSecurityName, then we should also fail. If a session is found and matches, then we skip to step 5. Wes's changes check tmSecurityName, but not tmTransportAddress. + In step 4, if tmSameSecurity is not true, we should search for a session which matches the tmTransportAddress and tmSecurityName, and if one is found, use it. If no session is found, openSession is called as currently described. + Step 4(2) records the destTransportDomain, destTransportAddress, and tmsessionID, but not the tmSecurityName. We really should be recording this in the session cache if we're going to look at it later, and additionally, we need it if we're going to use it to populate a tmStateReference cache as described in the EOP in section 5.1. The new step 7 added by Wes's changes may be sufficient to address this. -- Jeff From j.schoenwaelder@jacobs-university.de Thu Mar 5 14:01:20 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DB328C14F for ; Thu, 5 Mar 2009 14:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=-0.179, 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 h8cS4FpguMeN for ; Thu, 5 Mar 2009 14:01: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 AB79B3A6ACA for ; Thu, 5 Mar 2009 14:01:19 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 323B9C0199; Thu, 5 Mar 2009 23:01:49 +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 bh8Czty7bix5; Thu, 5 Mar 2009 23:01:42 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFA71C019A; Thu, 5 Mar 2009 23:01:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BB5099D86C6; Thu, 5 Mar 2009 23:01:41 +0100 (CET) Date: Thu, 5 Mar 2009 23:01:41 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090305220141.GC9885@elstar.local> Mail-Followup-To: "tom.petch" , Wes Hardaker , isms@ietf.org References: <005601c99cb2$112ad020$0601a8c0@allison> <20090305095035.GC7971@elstar.local> <010001c99dd1$1a7d1320$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010001c99dd1$1a7d1320$0601a8c0@allison> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft 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: , X-List-Received-Date: Thu, 05 Mar 2009 22:01:21 -0000 On Thu, Mar 05, 2009 at 09:20:19PM +0100, tom.petch wrote: > 'Omitting the port is an error' comes from last month, when, after we had > agreed that sshtm would use two ports, dbh said he could not write the EOPs > because he did not know how sshtm knew which one to use whereat you, Juergen, > replied > "The SnmpUDPAddress always contains a port number and the same is true > for the formats defined in RFC 3419. So once you have an TAddress, > everything should be fine." > and indeed that is how I read the TC, user@ is optional, port is not, in sshtm > > And I see nothing about using a default port if one is not specified. > > So, I think from this that transportAddress will always include a port even > though this is not specified in the body of the I-Ds, only implicit in the TC. > > If it does not, then I do not know how sshtm/ssh know which port to use. Good. So I got things right back then when I wrote my response to dbh. > On the other point, my notation is securityName + transportAddress so I am > saying that if an CG application uses > securityName bob transportAddress bob@example.com:request > and later > securityName bob transportAddress example.com:request > then this will send traffic over two separate ssh sessions. > > This is what I read in the EOPs and indeed, it is quite hard to do > anything else assuming that responses must come back over the same > session as the request with the same parameters to the application. > But I wanted to check that this was not a surprise to some of us. > If this is not intended, then what is? because we have more work to > do. So are you saying we are in agreement? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Thu Mar 5 21:52:03 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FC53A6991 for ; Thu, 5 Mar 2009 21:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 Zg-eUF8Hdgy0 for ; Thu, 5 Mar 2009 21:52:02 -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 7617E3A68E7 for ; Thu, 5 Mar 2009 21:52:02 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA01.westchester.pa.mail.comcast.net with comcast id Phcw1b0030vyq2s51hsZuP; Fri, 06 Mar 2009 05:52:33 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id PhsY1b00B0UQ6dC3RhsY8V; Fri, 06 Mar 2009 05:52:33 +0000 From: "David Harrington" To: "'Wes Hardaker'" References: <007901c99c09$b6cd0ce0$0601a8c0@allison><016501c99c38$54f035e0$0601a8c0@allison><20090303223106.GA5648@elstar.local><14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com><01f201c99cc9$61b85640$0601a8c0@allison><15f501c99ce1$8a015e90$0600a8c0@china.huawei.com><20090305095539.GA8180@elstar.local><18fd01c99db3$7906ded0$0600a8c0@china.huawei.com> Date: Fri, 6 Mar 2009 00:52:31 -0500 Message-ID: <19b001c99e1f$bde50f10$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmdttDVFRXn5Wm8Qsa71at7Wg9qMwAAI9Zg Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 05:52:04 -0000 > DH> Should we add a version of this last paragraph in the security > DH> considerations? in the SSH introduction? maybe section 3.3 for > DH> notifications and proxy? > > I tried to put something like that in the security considerations > section for the document I posted yesterday. Does it meet your needs? section 3.3: s/perform proxy/receive proxied messages/ local access control is only done for the NO. It is not done for a proxied message, even if that proxied message is a notification. /connection can succeed/connection is available or can be opened/ I recommend replacing the paragraph "Since outgoing messages may need" with a paragraph explaining a common use case, another describing client session establishment, and a third that discusses lifetime of the association. Since outgoing messages may need to be sent to a different SSH principal name that does not or can not directly match the SNMPv3 security name, the SnmpSSHAddress specifies an [...] Because naming policies might differ between administrative domains, many SSH client software packages support a user@hostname:port addressing syntax that operators can use to align non-equivalent account names. The SnmpSSHAddress Textual Convention supports this common SSH notation. When this notation is used in an SnmpSSHAddress, the SSH client uses the "user" portion of the notation as the principal when establishing a session with the remote SSH server. The "user" portion may or may not match the tmSecurityName parameter passed from the security model. If no "user@" portion is specified in the SnmpSSHAddress, then the SSH client uses the tmSecurityName as the principal when establishing a session with the remote SSH server. The SnmpSSHAddress and tmSecurityName associated with an SSH session MUST remain constant during the life of the session. Different SnmpSSHAddress values (with different hostnames, "user@" prefix names and/or port numbers) will each result in individual SSH sessions. section 4.1.1 I moved the lifetime association of session vs tmSecurityName into section 3.3, where the lifetime associaiton of SnmpSSHAddress is discussed, so the second sentence in section 4.1.1 is not necessary. possibly more later. > > DH> should we separate the notification case from the proxy > case, since > DH> proxy does not do access control? > > There are two separate cases: > > Clients that does access control before sending (NOs only) > Those that don't (everything else) > > I wouldn't spell out proxies generically since they're already lumped > into the other case. But in section 3.3, the NO and proxy are lumped together. > -- > Wes Hardaker > Sparta, Inc. > From j.schoenwaelder@jacobs-university.de Fri Mar 6 00:22:52 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352733A6BAE for ; Fri, 6 Mar 2009 00:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.125, 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 IENXrzk43F14 for ; Fri, 6 Mar 2009 00:22:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DB89E3A6901 for ; Fri, 6 Mar 2009 00:22:50 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B18C1C0217; Fri, 6 Mar 2009 09:23:20 +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 zrStTS-YQzXt; Fri, 6 Mar 2009 09:23: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 2E9E5C013E; Fri, 6 Mar 2009 09:23:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1EBE49D8E93; Fri, 6 Mar 2009 09:23:13 +0100 (CET) Date: Fri, 6 Mar 2009 09:23:12 +0100 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20090306082312.GC10332@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , isms@ietf.org References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] SSH always provides a username 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: , X-List-Received-Date: Fri, 06 Mar 2009 08:22:52 -0000 On Thu, Mar 05, 2009 at 04:36:16PM -0500, Jeffrey Hutzelman wrote: > draft-ietf-isms-secshell-14.txt section 4.1.1 contains the following: > > 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 an SSH identity to a > tmSecurityName, or to transform a tmSecurityName to an SSH > identity. > > 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. > > > This is not true; it is a misinterpretation of the details of operation > of a particular SSH user authentication method which happen below the > abstraction visible to SSHTM. While the GSS-API user authentication > method described in RFC4462 does allow the "username" field on the wire > to be empty, this is permitted only in cases where the SSH server (NOT a > subsystem such as SNMP) is able to infer a username from the client's > GSS-API credentials. SSH will always report an authenticated username. > > Similarly, if the SSH server allows the connection, it has determined > that the client is authorized for the requested username. The claim that > "the user name may not be verified by the server" would seem to be a > reference to the "none" user authentication method, in which the server > may choose to allow access with no further authentication. This is > functionally equivalent to using password authentication but allowing any > password, or using a well-known SNMP community string like "public" -- > weak, but operating as designed. > > In no case should SSHTM "obtain the user name from other credentials > exchanged during the SSH exchange"; this would be a serious violation of > the abstraction boundary between SSHTM and SSH. > > I propose to eliminate these two paragraphs, and make the following change: > > OLD: > > On the SSH server side of a connection: > > The tmSecurityName SHOULD be the value of the user name field of > the SSH_MSG_USERAUTH_REQUEST message for which a > SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH user name is > extracted from the SSH layer is implementation-dependent. > > NEW: > > On the SSH server side of a connection: > > The tmSecurityName SHOULD be the SSH user name. How the SSH user > name is extracted from the SSH later is implementation-dependent. > > > This eliminates the inappropriate reference to details of the SSH > protocol, which is also an abstraction violation. SSHTM has no business > knowing that the username came from a particular field of a particular > SSH protocol message, especially when that may not actually be the case. Thanks Jeff for clarifying what we can expect to be provided by the SSH layer. This is good news as it makes our documents simpler. Editors, please take care of these changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Pasi.Eronen@nokia.com Fri Mar 6 01:58:07 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933923A6A93 for ; Fri, 6 Mar 2009 01:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 aRtmudOIxFzH for ; Fri, 6 Mar 2009 01:58:06 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 18C343A6BCE for ; Fri, 6 Mar 2009 01:58:04 -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 n269wPcD031062; Fri, 6 Mar 2009 03:58:29 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 11:58:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 11:58:20 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 6 Mar 2009 10:58:20 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Fri, 6 Mar 2009 10:58:20 +0100 From: To: , Date: Fri, 6 Mar 2009 10:58:19 +0100 Thread-Topic: [Isms] Proposed changes to draft-ietf-isms-transport-security-model Thread-Index: AcmdFRd0YtJiLrOlQe6OhqahEiJA8ABK+1xA Message-ID: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2009 09:58:20.0802 (UTC) FILETIME=[14A2E620:01C99E42] X-Nokia-AV: Clean Subject: Re: [Isms] Proposed changes to draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 09:58:07 -0000 Wes, I do not like this change -- it will make the example considerably harder to understand, since the reader can't possibly figure out=20 how the NO actually initiates the SSH connection (since it requires a SSH user name, and it's certainly not "alice"). While user@host syntax is indeed specific to SSHTM, this particular example *is* about SSHTM. And transport addresses are *always* specific=20 to some TM, so any example showing a transport address will be specific=20 to some TM. (There's no requirement that TMs use the ":" syntax; e.g. a DCCP-based TM would need a syntax that includes the DCCP=20 service code, and HTTP-based TM would use URIs.) Best regards, Pasi > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > Behalf Of ext Wes Hardaker > Sent: 05 March, 2009 00:03 > To: isms@ietf.org > Subject: [Isms] Proposed changes to=20 > draft-ietf-isms-transport-security-model >=20 >=20 > Here are some proposed changes to the TSM document that removes the > reference to the user@ in the example in appendix A. Does anyone see > any issues with these changes: >=20 > http://www.hardakers.net/temp/tsm-diffs.html >=20 > --=20 > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > = From cfinss@dial.pipex.com Fri Mar 6 03:53:59 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737A03A69ED for ; Fri, 6 Mar 2009 03:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 fIHD-nwRjodK for ; Fri, 6 Mar 2009 03:53:58 -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 432233A686E for ; Fri, 6 Mar 2009 03:53:58 -0800 (PST) X-Trace: 225875528/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.96/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.96 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: AkoFAOOdsEk+vBFg/2dsb2JhbACDIjESigm7JgMEjxQHglEECIEkBoZY X-IronPort-AV: E=Sophos;i="4.38,314,1233532800"; d="scan'208";a="225875528" X-IP-Direction: IN Received: from 1cust96.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.96]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Mar 2009 11:54:26 +0000 Message-ID: <000601c99e49$b2c18d00$0601a8c0@allison> From: "tom.petch" To: "Jeffrey Hutzelman" , References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> Date: Fri, 6 Mar 2009 10:21:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: jhutz@cmu.edu Subject: Re: [Isms] SSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 11:53:59 -0000 ---- Original Message ----- From: "Jeffrey Hutzelman" To: Cc: Sent: Thursday, March 05, 2009 10:36 PM Subject: [Isms] SSH always provides a username > draft-ietf-isms-secshell-14.txt section 4.1.1 contains the following: > > 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 an SSH identity to a > tmSecurityName, or to transform a tmSecurityName to an SSH > identity. > > 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. > > This is not true; it is a misinterpretation of the details of operation of > a particular SSH user authentication method which happen below the > abstraction visible to SSHTM. While the GSS-API user authentication method > described in RFC4462 does allow the "username" field on the wire to be > empty, this is permitted only in cases where the SSH server (NOT a > subsystem such as SNMP) is able to infer a username from the client's > GSS-API credentials. SSH will always report an authenticated username. > > Similarly, if the SSH server allows the connection, it has determined that > the client is authorized for the requested username. The claim that "the > user name may not be verified by the server" would seem to be a reference > to the "none" user authentication method, in which the server may choose to > allow access with no further authentication. This is functionally > equivalent to using password authentication but allowing any password, or > using a well-known SNMP community string like "public" -- weak, but > operating as designed. > > In no case should SSHTM "obtain the user name from other credentials > exchanged during the SSH exchange"; this would be a serious violation of > the abstraction boundary between SSHTM and SSH. > > I propose to eliminate these two paragraphs, and make the following change: > > OLD: > > On the SSH server side of a connection: > > The tmSecurityName SHOULD be the value of the user name field of > the SSH_MSG_USERAUTH_REQUEST message for which a > SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH user name is > extracted from the SSH layer is implementation-dependent. > > NEW: > > On the SSH server side of a connection: > > The tmSecurityName SHOULD be the SSH user name. How the SSH user > name is extracted from the SSH later is implementation-dependent. > > > This eliminates the inappropriate reference to details of the SSH protocol, > which is also an abstraction violation. SSHTM has no business knowing that > the username came from a particular field of a particular SSH protocol > message, especially when that may not actually be the case. > Jeff What you say seems fine but I find this horribly difficult, especially over e-mail. I do not know enough about ssh to know whether your words are more accurate or not. What I do know is that the current wording was supplied by Joe Salowey (28nov2008) and when he did, I annotated my copy of sshtm with comment 'supplied by Joe so must be right' ie I do not know enough to judge the accuracy of this. This text was proposed in response to a difficulty so it is there for a reason. You and Joe both know much more about ssh than I and when you say what I perceive to be different things, I struggle to know which to support. I look in other places - you contributed more on the ssh list but I see more of Joe contributing outside the IETF - and find myelf on the fence. Perhaps the 'proper' resolution is for Joe to speak up and say, yes, this is fine but I cannot rely on that happening. The worst outcome is that, during a future review, Joe speaks up and says change it back again because .... So, I am on the fence, and not comfortable with it. Tom Petch > -- Jeff > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From cfinss@dial.pipex.com Fri Mar 6 03:54:00 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7769F28C1E2 for ; Fri, 6 Mar 2009 03:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.551, 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 6H5-jQAY+gng for ; Fri, 6 Mar 2009 03:53:59 -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 5BFED3A6920 for ; Fri, 6 Mar 2009 03:53:59 -0800 (PST) X-Trace: 225875536/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.96/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.96 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: AkoFAOOdsEk+vBFg/2dsb2JhbACDIjESigm7HgiPGweCSQiBMAY X-IronPort-AV: E=Sophos;i="4.38,314,1233532800"; d="scan'208";a="225875536" X-IP-Direction: IN Received: from 1cust96.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.96]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Mar 2009 11:54:27 +0000 Message-ID: <000701c99e49$b42b2f20$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <005601c99cb2$112ad020$0601a8c0@allison><20090305095035.GC7971@elstar.local><010001c99dd1$1a7d1320$0601a8c0@allison> Date: Fri, 6 Mar 2009 10:30:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 11:54:00 -0000 ---- Original Message ----- From: "Wes Hardaker" To: "tom.petch" Cc: "Juergen Schoenwaelder" ; "Wes Hardaker" ; Sent: Thursday, March 05, 2009 10:49 PM Subject: Re: Proposed text changes for the secshell draft > >>>>> On Thu, 5 Mar 2009 21:20:19 +0100, "tom.petch" said: > > tp> Top posting on both your points. > > I'm inline-posting in yours :-) > > tp> indeed that is how I read the TC, user@ is optional, port is not, in > tp> sshtm > > That's definitely how the current TC is worded (and should be). They're > a hostname followed by a ':' and a decimal port number. > > I think we are all in agreement about this at this point. > > tp> So, I think from this that transportAddress will always include a port > tp> even though this is not specified in the body of the I-Ds, only > tp> implicit in the TC. > > I actually think (whether it was intentional or not) this is a good > thing. The EOPs should generically say "get the addressing information > from the passed tmTransportAddress so that future TCs can be written to > support IPv16 without rewriting the EOPs. > > tp> On the other point, my notation is securityName + transportAddress so > tp> I am saying that if an CG application uses securityName bob > tp> transportAddress bob@example.com:request and later securityName bob > tp> transportAddress example.com:request then this will send traffic over > tp> two separate ssh sessions. > > That is true. It could be rewritten to check for string matches, but > honestly I think that would only make the wording even more confusing to > account for that case. All other cases where tmSecurityName != user[@] > MUST result in a different sessions for each (for security assurances). > > It'd be a pain to write not just because of the string comparison, but > also because the transportAddress that gets handed back up would need to > match the request that went out so you didn't confuse the application. > It'd be easier, implementation and documentation-wise, to mandate that > the transportAddress is always identical or else a new session is created. > -- Yes, I believe we are in agreement:-) I am not lookng for any changes to the written text EXCEPT that whereever we give an example of a (tm)transportAddtress we always include the port which most if not all of the current text does not do. This was why I raised it; a less experienced reader might see all those addresses with no port and think that no port was an option and struggle with the TC which says otherwise (don't know why, SMIv2 is a superb modelling language:-) And including the port is something you said you would do in your first response to my list of eight points. So yes, all looks good on that. Tom Petch > Wes Hardaker > Sparta, Inc. From cfinss@dial.pipex.com Fri Mar 6 03:54:02 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9242128C213 for ; Fri, 6 Mar 2009 03:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.237, 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 Ek-KYKGUkceD for ; Fri, 6 Mar 2009 03:54:01 -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 264D43A691D for ; Fri, 6 Mar 2009 03:54:00 -0800 (PST) X-Trace: 225875549/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.96/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.96 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: AkoFAOOdsEk+vBFg/2dsb2JhbACDIjESigm7JQmPEwEGglCBMQY X-IronPort-AV: E=Sophos;i="4.38,314,1233532800"; d="scan'208";a="225875549" X-IP-Direction: IN Received: from 1cust96.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.96]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Mar 2009 11:54:30 +0000 Message-ID: <000801c99e49$b53f5e40$0601a8c0@allison> From: "tom.petch" To: References: <005601c99cb2$112ad020$0601a8c0@allison> <20090305095035.GC7971@elstar.local> <010001c99dd1$1a7d1320$0601a8c0@allison> <20090305220141.GC9885@elstar.local> Date: Fri, 6 Mar 2009 10:34:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 11:54:02 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "Wes Hardaker" ; Sent: Thursday, March 05, 2009 11:01 PM Subject: Re: [Isms] Proposed text changes for the secshell draft > On Thu, Mar 05, 2009 at 09:20:19PM +0100, tom.petch wrote: > > > 'Omitting the port is an error' comes from last month, when, after we had > > agreed that sshtm would use two ports, dbh said he could not write the EOPs > > because he did not know how sshtm knew which one to use whereat you, Juergen, > > replied > > "The SnmpUDPAddress always contains a port number and the same is true > > for the formats defined in RFC 3419. So once you have an TAddress, > > everything should be fine." > > and indeed that is how I read the TC, user@ is optional, port is not, in sshtm > > > > And I see nothing about using a default port if one is not specified. > > > > So, I think from this that transportAddress will always include a port even > > though this is not specified in the body of the I-Ds, only implicit in the TC. > > > > If it does not, then I do not know how sshtm/ssh know which port to use. > > Good. So I got things right back then when I wrote my response to dbh. > > > On the other point, my notation is securityName + transportAddress so I am > > saying that if an CG application uses > > securityName bob transportAddress bob@example.com:request > > and later > > securityName bob transportAddress example.com:request > > then this will send traffic over two separate ssh sessions. > > > > This is what I read in the EOPs and indeed, it is quite hard to do > > anything else assuming that responses must come back over the same > > session as the request with the same parameters to the application. > > But I wanted to check that this was not a surprise to some of us. > > If this is not intended, then what is? because we have more work to > > do. > > So are you saying we are in agreement? Yes, but as I say to Wes, I want all our examples of (tm)transportAddress to include a port lest this mislead; and Wes has already agreed to do this. I was not seeing any great need to add explicit text about the port being required but would not object if it was there. Tom > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From cfinss@dial.pipex.com Fri Mar 6 03:54:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1789A28C223 for ; Fri, 6 Mar 2009 03:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.531, 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 bQy2D+4Vq+no for ; Fri, 6 Mar 2009 03:54:04 -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 DA58228C220 for ; Fri, 6 Mar 2009 03:54:03 -0800 (PST) X-Trace: 225875561/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.96/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.96 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: AkoFAOOdsEk+vBFg/2dsb2JhbACDIjESigm7HgiPGweCSQiBMAY X-IronPort-AV: E=Sophos;i="4.38,314,1233532800"; d="scan'208";a="225875561" X-IP-Direction: IN Received: from 1cust96.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.96]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Mar 2009 11:54:31 +0000 Message-ID: <000901c99e49$b68f0fc0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Wes Hardaker'" References: <007901c99c09$b6cd0ce0$0601a8c0@allison><016501c99c38$54f035e0$0601a8c0@allison><20090303223106.GA5648@elstar.local><14bd01c99c5d$9abeb1d0$0600a8c0@china.huawei.com><01f201c99cc9$61b85640$0601a8c0@allison><15f501c99ce1$8a015e90$0600a8c0@china.huawei.com><20090305095539.GA8180@elstar.local><18fd01c99db3$7906ded0$0600a8c0@china.huawei.com> <19b001c99e1f$bde50f10$0600a8c0@china.huawei.com> Date: Fri, 6 Mar 2009 10:41:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] wg last call followup - sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 11:54:05 -0000 ----- Original Message ----- From: "David Harrington" To: "'Wes Hardaker'" Cc: Sent: Friday, March 06, 2009 6:52 AM Subject: Re: [Isms] wg last call followup - sshtm > > DH> Should we add a version of this last paragraph in the security > > DH> considerations? in the SSH introduction? maybe section 3.3 for > > DH> notifications and proxy? > > > > I tried to put something like that in the security considerations > > section for the document I posted yesterday. Does it meet your > needs? > > section 3.3: > s/perform proxy/receive proxied messages/ > > local access control is only done for the NO. It is not done for a > proxied message, even if that proxied message is a notification. > > /connection can succeed/connection is available or can be opened/ > > I recommend replacing the paragraph "Since outgoing messages may need" > with a paragraph explaining a common use case, another describing > client session establishment, and a third that discusses lifetime of > the association. > > > Since outgoing messages may need to be sent to a different SSH > principal name that does not or can not directly match the SNMPv3 > security name, the SnmpSSHAddress specifies an [...] > > > Because naming policies might differ between administrative domains, > many SSH client software packages support a user@hostname:port > addressing syntax that operators can use to align non-equivalent > account names. The SnmpSSHAddress Textual Convention supports this > common SSH notation. > > When this notation is used in an SnmpSSHAddress, the SSH client uses > the "user" portion of the notation as the principal when establishing > a session with the remote SSH server. The "user" portion may or may > not match the tmSecurityName parameter passed from the security model. > If no "user@" portion is specified in the SnmpSSHAddress, then the SSH > client uses the tmSecurityName as the principal when establishing a > session with the remote SSH server. > > The SnmpSSHAddress and tmSecurityName associated with an SSH session > MUST remain constant during the life of the session. Different > SnmpSSHAddress values (with different hostnames, "user@" prefix names > and/or port numbers) will each result in individual SSH sessions. > > David That looks excellent. History tells me that I also need to see it in context since I sometimes then find other sentences which need tweaking to bring them in line, and as I have said, that takes me a bit longer to do; so agreement pro tem. Tom Petch > section 4.1.1 > I moved the lifetime association of session vs tmSecurityName into > section 3.3, where the lifetime associaiton of SnmpSSHAddress is > discussed, so the second sentence in section 4.1.1 is not necessary. > > possibly more later. > > > > > DH> should we separate the notification case from the proxy > > case, since > > DH> proxy does not do access control? > > > > There are two separate cases: > > > > Clients that does access control before sending (NOs only) > > Those that don't (everything else) > > > > I wouldn't spell out proxies generically since they're already > lumped > > into the other case. > > But in section 3.3, the NO and proxy are lumped together. > > > -- > > Wes Hardaker > > Sparta, Inc. > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From cfinss@dial.pipex.com Fri Mar 6 06:02:00 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0243A6C2C for ; Fri, 6 Mar 2009 06:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 0ZerhVC9Rssk for ; Fri, 6 Mar 2009 06:01:59 -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 00FED3A6C2A for ; Fri, 6 Mar 2009 06:01:58 -0800 (PST) X-Trace: 81969139/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.78/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.78 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: ArcEAHa7sEk+vBNO/2dsb2JhbACDI0OKB8lTB4QBBg X-IronPort-AV: E=Sophos;i="4.38,314,1233532800"; d="scan'208";a="81969139" X-IP-Direction: IN Received: from 1cust78.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.78]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Mar 2009 14:02:25 +0000 Message-ID: <009401c99e5b$93d08a60$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , References: Date: Fri, 6 Mar 2009 14:00:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] Proposed SSHTM document modifications: take 2 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:02:00 -0000 Wes I think that dbh's text is better for section 3 but .... I do see it as too late. I want it at the end of 3.1.4 under SSH Subsystems, you place it under Notifications. I see this as a symptom of an unresolved issue. Jeff sees the address format as about NOs; dbh, and I agree with him, sees it as a general feature which CGs can also. I am unclear where you stand, but for me, this means that it must be in 3.1.4 not buried under Notifications. We need a good reason to say it must not be used by a CG, whether that is done explicitly or implicitly 3.3 has a reference to notification generators, should be Notification Originators 4.1.1 uses 'consistent' which to me is the wrong word. Consistent with what? the first law of Thermodynamics? sorry, facetiousness:-( What I think that this passage must convey is that it must not change, that once supplied to open a session then a) for outbound messages, client or server, the same value will invoke the same session (pace transportAddress) and a different value will invoke a different session b) for inbound messages, client or server, this will be the only value ever supplied as part of the session identifier. We may not need to say all of this - well I would - but 'consistent' does not convey enough of it. 5.1 I have the same comment; 'consistent' is not the right word. The rest of section 5 is a struggle for me. 5.3 7) looks spot on but I think that this is gainsayed by 5.1 2) and that 5.1 needs a rethink as a consequence. 5.1 1) should cover the client case, the problematic one, saying in essence that, as per 5.3 7), the value of tmSecurityName that was used when the session was opened MUST be inserted into tmSecurityName in the cache entry now being created; this value is obtianed in an implementation-dependent way. And then scrap 5.1 2). And if implementers cannot work out how to design a cache to do that, they should not be implementing:-) No more details needed. Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: Sent: Thursday, March 05, 2009 2:32 AM Subject: [Isms] Proposed SSHTM document modifications: take 2 From ietfdbh@comcast.net Fri Mar 6 06:12:28 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6E23A69E2 for ; Fri, 6 Mar 2009 06:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 XgCzVeRA0nMb for ; Fri, 6 Mar 2009 06:12:28 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id C1DE53A6970 for ; Fri, 6 Mar 2009 06:12:27 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Ppzj1b05S17dt5G57qCziD; Fri, 06 Mar 2009 14:12:59 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id PqCy1b0070UQ6dC3ZqCyAK; Fri, 06 Mar 2009 14:12:59 +0000 From: "David Harrington" To: "'tom.petch'" , "'Jeffrey Hutzelman'" , References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> <000601c99e49$b2c18d00$0601a8c0@allison> Date: Fri, 6 Mar 2009 09:12:57 -0500 Message-ID: <1a6801c99e65$a689bd20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <000601c99e49$b2c18d00$0601a8c0@allison> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmeUlD8dZ/uqtaASbyCF8TVlSZpuwAEumeA Subject: Re: [Isms] SSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:12:29 -0000 Hi, I have asked Joe to be more active in this discussion. I also asked Chris Lonvick (editor SSH docs) to look in on this thread and see if he wants to contribute anything. When the pure security guys reach consensus, maybe they can provide us NM-oriented editors soem immutable text to put into the document. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Friday, March 06, 2009 4:22 AM > To: Jeffrey Hutzelman; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] SSH always provides a username > > ---- Original Message ----- > From: "Jeffrey Hutzelman" > To: > Cc: > Sent: Thursday, March 05, 2009 10:36 PM > Subject: [Isms] SSH always provides a username > > > > draft-ietf-isms-secshell-14.txt section 4.1.1 contains the > following: > > > > 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 an SSH identity to a > > tmSecurityName, or to transform a tmSecurityName to an SSH > > identity. > > > > 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. > > > > This is not true; it is a misinterpretation of the details > of operation of > > a particular SSH user authentication method which happen below the > > abstraction visible to SSHTM. While the GSS-API user > authentication method > > described in RFC4462 does allow the "username" field on the > wire to be > > empty, this is permitted only in cases where the SSH server (NOT a > > subsystem such as SNMP) is able to infer a username from > the client's > > GSS-API credentials. SSH will always report an > authenticated username. > > > > Similarly, if the SSH server allows the connection, it has > determined that > > the client is authorized for the requested username. The > claim that "the > > user name may not be verified by the server" would seem to > be a reference > > to the "none" user authentication method, in which the > server may choose to > > allow access with no further authentication. This is functionally > > equivalent to using password authentication but allowing > any password, or > > using a well-known SNMP community string like "public" -- weak, but > > operating as designed. > > > > In no case should SSHTM "obtain the user name from other credentials > > exchanged during the SSH exchange"; this would be a serious > violation of > > the abstraction boundary between SSHTM and SSH. > > > > I propose to eliminate these two paragraphs, and make the > following change: > > > > OLD: > > > > On the SSH server side of a connection: > > > > The tmSecurityName SHOULD be the value of the user > name field of > > the SSH_MSG_USERAUTH_REQUEST message for which a > > SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH > user name is > > extracted from the SSH layer is implementation-dependent. > > > > NEW: > > > > On the SSH server side of a connection: > > > > The tmSecurityName SHOULD be the SSH user name. How > the SSH user > > name is extracted from the SSH later is > implementation-dependent. > > > > > > This eliminates the inappropriate reference to details of > the SSH protocol, > > which is also an abstraction violation. SSHTM has no > business knowing that > > the username came from a particular field of a particular > SSH protocol > > message, especially when that may not actually be the case. > > > > Jeff > > What you say seems fine but I find this horribly difficult, > especially over > e-mail. I do not know enough about ssh to know whether your > words are more > accurate or not. > > What I do know is that the current wording was supplied by Joe Salowey > (28nov2008) and when he did, I annotated my copy of sshtm > with comment 'supplied > by Joe so must be right' ie I do not know enough to judge the > accuracy of this. > This text was proposed in response to a difficulty so it is > there for a reason. > > You and Joe both know much more about ssh than I and when you > say what I > perceive to be different things, I struggle to know which to > support. I look in > other places - you contributed more on the ssh list but I see > more of Joe > contributing outside the IETF - and find myelf on the fence. > > Perhaps the 'proper' resolution is for Joe to speak up and > say, yes, this is > fine but I cannot rely on that happening. > > The worst outcome is that, during a future review, Joe speaks > up and says change > it back again because .... > > So, I am on the fence, and not comfortable with it. > > Tom Petch > > > -- Jeff > > _______________________________________________ > > 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 wjhns1@hardakers.net Fri Mar 6 06:51:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F90F3A6C3E for ; Fri, 6 Mar 2009 06:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.038, 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 gRi-kZPzOcBo for ; Fri, 6 Mar 2009 06:51:04 -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 D04A23A69BD for ; Fri, 6 Mar 2009 06:51:04 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 6C99D39A12C; Fri, 6 Mar 2009 06:51:35 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> Date: Fri, 06 Mar 2009 06:51:35 -0800 In-Reply-To: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Thu, 05 Mar 2009 16:36:16 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] IsmsSSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:51:05 -0000 >>>>> On Thu, 05 Mar 2009 16:36:16 -0500, Jeffrey Hutzelman said: JH> OLD: JH> On the SSH server side of a connection: JH> The tmSecurityName SHOULD be the value of the user name field of JH> the SSH_MSG_USERAUTH_REQUEST message for which a JH> SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH user name is JH> extracted from the SSH layer is implementation-dependent. JH> NEW: JH> On the SSH server side of a connection: JH> The tmSecurityName SHOULD be the SSH user name. How the SSH user JH> name is extracted from the SSH later is implementation-dependent. I never liked the previous wording and think the newer set is much better. I suspect that some of the original wording may have been back when we were discussing host-based authentication and maybe the wording was confused because of that (host-based authentication still requires the user-name to be present but the server can ignore it if desired). My only question with the replacement text is that the rest of the documentation frequently refers to the "SSH principal" instead of the "SSH user name". Should the text use that instead? -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Fri Mar 6 06:58:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D843A6843 for ; Fri, 6 Mar 2009 06:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.037, 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 BOwmUL92Fw9a for ; Fri, 6 Mar 2009 06:58:30 -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 6C7353A680B for ; Fri, 6 Mar 2009 06:58:30 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 3A9DD39A12C; Fri, 6 Mar 2009 06:59:01 -0800 (PST) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <009401c99e5b$93d08a60$0601a8c0@allison> Date: Fri, 06 Mar 2009 06:59:01 -0800 In-Reply-To: <009401c99e5b$93d08a60$0601a8c0@allison> (tom petch's message of "Fri, 6 Mar 2009 14:00:13 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSHTM document modifications: take 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: , X-List-Received-Date: Fri, 06 Mar 2009 14:58:31 -0000 >>>>> On Fri, 6 Mar 2009 14:00:13 +0100, "tom.petch" said: tp> I think that dbh's text is better for section 3 but .... I do see tp> it as too late. Well, dbh is free to rewrite it. He generally does that with everyones text before he publishes it ;-) tp> I see this as a symptom of an unresolved issue. Jeff sees the tp> address format as about NOs; dbh, and I agree with him, sees it as a tp> general feature which CGs can also. I'd be more than happy to make it generic. CGs shouldn't be prohibited from using it. We were talking about multiple things: 1) information about it, which is generic. 2) motivations for it, which primarily has been from the NO perspective So splitting it up would be fine with me to meet both needs. tp> 3.3 has a reference to notification generators, should be Notification tp> Originators Good point tp> 4.1.1 uses 'consistent' which to me is the wrong word. Consistent tp> with what? I don't find it unclear, but adding a few words wouldn't hurt. Constant may be a better word. It has to be constant based on when the session was opened, regardless from which side it was opened from. I'll talk to David about whether he wants to take the next pass at incorporating the comments from you and Jeff. -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Fri Mar 6 07:03:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98D13A6B15 for ; Fri, 6 Mar 2009 07:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.036, 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 uvRAu5MvfVSr for ; Fri, 6 Mar 2009 07:03:38 -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 E31E43A6887 for ; Fri, 6 Mar 2009 07:03:37 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id B1C8F39A12C; Fri, 6 Mar 2009 07:04:08 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 06 Mar 2009 07:04:08 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Fri, 6 Mar 2009 10:58:19 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes to draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:03:38 -0000 >>>>> On Fri, 6 Mar 2009 10:58:19 +0100, said: PE> I do not like this change -- it will make the example considerably PE> harder to understand, since the reader can't possibly figure out PE> how the NO actually initiates the SSH connection (since it requires PE> a SSH user name, and it's certainly not "alice"). Well, we could make it more clear that the ssh user name will be alice in the text. I don't think the example will benefit from adding the alice@ prefix since the object of the text is to discuss how configuration of notifications works from a bunch of other perspectives (ASIs, MIBs, etc). PE> (There's no requirement that TMs use the ":" syntax; PE> e.g. a DCCP-based TM would need a syntax that includes the DCCP PE> service code, and HTTP-based TM would use URIs.) Except that having a required port matches every TC produced to date and matches the way the previous UDP and TCP TCs worked so it helps the understanding. And since the SSH TC requires it, we can't leave it out of the example anyway. -- Wes Hardaker Sparta, Inc. From Pasi.Eronen@nokia.com Fri Mar 6 07:18:56 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC3A3A6BDA for ; Fri, 6 Mar 2009 07:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 vl0dBCHsdXhW for ; Fri, 6 Mar 2009 07:18:56 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CCDBE3A6CC9 for ; Fri, 6 Mar 2009 07:18:55 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n26FILsm008985; Fri, 6 Mar 2009 09:19:23 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 17:19:20 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 17:19:19 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 17:19:14 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 6 Mar 2009 16:19:14 +0100 From: To: Date: Fri, 6 Mar 2009 16:19:10 +0100 Thread-Topic: Proposed changes to draft-ietf-isms-transport-security-model Thread-Index: AcmebNm5OPo0V9FtQzqQCQkSXuh1LwAAN1Mw Message-ID: <808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2009 15:19:14.0856 (UTC) FILETIME=[E8F26280:01C99E6E] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes to draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:18:56 -0000 Wes Hardaker wrote: >=20 > PE> I do not like this change -- it will make the example > PE> considerably harder to understand, since the reader can't > PE> possibly figure out how the NO actually initiates the SSH > PE> connection (since it requires a SSH user name, and it's > PE> certainly not "alice"). >=20 > Well, we could make it more clear that the ssh user name will be alice > in the text. > > I don't think the example will benefit from adding the alice@ prefix > since the object of the text is to discuss how configuration of > notifications works from a bunch of other perspectives (ASIs,=20 > MIBs, etc). In current examples, the prefix is "rtr-nyc4@", not "alice@". Using "alice" as SSH user name here doesn't really make sense. "alice" is our (notification originator's) name for the receiver (used for VACM); the SSH user name has to be the receiver's name for us (the originator). Since how exactly the SSH user name works was one of the=20 topics that took even the WG many years to understand, I think it's important to be as clear as possible in the examples here. Best regards, Pasi= From wjhns1@hardakers.net Fri Mar 6 07:27:06 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B5B3A68C0 for ; Fri, 6 Mar 2009 07:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.035, 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 FjypwAXEcsaZ for ; Fri, 6 Mar 2009 07:27:05 -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 5B0BC3A6405 for ; Fri, 6 Mar 2009 07:27:05 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 0B20139A12C; Fri, 6 Mar 2009 07:27:36 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 06 Mar 2009 07:27:35 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Fri, 6 Mar 2009 16:19:10 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes to draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:27:06 -0000 >>>>> On Fri, 6 Mar 2009 16:19:10 +0100, said: PE> Since how exactly the SSH user name works was one of the PE> topics that took even the WG many years to understand, PE> I think it's important to be as clear as possible in PE> the examples here. I agree. I think the text should state that the SSH user name will be taken from the securityName value. And the prefix definitely needs to be well explained in the SSH draft. -- Wes Hardaker Sparta, Inc. From Pasi.Eronen@nokia.com Fri Mar 6 07:30:49 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CC33A6CFD for ; Fri, 6 Mar 2009 07:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 ifbmDH9s1CAV for ; Fri, 6 Mar 2009 07:30:47 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 186183A6CC0 for ; Fri, 6 Mar 2009 07:30:46 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n26FU5Tu019896; Fri, 6 Mar 2009 09:31:15 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 17:30:57 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 17:30:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 17:30:47 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 6 Mar 2009 16:30:47 +0100 From: To: Date: Fri, 6 Mar 2009 16:30:48 +0100 Thread-Topic: Proposed changes to draft-ietf-isms-transport-security-model Thread-Index: AcmecBzo9n++uTsqTJ++kauqWTGfbwAACTgg Message-ID: <808FD6E27AD4884E94820BC333B2DB7727EA6029E3@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2009 15:30:47.0887 (UTC) FILETIME=[860685F0:01C99E70] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes to draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:30:49 -0000 Wes Hardaker wrote: > PE> Since how exactly the SSH user name works was one of the=20 > PE> topics that took even the WG many years to understand, > PE> I think it's important to be as clear as possible in > PE> the examples here. >=20 > I agree. I think the text should state that the SSH user name > will be taken from the securityName value. But the example is about *notification originator*, and that's the=20 one case where taking SSH user name from securityName doesn't make much sense! So although that's the default (in absense of "user@", this is a situation where the "user@" prefix would almost always be used (and the example should show a typical or common case, not something so rare it probably never happens). Best regards,=20 Pasi= From ietfdbh@comcast.net Fri Mar 6 07:41:43 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1723328C12A for ; Fri, 6 Mar 2009 07:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 u61ng47xHk+u for ; Fri, 6 Mar 2009 07:41:42 -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 190D73A6CA0 for ; Fri, 6 Mar 2009 07:41:41 -0800 (PST) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA09.westchester.pa.mail.comcast.net with comcast id Pmug1b00516LCl059riDa1; Fri, 06 Mar 2009 15:42:13 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id PriC1b00j0UQ6dC3SriD2o; Fri, 06 Mar 2009 15:42:13 +0000 From: "David Harrington" To: , References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 6 Mar 2009 10:42:11 -0500 Message-ID: <1aa501c99e72$1e011ea0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmebNm5OPo0V9FtQzqQCQkSXuh1LwAAN1MwAADXzHA= Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes todraft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:41:43 -0000 Hi Pasi, I disagree. In the TSM document, we are focused on helping readers understand how TSM works, not SSHTM. In SSHTM, if the transportAddress does not have a "user@" component, then we default to using the securityName (in this case, "alice") for the SSH user name. So the example in TSM is not wrong, and since it does not introduce the special SSH addressing mode, is clearer for purposes of explaining TSM. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Friday, March 06, 2009 10:19 AM > To: wjhns1@hardakers.net > Cc: isms@ietf.org > Subject: Re: [Isms] Proposed changes > todraft-ietf-isms-transport-security-model > > Wes Hardaker wrote: > > > > PE> I do not like this change -- it will make the example > > PE> considerably harder to understand, since the reader can't > > PE> possibly figure out how the NO actually initiates the SSH > > PE> connection (since it requires a SSH user name, and it's > > PE> certainly not "alice"). > > > > Well, we could make it more clear that the ssh user name > will be alice > > in the text. > > > > I don't think the example will benefit from adding the alice@ prefix > > since the object of the text is to discuss how configuration of > > notifications works from a bunch of other perspectives (ASIs, > > MIBs, etc). > > In current examples, the prefix is "rtr-nyc4@", not "alice@". > > Using "alice" as SSH user name here doesn't really make sense. > "alice" is our (notification originator's) name for the receiver > (used for VACM); the SSH user name has to be the receiver's > name for us (the originator). > > Since how exactly the SSH user name works was one of the > topics that took even the WG many years to understand, > I think it's important to be as clear as possible in > the examples here. > > Best regards, > Pasi > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Fri Mar 6 07:43:55 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0C73A6C6B for ; Fri, 6 Mar 2009 07:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.034, 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 hqpLJF0Wax2M for ; Fri, 6 Mar 2009 07:43:51 -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 4AC153A6CAE for ; Fri, 6 Mar 2009 07:43:51 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 22E0139A12C; Fri, 6 Mar 2009 07:44:22 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727EA6029E3@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 06 Mar 2009 07:44:22 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727EA6029E3@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Fri, 6 Mar 2009 16:30:48 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes to draft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:43:55 -0000 >>>>> On Fri, 6 Mar 2009 16:30:48 +0100, said: PE> But the example is about *notification originator*, and that's the PE> one case where taking SSH user name from securityName doesn't PE> make much sense! No, it MAY make perfect sense. Even a lot of the time. We don't have a huge amount of data to say how often it'll make sense or not. -- Wes Hardaker Sparta, Inc. From ietfdbh@comcast.net Fri Mar 6 07:47:23 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EEB93A6CF7 for ; Fri, 6 Mar 2009 07:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 6XvGwWv1UwnB for ; Fri, 6 Mar 2009 07:47:22 -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 791893A6CF1 for ; Fri, 6 Mar 2009 07:47:22 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id PnSZ1b00A0ldTLk55rnso5; Fri, 06 Mar 2009 15:47:52 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA04.westchester.pa.mail.comcast.net with comcast id Prnr1b00n0UQ6dC3QrnrtA; Fri, 06 Mar 2009 15:47:52 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com><808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 6 Mar 2009 10:47:50 -0500 Message-ID: <1aa601c99e72$e7d6bc80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmecBYJ/QCs4yb1RP+UrD6z5TfpoQAAiCeQ Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes todraft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:47:23 -0000 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Friday, March 06, 2009 10:28 AM > To: Pasi.Eronen@nokia.com > Cc: isms@ietf.org > Subject: Re: [Isms] Proposed changes > todraft-ietf-isms-transport-security-model > > >>>>> On Fri, 6 Mar 2009 16:19:10 +0100, said: > > PE> Since how exactly the SSH user name works was one of the > PE> topics that took even the WG many years to understand, > PE> I think it's important to be as clear as possible in > PE> the examples here. > > I agree. I think the text should state that the SSH user name > will be taken from the securityName value. ***I disagree*** Please state that it is taken from the administratively-configured MIB, or other implement-dependent datastore, but please do not say it is taken from the securityName value, because that may not always be true for all uses of TSM. I really think we do not want the TSM document discussing any of the details of how SSHTM works! This is a modular architecture. > > And the prefix definitely needs to be well explained in the SSH draft. > > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Fri Mar 6 07:52:14 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134B93A6CC8 for ; Fri, 6 Mar 2009 07:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 YeZDIKYBPLnS for ; Fri, 6 Mar 2009 07:52:13 -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 E549B3A6CAE for ; Fri, 6 Mar 2009 07:52:12 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Pnfs1b0071GhbT858rskMk; Fri, 06 Mar 2009 15:52:44 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id Prsj1b00g0UQ6dC3TrskMJ; Fri, 06 Mar 2009 15:52:44 +0000 From: "David Harrington" To: , References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com><808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727EA6029E3@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 6 Mar 2009 10:52:42 -0500 Message-ID: <1aa701c99e73$96030de0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <808FD6E27AD4884E94820BC333B2DB7727EA6029E3@NOK-EUMSG-01.mgdnok.nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmecBzo9n++uTsqTJ++kauqWTGfbwAACTggAACvPcA= Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes todraft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:52:14 -0000 Hi, So are you saying that within an enterprise, operators rarely use the same naming conventions across their different SSH entities? In my small home network, I use the same identity for all my SSH endpoints. SSH is not my area of special expetise, but I would expect that SSH naming might be consistent within an administrative domain. And to my knowledge, SNMP is usually used within, not across, administrative domains. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Friday, March 06, 2009 10:31 AM > To: wjhns1@hardakers.net > Cc: isms@ietf.org > Subject: Re: [Isms] Proposed changes > todraft-ietf-isms-transport-security-model > > Wes Hardaker wrote: > > PE> Since how exactly the SSH user name works was one of the > > PE> topics that took even the WG many years to understand, > > PE> I think it's important to be as clear as possible in > > PE> the examples here. > > > > I agree. I think the text should state that the SSH user name > > will be taken from the securityName value. > > But the example is about *notification originator*, and that's the > one case where taking SSH user name from securityName doesn't > make much sense! So although that's the default (in absense > of "user@", this is a situation where the "user@" prefix would > almost always be used (and the example should show a typical > or common case, not something so rare it probably never happens). > > Best regards, > Pasi > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From jsalowey@cisco.com Fri Mar 6 07:52:56 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB1C3A6CC8 for ; Fri, 6 Mar 2009 07:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 2DmCbJr4eTZa for ; Fri, 6 Mar 2009 07:52:55 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BD5BC28C1F3 for ; Fri, 6 Mar 2009 07:52:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,315,1233532800"; d="scan'208";a="31143485" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 06 Mar 2009 15:53:26 +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 n26FrQUi019755; Fri, 6 Mar 2009 07:53:26 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n26FrQBl010918; Fri, 6 Mar 2009 15:53:26 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); Fri, 6 Mar 2009 07:53:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 07:53:25 -0800 Message-ID: In-Reply-To: <000601c99e49$b2c18d00$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] SSH always provides a username Thread-Index: AcmeUl5kfkClib/qRmW5DrCiHt6jTAAHRf2A References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> <000601c99e49$b2c18d00$0601a8c0@allison> From: "Joseph Salowey (jsalowey)" To: "tom.petch" , "Jeffrey Hutzelman" , X-OriginalArrivalTime: 06 Mar 2009 15:53:26.0464 (UTC) FILETIME=[AFCCEC00:01C99E73] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6255; t=1236354806; x=1237218806; 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:=20RE=3A=20[Isms]=20SSH=20always=20provides=20a=20 username |Sender:=20; bh=795JZtiWm1oKJzqoj1/UoHpjxFGpS7LU1CJ5D6GTfGA=; b=oxwN0d0QYNnJUICezdaIMHmOONzKIESSTChD0kKKZIConqBsPCZWezm5Ex y7vSSBioLz3sSZBWkHW6YZpKgH5GAXvy3POEf/Zuv6VwEHJi0W9G3bIbObvu 2uksMFqE60; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Isms] SSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:52:56 -0000 =20 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > Behalf Of tom.petch > Sent: Friday, March 06, 2009 1:22 AM > To: Jeffrey Hutzelman; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] SSH always provides a username >=20 > ---- Original Message ----- > From: "Jeffrey Hutzelman" > To: > Cc: > Sent: Thursday, March 05, 2009 10:36 PM > Subject: [Isms] SSH always provides a username >=20 >=20 > > draft-ietf-isms-secshell-14.txt section 4.1.1 contains the=20 > following: > > > > 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=20 > necessary to use a > > mapping algorithm to transform an SSH identity to a > > tmSecurityName, or to transform a tmSecurityName to an SSH > > identity. > > > > In other cases the user name may not be verified by=20 > the server, so > > for these implementations, it may be necessary to=20 > obtain the user > > name from other credentials exchanged during the SSH exchange. > > > > This is not true; it is a misinterpretation of the details of=20 > > operation of a particular SSH user authentication method=20 > which happen=20 > > below the abstraction visible to SSHTM. While the GSS-API user=20 > > authentication method described in RFC4462 does allow the=20 > "username"=20 > > field on the wire to be empty, this is permitted only in=20 > cases where=20 > > the SSH server (NOT a subsystem such as SNMP) is able to infer a=20 > > username from the client's GSS-API credentials. SSH will=20 > always report an authenticated username. > > > > Similarly, if the SSH server allows the connection, it has=20 > determined=20 > > that the client is authorized for the requested username. =20 > The claim=20 > > that "the user name may not be verified by the server"=20 > would seem to=20 > > be a reference to the "none" user authentication method, in=20 > which the=20 > > server may choose to allow access with no further authentication. =20 > > This is functionally equivalent to using password=20 > authentication but=20 > > allowing any password, or using a well-known SNMP community string=20 > > like "public" -- weak, but operating as designed. > > > > In no case should SSHTM "obtain the user name from other=20 > credentials=20 > > exchanged during the SSH exchange"; this would be a serious=20 > violation=20 > > of the abstraction boundary between SSHTM and SSH. > > > > I propose to eliminate these two paragraphs, and make the=20 > following change: > > > > OLD: > > > > On the SSH server side of a connection: > > > > The tmSecurityName SHOULD be the value of the user=20 > name field of > > the SSH_MSG_USERAUTH_REQUEST message for which a > > SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH=20 > user name is > > extracted from the SSH layer is implementation-dependent. > > > > NEW: > > > > On the SSH server side of a connection: > > > > The tmSecurityName SHOULD be the SSH user name. How=20 > the SSH user > > name is extracted from the SSH later is=20 > implementation-dependent. > > > > > > This eliminates the inappropriate reference to details of the SSH=20 > > protocol, which is also an abstraction violation. SSHTM has no=20 > > business knowing that the username came from a particular=20 > field of a=20 > > particular SSH protocol message, especially when that may=20 > not actually be the case. > > >=20 > Jeff >=20 > What you say seems fine but I find this horribly difficult,=20 > especially over e-mail. I do not know enough about ssh to=20 > know whether your words are more accurate or not. >=20 > What I do know is that the current wording was supplied by Joe Salowey > (28nov2008) and when he did, I annotated my copy of sshtm=20 > with comment 'supplied by Joe so must be right' ie I do not=20 > know enough to judge the accuracy of this. > This text was proposed in response to a difficulty so it is=20 > there for a reason. >=20 > You and Joe both know much more about ssh than I and when you=20 > say what I perceive to be different things, I struggle to=20 > know which to support. I look in other places - you=20 > contributed more on the ssh list but I see more of Joe=20 > contributing outside the IETF - and find myelf on the fence. >=20 > Perhaps the 'proper' resolution is for Joe to speak up and=20 > say, yes, this is fine but I cannot rely on that happening. >=20 [Joe] Yes this is fine, explanation below. =20 > The worst outcome is that, during a future review, Joe speaks=20 > up and says change it back again because .... > > So, I am on the fence, and not comfortable with it. >=20 [Joe] I agree with Jeffrey that the current text has too many SSH specifics in it and I would like to see that changed (I think I suggested it in the past, but I probably didn't express myself well). My main concern is that the protocol field in the SSH message may not be filled in. It is true that SSH knows what the authenticated name is. It is true for RFC 4462 that if the user name is present it should be authorized, but the core SSH drafts don't require this, so it might not be true for other mechanisms. In any case, how the SSH username is extracted from the SSH protocol is implementation specific. =20 I think Jeffrey's text is good (s/later/layer). I am tempted to request that we say something like "It is the responsibility of the SSH layer ensure that the user name is valid and authenticated", but I can live without this because it really should be the case in a reasonable implementation. =20 Hopefully this helps clear things up.=20 =20 > Tom Petch >=20 > > -- Jeff > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms >=20 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms >=20 From jhutz@cmu.edu Fri Mar 6 07:58:32 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C38B3A6CCB for ; Fri, 6 Mar 2009 07:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 nap8Zyi5RzJW for ; Fri, 6 Mar 2009 07:58:27 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id AD2D03A6359 for ; Fri, 6 Mar 2009 07:58:27 -0800 (PST) Received: from 68-247-180-249.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n26FwrPg013277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 10:58:53 -0500 (EST) Date: Fri, 06 Mar 2009 10:58:53 -0500 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: <3CCC8F154ADE13D7A89655E8@atlantis.pc.cs.cmu.edu> In-Reply-To: References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] IsmsSSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:58:32 -0000 --On Friday, March 06, 2009 06:51:35 AM -0800 Wes Hardaker wrote: > My only question with the replacement text is that the rest of the > documentation frequently refers to the "SSH principal" instead of the > "SSH user name". Should the text use that instead? I don't know where the phrase "SSH principal" came from. From jhutz@cmu.edu Fri Mar 6 08:15:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482E33A68B8 for ; Fri, 6 Mar 2009 08:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 G98x8KCcZXr5 for ; Fri, 6 Mar 2009 08:15:09 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 463003A6784 for ; Fri, 6 Mar 2009 08:15:09 -0800 (PST) Received: from 68-247-180-249.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n26GFQYA014451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 11:15:27 -0500 (EST) Date: Fri, 06 Mar 2009 11:15:26 -0500 From: Jeffrey Hutzelman To: "Joseph Salowey (jsalowey)" , "tom.petch" , isms@ietf.org Message-ID: <282515935A8B39ABC9161D94@atlantis.pc.cs.cmu.edu> In-Reply-To: References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> <000601c99e49$b2c18d00$0601a8c0@allison> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] SSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 16:15:10 -0000 --On Friday, March 06, 2009 07:53:25 AM -0800 "Joseph Salowey (jsalowey)" wrote: > My main concern is that the protocol field in the SSH message may not be > filled in. But that detail is not visible to the layer above... > It is true that SSH knows what the authenticated name is. While this one is. > It is true for RFC 4462 that if the user name is present it should be > authorized, but the core SSH drafts don't require this, so it might not > be true for other mechanisms. I think that depends on what you mean by "authorized". RFC4252 does require that the server reject an authentication request if the user does not exist; see the third full paragraph on page 5. I think it is inherent in the nature of an authentication method that the method verify that whatever credentials the client presents are valid for the specified username, according to whatever the rules are for that method. So, that much should go without saying. Of course, the core drafts don't nail down what that means, because it varies from method to method. 'publickey' says "the server MUST check that the key is a valid authenticator for the user" (RFC 4252 sec 7, graf 2). 'password' leaves the details of password validation up to the server. 'none' succeeds "if no authentication is needed for the user" (RFC4252 sec 5.2). The description of 'hostbased' is a bit confusing. The auth request for this method contains two usernames -- the SSH user name that is present in all auth requests, and the requesting user's name _on the client host_. This allows user "bob" on host A to use hostbased authentication to log in as user "joe" on host B, provided B is configured to allow bob@A to log in as joe. To my reading, what the next-to-last graf on RFC4252 page 13 says is that in this scenario, the SSH server on host B can ignore the "bob" value and base its access decision solely on the credentials provided by host A. It does _not_ allow host B to ignore the 'user name' that is a standard part of the SSH request, which in this example contains the name "joe". That would be silly, because then it wouldn't know what username to use. > I think Jeffrey's text is good (s/later/layer). I am tempted to > request that we say something like "It is the responsibility of the SSH > layer ensure that the user name is valid and authenticated", but I can > live without this because it really should be the case in a reasonable > implementation. I think RFC4252 covers that sufficiently well, but I won't object to reiterating it here. -- Jeff From jhutz@cmu.edu Fri Mar 6 09:37:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762A43A6C07 for ; Fri, 6 Mar 2009 09:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 L5EW4fWWmYFw for ; Fri, 6 Mar 2009 09:37:04 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id B140E3A68F3 for ; Fri, 6 Mar 2009 09:37:04 -0800 (PST) Received: from 68-247-180-249.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n26HbSXf016961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 12:37:29 -0500 (EST) Date: Fri, 06 Mar 2009 12:37:28 -0500 From: Jeffrey Hutzelman To: David Harrington , Pasi.Eronen@nokia.com, wjhns1@hardakers.net Message-ID: In-Reply-To: <200903061552.n26Fqmps019705@grapenut.srv.cs.cmu.edu> References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727EA6029E3@NOK-EUMSG-01.mgdnok.nokia.com> <200903061552.n26Fqmps019705@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] Proposed changes todraft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:37:05 -0000 --On Friday, March 06, 2009 10:52:42 AM -0500 David Harrington wrote: > Hi, > > So are you saying that within an enterprise, operators rarely use the > same naming conventions across their different SSH entities? In my > small home network, I use the same identity for all my SSH endpoints. > SSH is not my area of special expetise, but I would expect that SSH > naming might be consistent within an administrative domain. No, he's saying that when an NO sends a notification with securityName "alice", then "alice" describes the NR, not the NO. It is highly unlikely that, when the NO originates an SSH connection, it is going to use the username "alice", because _the NO is not alice_. -- Jeff From wjhns1@hardakers.net Fri Mar 6 15:39:44 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E796A3A69F6 for ; Fri, 6 Mar 2009 15:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.033, 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 qZD5XuVT2qyz for ; Fri, 6 Mar 2009 15:39:44 -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 401FB3A6938 for ; Fri, 6 Mar 2009 15:39:44 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 5796539A128; Fri, 6 Mar 2009 15:40:15 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <005601c99cb2$112ad020$0601a8c0@allison> <20090305095035.GC7971@elstar.local> <200903051354.n25Ds98K011695@raisinbran.srv.cs.cmu.edu> Date: Fri, 06 Mar 2009 15:40:14 -0800 In-Reply-To: (Jeffrey Hutzelman's message of "Thu, 05 Mar 2009 17:00:08 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Proposed text changes for the secshell draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 23:39:45 -0000 >>>>> On Thu, 05 Mar 2009 17:00:08 -0500, Jeffrey Hutzelman said: JH> - The EOP are quite clear on what happens if there is _not_ an JH> existing session, in steps 3 and 4, but nowhere is it stated JH> that if there _is_ an existing session, it should be used. JH> Particularly... Your issues have been fixed in my next set of text... JH> + There does not appear to be any step which verifies that JH> the destTransportDomain and tmTransportDomain are SSHTM. JH> Is such a check required? No, we sort of decided it would be an implementation issue if code had even gotten that far and such trivialities didn't need to be documented in the EOP (you likely have bigger problems). -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Fri Mar 6 16:20:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7CFC3A6ABD for ; Fri, 6 Mar 2009 16:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.032, 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 gUnwX5X--+25 for ; Fri, 6 Mar 2009 16:20:18 -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 DD7B23A68E4 for ; Fri, 6 Mar 2009 16:20:17 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id EE38939A128 for ; Fri, 6 Mar 2009 16:20:48 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Fri, 06 Mar 2009 16:20:48 -0800 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] new SSH draft to review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 00:20:19 -0000 After much thinking about the text, I've modified the incoming/outgoing EOPs quite a bit. They're a lot simpler and easier to understand I think and incorporate all the issues people had with them. See what you think of them. I certainly could have made some mistakes typo-wise since I'm too brain dead to look at them further today to double check them (again). David will probably work on them more Monday. Diffs since -14: http://www.hardakers.net/temp/isms-ssh-fulldiff.html Diffs since last time: http://www.hardakers.net/temp/isms-ssh-lastdiff.html The full document: http://www.hardakers.net/temp/draft-ietf-isms-secshell-15wes3.txt -- Wes Hardaker Sparta, Inc. From cfinss@dial.pipex.com Sat Mar 7 04:27:39 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1883A6ABC for ; Sat, 7 Mar 2009 04:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65mgnSl5eFuG for ; Sat, 7 Mar 2009 04:27: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 6442B3A6A20 for ; Sat, 7 Mar 2009 04:27:38 -0800 (PST) X-Trace: 137943340/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.19/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.19 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: AvQEAJf3sUk+vBET/2dsb2JhbACDJIpNxkoHgk4MgSQG X-IronPort-AV: E=Sophos;i="4.38,318,1233532800"; d="scan'208";a="137943340" X-IP-Direction: IN Received: from 1cust19.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.19]) by smtp.pipex.tiscali.co.uk with SMTP; 07 Mar 2009 12:27:54 +0000 Message-ID: <003c01c99f17$8942f260$0601a8c0@allison> From: "tom.petch" To: , References: <808FD6E27AD4884E94820BC333B2DB7727EA602670@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727EA6029D0@NOK-EUMSG-01.mgdnok.nokia.com> Date: Sat, 7 Mar 2009 12:15:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] Proposed changes todraft-ietf-isms-transport-security-model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 12:27:39 -0000 ----- Original Message ----- From: To: Cc: Sent: Friday, March 06, 2009 4:19 PM > Wes Hardaker wrote: > > > > PE> I do not like this change -- it will make the example > > PE> considerably harder to understand, since the reader can't > > PE> possibly figure out how the NO actually initiates the SSH > > PE> connection (since it requires a SSH user name, and it's > > PE> certainly not "alice"). > > > > Well, we could make it more clear that the ssh user name will be alice > > in the text. > > > > I don't think the example will benefit from adding the alice@ prefix > > since the object of the text is to discuss how configuration of > > notifications works from a bunch of other perspectives (ASIs, > > MIBs, etc). > > In current examples, the prefix is "rtr-nyc4@", not "alice@". > > Using "alice" as SSH user name here doesn't really make sense. > "alice" is our (notification originator's) name for the receiver > (used for VACM); the SSH user name has to be the receiver's > name for us (the originator). > > Since how exactly the SSH user name works was one of the > topics that took even the WG many years to understand, > I think it's important to be as clear as possible in > the examples here. > Pasi, I think that the mechanics of this combination of securityName and e-mail format transportAddress are relatively straightforward to describe and understand. It is when the descriptions get more abstract, referrring to authenticated receivers, that I see confusion arising; and this is perverse for me, since I usually want less mechanics and more abstractions in the snmp I-Ds. I have a fixed view of authentication; Alice makes an assertion and offers security credentials to authenticate it which Bob uses to perform such authentication as he thinks necessary. This idea sometimes jars with the language used in the three I-Ds but that I can cope with. The two gaps in my understanding were having two separate securityNames, one in NO and the other in NR, which I had not seen as permitted, although a careful study of RFC3411 shows those clever authors of RFC3411 did not exclude it "A securityName is a human readable string representing a principal.": and that the securityName used in the NO was not authenticated in the sense I understand it - Juergen pointed out that the securityName in the NO is bound to the authenticated host name of the ssh server. I had not see this last as secure enough but when those with more security expertise than I say it is ok, then I will accept that. So, should the example be in tsm? I think yes, but the wording needs adjusting, addressing the two points that I was hung up on. Is, as the example says, the e-mail format address model independent? I am happy to see it as such, certainly not specific to Notifications. Tom Petch > Best regards, > Pasi From cfinss@dial.pipex.com Sat Mar 7 04:27:40 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED573A68B1 for ; Sat, 7 Mar 2009 04:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.493, 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 fxUoa45X-qUW for ; Sat, 7 Mar 2009 04:27: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 2DEDA3A6AD3 for ; Sat, 7 Mar 2009 04:27:39 -0800 (PST) X-Trace: 137943346/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.19/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.19 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: AvQEAJf3sUk+vBET/2dsb2JhbACDJIpNtzwHjwcHgk4MgSQGhl0 X-IronPort-AV: E=Sophos;i="4.38,318,1233532800"; d="scan'208";a="137943346" X-IP-Direction: IN Received: from 1cust19.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.19]) by smtp.pipex.tiscali.co.uk with SMTP; 07 Mar 2009 12:27:56 +0000 Message-ID: <003d01c99f17$8a4df9c0$0601a8c0@allison> From: "tom.petch" To: "Jeffrey Hutzelman" , "Wes Hardaker" References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> <3CCC8F154ADE13D7A89655E8@atlantis.pc.cs.cmu.edu> Date: Sat, 7 Mar 2009 12:16:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] IsmsSSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 12:27:40 -0000 ----- Original Message ----- From: "Jeffrey Hutzelman" To: "Wes Hardaker" Cc: ; Sent: Friday, March 06, 2009 4:58 PM Subject: Re: [Isms] IsmsSSH always provides a username > --On Friday, March 06, 2009 06:51:35 AM -0800 Wes Hardaker > wrote: > > > My only question with the replacement text is that the rest of the > > documentation frequently refers to the "SSH principal" instead of the > > "SSH user name". Should the text use that instead? > > I don't know where the phrase "SSH principal" came from. Nor me. Oxymoron? I do not think that it should appear. Principal is a well defined SNMPv3 term, SSH has users, hosts, ..... If we need to invent another term, it should be anything but principal. Tom Petch > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From root@core3.amsl.com Sun Mar 8 20:15:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E51F328C0E0; Sun, 8 Mar 2009 20:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309031501.E51F328C0E0@core3.amsl.com> Date: Sun, 8 Mar 2009 20:15:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-usage-05.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 03:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models Author(s) : K. Narayan, D. Nelson Filename : draft-ietf-isms-radius-usage-05.txt Pages : 13 Date : 2009-03-08 This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-05.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-radius-usage-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-08200442.I-D@ietf.org> --NextPart-- From dnelson@elbrysnetworks.com Sun Mar 8 21:18:35 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D6D3A67A2 for ; Sun, 8 Mar 2009 21:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, 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 790P-J8Q5VHE for ; Sun, 8 Mar 2009 21:18:35 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id BF44D3A677E for ; Sun, 8 Mar 2009 21:18:34 -0700 (PDT) Received: (qmail 18643 invoked from network); 8 Mar 2009 23:19:03 -0400 Received: from unknown (HELO ?172.22.23.8?) (172.22.23.8) by gumby.elbrysnetworks.com with SMTP; 8 Mar 2009 23:19:03 -0400 Message-ID: <49B48AA7.6050306@elbrysnetworks.com> Date: Sun, 08 Mar 2009 23:19:03 -0400 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: isms@ietf.org References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Isms] wg last call followup X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 04:18:35 -0000 Juergen Schoenwaelder wrote: > On November 4th 2008, I started WG last call on the ISMS document set: > > [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 > > > We received some comments and the subsequent mailing list discussions > have led to some changes to the ISMS core documents. I have just posted draft-ietf-isms-radius-usage-05.txt, which incorporates all the revised text we agreed to on the mailing list, arising out of the WGLC. From j.schoenwaelder@jacobs-university.de Mon Mar 9 00:30:32 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A353A68BB for ; Mon, 9 Mar 2009 00:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_40=-0.185, 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 QPzDAD2t-aNE for ; Mon, 9 Mar 2009 00:30:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D2D703A67CC for ; Mon, 9 Mar 2009 00:30:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A4A2C0009 for ; Mon, 9 Mar 2009 08:30:56 +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 F6cqaNylq46n; Mon, 9 Mar 2009 08:30:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBC42C0005; Mon, 9 Mar 2009 08:30:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8FACC9F2314; Mon, 9 Mar 2009 08:30:51 +0100 (CET) Date: Mon, 9 Mar 2009 08:30:51 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090309073051.GB5444@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] radius usage last call followup 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: , X-List-Received-Date: Mon, 09 Mar 2009 07:30:32 -0000 Hi, our radius usage document has been last called in November and the comments lead to several changes. The revised ID is now in place: http://tools.ietf.org/html/draft-ietf-isms-radius-usage-05 Please check the changes until March 23rd. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Mon Mar 9 08:34:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192413A67E4 for ; Mon, 9 Mar 2009 08:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.031, 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 KbSG-WmS6y54 for ; Mon, 9 Mar 2009 08:34:16 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 77B773A67AF for ; Mon, 9 Mar 2009 08:34:16 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 689A139A138; Mon, 9 Mar 2009 08:34:50 -0700 (PDT) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> <3CCC8F154ADE13D7A89655E8@atlantis.pc.cs.cmu.edu> <003d01c99f17$8a4df9c0$0601a8c0@allison> Date: Mon, 09 Mar 2009 08:34:50 -0700 In-Reply-To: <003d01c99f17$8a4df9c0$0601a8c0@allison> (tom petch's message of "Sat, 7 Mar 2009 12:16:48 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] IsmsSSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:34:17 -0000 >>>>> On Sat, 7 Mar 2009 12:16:48 +0100, "tom.petch" said: tp> Nor me. Oxymoron? I do not think that it should appear. Principal tp> is a well defined SNMPv3 term, SSH has users, hosts, ..... If we tp> need to invent another term, it should be anything but principal. In the document I posted a link to on Friday I tried to change all existences of "SSH principal" to "SSH user". Note that the term principal is defined in the beginning of the document and does still exist through the rest of the document to refer to the human-user (badly summarizing here). If you look at the diff or the document and think I missed one, please let me know ASAP. -- Wes Hardaker Sparta, Inc. From ietfdbh@comcast.net Mon Mar 9 09:19:30 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B045F3A69DE for ; Mon, 9 Mar 2009 09:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.201, 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 Kklma7HIJGSP for ; Mon, 9 Mar 2009 09:19:30 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id C77953A6997 for ; Mon, 9 Mar 2009 09:19:29 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA04.westchester.pa.mail.comcast.net with comcast id QygM1b00517dt5G544L4D5; Mon, 09 Mar 2009 16:20:04 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id R4L31b00N0UQ6dC3Z4L3zw; Mon, 09 Mar 2009 16:20:04 +0000 From: "David Harrington" To: "'Wes Hardaker'" , "'tom.petch'" References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu><3CCC8F154ADE13D7A89655E8@atlantis.pc.cs.cmu.edu><003d01c99f17$8a4df9c0$0601a8c0@allison> Date: Mon, 9 Mar 2009 12:20:02 -0400 Message-ID: <04d001c9a0d2$e6d2a2b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmgzJf1xbPr4c+sQuWssy35eMh5VgABgL4Q Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] IsmsSSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 16:19:30 -0000 Hi, Just a point. If you refer to the "SSH user", that can be easily confused with the value of the "SSH user name" field, and since we have had long debates about whether user name is or is not filled in, and so on, keeping a separation between "SSH user" and "SSH user name" was something I considered a good thing. ymmv. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Monday, March 09, 2009 11:35 AM > To: tom.petch > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: [Isms] IsmsSSH always provides a username > > >>>>> On Sat, 7 Mar 2009 12:16:48 +0100, "tom.petch" > said: > > tp> Nor me. Oxymoron? I do not think that it should appear. > Principal > tp> is a well defined SNMPv3 term, SSH has users, hosts, ..... If we > tp> need to invent another term, it should be anything but principal. > > In the document I posted a link to on Friday I tried to change all > existences of "SSH principal" to "SSH user". Note that the term > principal is defined in the beginning of the document and does still > exist through the rest of the document to refer to the > human-user (badly > summarizing here). If you look at the diff or the document > and think I > missed one, please let me know ASAP. > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From jhutz@cmu.edu Mon Mar 9 12:35:58 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571233A6C33 for ; Mon, 9 Mar 2009 12:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQoF6bEKV2dC for ; Mon, 9 Mar 2009 12:35:57 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 805243A6C2F for ; Mon, 9 Mar 2009 12:35:57 -0700 (PDT) Received: from 68-247-180-249.pools.spcsdns.net (72-61-128-224.pools.spcsdns.net [72.61.128.224]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n29Ja9NC016400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 15:36:11 -0400 (EDT) Date: Mon, 09 Mar 2009 15:36:08 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Wes Hardaker'" , "'tom.petch'" Message-ID: <4655EDBBDBF8763615CF9A72@atlantis.pc.cs.cmu.edu> In-Reply-To: <200903091620.n29GK8eT023993@raisinbran.srv.cs.cmu.edu> References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> <3CCC8F154ADE13D7A89655E8@atlantis.pc.cs.cmu.edu> <003d01c99f17$8a4df9c0$0601a8c0@allison> <200903091620.n29GK8eT023993@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] IsmsSSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:35:58 -0000 --On Monday, March 09, 2009 12:20:02 PM -0400 David Harrington wrote: > Hi, > > Just a point. If you refer to the "SSH user", that can be easily > confused with the value of the "SSH user name" field, and since we > have had long debates about whether user name is or is not filled in, > and so on, keeping a separation between "SSH user" and "SSH user name" > was something I considered a good thing. Actually, what we've had long debates about was whether SSHTM should talk about the details of the SSH protocol at all, and I believe we came to the conclusion that it should not. The distinction you are talking about is the distinction between "TCP port" and "TCP source port field"; just as that matters only to an implementation of TCP, the details of the 'user name' field in a particular SSH message, what it means, and when, matter only to an implementation of SSH. Please, as long as we keep our focus above the SSH abstraction, any confusion caused by trying to talk about what goes on below that abstraction goes away! -- Jeff From jhutz@cmu.edu Mon Mar 9 12:46:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7433A6C19 for ; Mon, 9 Mar 2009 12:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DJhQqRBXWma for ; Mon, 9 Mar 2009 12:46:30 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 55C0F3A684B for ; Mon, 9 Mar 2009 12:46:25 -0700 (PDT) Received: from 68-247-180-249.pools.spcsdns.net (72-61-128-224.pools.spcsdns.net [72.61.128.224]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n29JkohI016859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 15:46:51 -0400 (EDT) Date: Mon, 09 Mar 2009 15:46:49 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , isms@ietf.org Message-ID: In-Reply-To: <200903070020.n270KsCZ017753@raisinbran.srv.cs.cmu.edu> References: <200903070020.n270KsCZ017753@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] new SSH draft to review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:46:31 -0000 --On Friday, March 06, 2009 04:20:48 PM -0800 Wes Hardaker wrote: > > After much thinking about the text, I've modified the incoming/outgoing > EOPs quite a bit. They're a lot simpler and easier to understand I > think and incorporate all the issues people had with them. > > See what you think of them. I certainly could have made some mistakes > typo-wise since I'm too brain dead to look at them further today to > double check them (again). David will probably work on them more Monday. Looks good overall. A few minor comments. Also, remember that the I-D submission deadline is 1700 PDT today (in about 4 hours). ]] Because naming policies might differ between administrative domains, ]] many SSH client software packages support a user@hostname:port ]] addressing syntax that operators can use to align non-equivalent ]] account names. The SnmpSSHAddress Textual Convention supports this ]] common SSH notation. s/supports this common SSH notation/echoes this common SSH notation/ We chose the syntax we did because it is in common use and thus will be familiar to many users of SSH, but not to "support" the behavior of any given implementation. In particular, it is SSHTM, not SSH, which is responsible for handling an SnmpSSHAddress, breaking it apart into its constituent parts, and passing those on to the SSH layer via whatever interface is provided. Similarly with the next paragraph -- the SSH client never uses the tmSecurityName for anything; it is not part of SNMP and so never sees that field. SSHTM passes a username to the SSH client, using whatever interface the SSH implementation provides for that purpose. It may obtain that username from the transport address or from tmSecurityName, but that is done in SSHTM, _not_ in the SSH client. In 5.1(2)(A): ]] It MUST exactly and include any "user@" prefix I think you mean s/and // In 5.2(3)(B): ]] If there is a session that matches the sessionID, select that session Change to "If tmSameSecurity is true and..." s/sessionID/sessionID, tmSecurityName, and tmTransportAddress/ In 5.2(3)(C): ]] If there is a session that matches... Change to "If tmSameSecurity is false and..." From wjhns1@hardakers.net Mon Mar 9 13:54:55 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0175F3A6897 for ; Mon, 9 Mar 2009 13:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.030, 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 VPJ3FXoLzY7y for ; Mon, 9 Mar 2009 13:54:54 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 1D8A93A6816 for ; Mon, 9 Mar 2009 13:54:54 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 792ED39A0F8; Mon, 9 Mar 2009 13:55:28 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200903070020.n270KsCZ017753@raisinbran.srv.cs.cmu.edu> Date: Mon, 09 Mar 2009 13:55:28 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Mon, 09 Mar 2009 15:46:49 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] new SSH draft to review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 20:54:55 -0000 >>>>> On Mon, 09 Mar 2009 15:46:49 -0400, Jeffrey Hutzelman said: JH> --On Friday, March 06, 2009 04:20:48 PM -0800 Wes Hardaker JH> wrote: >> >> After much thinking about the text, I've modified the incoming/outgoing >> EOPs quite a bit. They're a lot simpler and easier to understand I >> think and incorporate all the issues people had with them. >> >> See what you think of them. I certainly could have made some mistakes >> typo-wise since I'm too brain dead to look at them further today to >> double check them (again). David will probably work on them more Monday. JH> Looks good overall. A few minor comments. Also, remember that the JH> I-D JH> submission deadline is 1700 PDT today (in about 4 hours). Oh, yes. I'm well aware of that at this point.... Good points on your edits and thanks for the rest of them I'm not commenting on (the changes were made). JH> Similarly with the next paragraph -- the SSH client never uses the JH> tmSecurityName for anything; it is not part of SNMP and so never sees JH> that field. SSHTM passes a username to the SSH client, using whatever JH> interface the SSH implementation provides for that purpose. It may JH> obtain that username from the transport address or from JH> tmSecurityName, but that is done in SSHTM, _not_ in the SSH client. Good point on the wording. How's this: Because naming policies might differ between administrative domains, many SSH client software packages support a user@hostname:port addressing syntax that operators can use to align non-equivalent account names. The SnmpSSHAddress Textual Convention echos this common SSH notation. When this notation is used in an SnmpSSHAddress, the SSH connection should be established with a SSH user name matching the "user" portion of the notation when establishing a session with the remote SSH server. The "user" portion may or may not match the tmSecurityName parameter passed from the security model. If no "user@" portion is specified in the SnmpSSHAddress, then the SSH connection should be established using the tmSecurityName as the SSH user name when establishing a session with the remote SSH server. (it's annoyingly hard to write generic text like that). JH> In 5.2(3)(C): JH> ]] If there is a session that matches... JH> Change to "If tmSameSecurity is false and..." Ok, then how's this: 3. Identify an SSH session to send the messages over: A. If tmSameSecurity is true and there is no existing session with a matching sessionID, tmSecurityName and tmTransportAddress, then increment the sshtmSessionNoAvailableSessions counter, discard the message and return the error indication in the statusInformation. Processing of this message stops. B. If there is a session with a matching sessionID, tmTransportAddress and tmSecurityName, then select that session. C. If there is a session that matches the tmTransportAddress and tmSecurityName, then select that session. D. If the above steps failed to select a session to use, then call openSession() with the tmStateReference as a parameter. + If openSession fails, then discard the message, release tmStateReference and pass the error indication returned by openSession back to the calling module. Processing stops for this message. + If openSession succeeds, then record the destTransportDomain, destTransportAddress, tmSecurityname and tmSessionID in an implementation-dependent manner. This will be needed when processing an incoming message. That should ensure that: - tmSameSecurity=true requires an exact session match - tmSameSecurity=false allows selecting on the same session, or a matching session (just address and name but not sessionID) or creates an entirely new one. -- Wes Hardaker Sparta, Inc. From jhutz@cmu.edu Mon Mar 9 14:07:07 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7553A68B2 for ; Mon, 9 Mar 2009 14:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFcUNgupAb6A for ; Mon, 9 Mar 2009 14:07:07 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id EF0B63A68A9 for ; Mon, 9 Mar 2009 14:07:06 -0700 (PDT) Received: from 68-247-180-249.pools.spcsdns.net (72-61-128-224.pools.spcsdns.net [72.61.128.224]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n29L7Zqs019715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 17:07:37 -0400 (EDT) Date: Mon, 09 Mar 2009 17:07:35 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: In-Reply-To: References: <200903070020.n270KsCZ017753@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] new SSH draft to review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:07:08 -0000 --On Monday, March 09, 2009 01:55:28 PM -0700 Wes Hardaker wrote: > Good points on your edits and thanks for the rest of them I'm not > commenting on (the changes were made). > > JH> Similarly with the next paragraph -- the SSH client never uses the > JH> tmSecurityName for anything; it is not part of SNMP and so never sees > JH> that field. SSHTM passes a username to the SSH client, using whatever > JH> interface the SSH implementation provides for that purpose. It may > JH> obtain that username from the transport address or from > JH> tmSecurityName, but that is done in SSHTM, _not_ in the SSH client. > > Good point on the wording. How's this: Looks good. > B. If there is a session with a matching sessionID, > tmTransportAddress and tmSecurityName, then select that > session. > - tmSameSecurity=false allows selecting on the same session, or a > matching session (just address and name but not sessionID) or creates > an entirely new one. My reading was that tmSessionID was meaningless unless tmSameSecurity is true, and so I was trying to arrive at wording that ensures that the sessionID is not used when tmSameSecurity is not true. If the intent is that the sessionID may be valid even when tmSameSecurity is false, then this latest text is good. -- Jeff From wjhns1@hardakers.net Mon Mar 9 14:12:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94413A68B2 for ; Mon, 9 Mar 2009 14:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.029, 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 BD-BwLn8m523 for ; Mon, 9 Mar 2009 14:12:10 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 03B0D3A6C95 for ; Mon, 9 Mar 2009 14:12:10 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 3541A39A0F8; Mon, 9 Mar 2009 14:12:44 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <200903070020.n270KsCZ017753@raisinbran.srv.cs.cmu.edu> Date: Mon, 09 Mar 2009 14:12:43 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Mon, 09 Mar 2009 17:07:35 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] new SSH draft to review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:12:10 -0000 >>>>> On Mon, 09 Mar 2009 17:07:35 -0400, Jeffrey Hutzelman said: JH> My reading was that tmSessionID was meaningless unless tmSameSecurity JH> is true, and so I was trying to arrive at wording that ensures that JH> the sessionID is not used when tmSameSecurity is not true. If the JH> intent is that the sessionID may be valid even when tmSameSecurity is JH> false, then this latest text is good. I think most people will have a cache that points sessionID -> real pointer much faster than doing a lookup on just secName and address. Most importantly, if there are multiple sessions established "for some reason" that both have the same address and secName then we should always prefer the one with a matching sessionID if it exists. (we don't discuss multiple sessions with matching parameters and don't say we're suggesting people support it, but I don't think we should write the rules so that it's prohibited if an implementation wants to do it) -- Wes Hardaker Sparta, Inc. From jhutz@cmu.edu Mon Mar 9 14:19:57 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C97C3A680C for ; Mon, 9 Mar 2009 14:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 cod2p6-ajSeX for ; Mon, 9 Mar 2009 14:19:56 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 844593A6B29 for ; Mon, 9 Mar 2009 14:19:56 -0700 (PDT) Received: from 68-247-180-249.pools.spcsdns.net (72-61-128-224.pools.spcsdns.net [72.61.128.224]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n29LKPSp019978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 17:20:26 -0400 (EDT) Date: Mon, 09 Mar 2009 17:20:25 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: <808A8DAD480FEC6DDE829A2E@atlantis.pc.cs.cmu.edu> In-Reply-To: References: <200903070020.n270KsCZ017753@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] new SSH draft to review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:19:57 -0000 --On Monday, March 09, 2009 02:12:43 PM -0700 Wes Hardaker wrote: >>>>>> On Mon, 09 Mar 2009 17:07:35 -0400, Jeffrey Hutzelman >>>>>> said: > > JH> My reading was that tmSessionID was meaningless unless tmSameSecurity > JH> is true, and so I was trying to arrive at wording that ensures that > JH> the sessionID is not used when tmSameSecurity is not true. If the > JH> intent is that the sessionID may be valid even when tmSameSecurity is > JH> false, then this latest text is good. > > I think most people will have a cache that points sessionID -> real > pointer much faster than doing a lookup on just secName and address. > > Most importantly, if there are multiple sessions established "for some > reason" that both have the same address and secName then we should > always prefer the one with a matching sessionID if it exists. Provided there _is_ a sessionID, which was the point I was unclear on and, perhaps, still am. But as long as we're clear on when the sessionID is expected to be present, I think we're fine. From root@core3.amsl.com Mon Mar 9 14:30:02 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2952D3A6CAC; Mon, 9 Mar 2009 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309213002.2952D3A6CAC@core3.amsl.com> Date: Mon, 9 Mar 2009 14:30:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-15.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Transport Model for SNMP Author(s) : D. Harrington, et al. Filename : draft-ietf-isms-secshell-15.txt Pages : 43 Date : 2009-03-09 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-15.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-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09142629.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Mar 9 14:30:02 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 606F03A696F; Mon, 9 Mar 2009 14:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309213002.606F03A696F@core3.amsl.com> Date: Mon, 9 Mar 2009 14:30:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-transport-security-model-12.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Security Model for SNMP Author(s) : D. Harrington, W. Hardaker Filename : draft-ietf-isms-transport-security-model-12.txt Pages : 32 Date : 2009-03-09 This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09142651.I-D@ietf.org> --NextPart-- From clonvick@cisco.com Mon Mar 9 19:12:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D6D3A6991 for ; Mon, 9 Mar 2009 19:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 bk0ZnfaMRj83 for ; Mon, 9 Mar 2009 19:12:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C8E6D3A6900 for ; Mon, 9 Mar 2009 19:12:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,333,1233532800"; d="scan'208";a="264360404" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2009 02:12:50 +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 n2A2CoAn030812; Mon, 9 Mar 2009 19:12:50 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2A2Co2l018155; Tue, 10 Mar 2009 02:12:50 GMT Date: Mon, 9 Mar 2009 19:12:50 -0700 (PDT) From: Chris Lonvick To: "Joseph Salowey (jsalowey)" In-Reply-To: Message-ID: References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> <000601c99e49$b2c18d00$0601a8c0@allison> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7643; t=1236651170; x=1237515170; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Isms]=20SSH=20always=20provides=20a=20 username |Sender:=20; bh=/UXt7JzODEL/ehi68FWKohjOk8TbSUtRJmW7Dc/kXZk=; b=ndaoQFNLfJ/TRPU2TE9njZXyYHdwh0DmGoIe4OGi1X9rM6esMU79AI12eP sF79/fZhn4ezAF5/NENxdYciFxZyCNHrVlD8rsxTnX/3X/mLulmLHxeyRrWv ThwtqknG6K; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] SSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 02:12:17 -0000 Hi, I would add my support to the consensus that the conclusions reached on this thread are correct. The following offers an explanation of why explicit authentication is not always required. The initial intention for SSH was to secure the "r tools": rlogin, rsh, rcp, and rdist. The trust mechanisms for those were host-level equivalence and device-level equivalence. For the former, an administrator or user identified that an account on one machine was equivalent to an account on a different machine - that they had the same user. For the latter, an administrator ensured equivalency of the user accounts and informed the machines that they could trust each other for this purpose. In both cases, a username was always provided but in some cases authentication was implied since trust was already established. >From those humble beginnings, ;-) SSH has evolved into many different things. Most of those things, like isms, do not depend upon upon trust models like those and the isms documents should be explicit in its trust model and authentication scheme. If the SSH documents are not clear about filling in a username field, then I believe that's on oversight due to the lengthy editing process and not the intent. Best regards, Chris On Fri, 6 Mar 2009, Joseph Salowey (jsalowey) wrote: > > >> -----Original Message----- >> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On >> Behalf Of tom.petch >> Sent: Friday, March 06, 2009 1:22 AM >> To: Jeffrey Hutzelman; isms@ietf.org >> Cc: jhutz@cmu.edu >> Subject: Re: [Isms] SSH always provides a username >> >> ---- Original Message ----- >> From: "Jeffrey Hutzelman" >> To: >> Cc: >> Sent: Thursday, March 05, 2009 10:36 PM >> Subject: [Isms] SSH always provides a username >> >> >>> draft-ietf-isms-secshell-14.txt section 4.1.1 contains the >> following: >>> >>> 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 an SSH identity to a >>> tmSecurityName, or to transform a tmSecurityName to an SSH >>> identity. >>> >>> 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. >>> >>> This is not true; it is a misinterpretation of the details of >>> operation of a particular SSH user authentication method >> which happen >>> below the abstraction visible to SSHTM. While the GSS-API user >>> authentication method described in RFC4462 does allow the >> "username" >>> field on the wire to be empty, this is permitted only in >> cases where >>> the SSH server (NOT a subsystem such as SNMP) is able to infer a >>> username from the client's GSS-API credentials. SSH will >> always report an authenticated username. >>> >>> Similarly, if the SSH server allows the connection, it has >> determined >>> that the client is authorized for the requested username. >> The claim >>> that "the user name may not be verified by the server" >> would seem to >>> be a reference to the "none" user authentication method, in >> which the >>> server may choose to allow access with no further authentication. >>> This is functionally equivalent to using password >> authentication but >>> allowing any password, or using a well-known SNMP community string >>> like "public" -- weak, but operating as designed. >>> >>> In no case should SSHTM "obtain the user name from other >> credentials >>> exchanged during the SSH exchange"; this would be a serious >> violation >>> of the abstraction boundary between SSHTM and SSH. >>> >>> I propose to eliminate these two paragraphs, and make the >> following change: >>> >>> OLD: >>> >>> On the SSH server side of a connection: >>> >>> The tmSecurityName SHOULD be the value of the user >> name field of >>> the SSH_MSG_USERAUTH_REQUEST message for which a >>> SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH >> user name is >>> extracted from the SSH layer is implementation-dependent. >>> >>> NEW: >>> >>> On the SSH server side of a connection: >>> >>> The tmSecurityName SHOULD be the SSH user name. How >> the SSH user >>> name is extracted from the SSH later is >> implementation-dependent. >>> >>> >>> This eliminates the inappropriate reference to details of the SSH >>> protocol, which is also an abstraction violation. SSHTM has no >>> business knowing that the username came from a particular >> field of a >>> particular SSH protocol message, especially when that may >> not actually be the case. >>> >> >> Jeff >> >> What you say seems fine but I find this horribly difficult, >> especially over e-mail. I do not know enough about ssh to >> know whether your words are more accurate or not. >> >> What I do know is that the current wording was supplied by Joe Salowey >> (28nov2008) and when he did, I annotated my copy of sshtm >> with comment 'supplied by Joe so must be right' ie I do not >> know enough to judge the accuracy of this. >> This text was proposed in response to a difficulty so it is >> there for a reason. >> >> You and Joe both know much more about ssh than I and when you >> say what I perceive to be different things, I struggle to >> know which to support. I look in other places - you >> contributed more on the ssh list but I see more of Joe >> contributing outside the IETF - and find myelf on the fence. >> >> Perhaps the 'proper' resolution is for Joe to speak up and >> say, yes, this is fine but I cannot rely on that happening. >> > [Joe] Yes this is fine, explanation below. > >> The worst outcome is that, during a future review, Joe speaks >> up and says change it back again because .... >> > >> So, I am on the fence, and not comfortable with it. >> > [Joe] I agree with Jeffrey that the current text has too many SSH > specifics in it and I would like to see that changed (I think I > suggested it in the past, but I probably didn't express myself well). > My main concern is that the protocol field in the SSH message may not be > filled in. It is true that SSH knows what the authenticated name is. > It is true for RFC 4462 that if the user name is present it should be > authorized, but the core SSH drafts don't require this, so it might not > be true for other mechanisms. In any case, how the SSH username is > extracted from the SSH protocol is implementation specific. > > I think Jeffrey's text is good (s/later/layer). I am tempted to > request that we say something like "It is the responsibility of the SSH > layer ensure that the user name is valid and authenticated", but I can > live without this because it really should be the case in a reasonable > implementation. > > Hopefully this helps clear things up. > > > >> Tom Petch >> >>> -- Jeff >>> _______________________________________________ >>> 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 jhutz@cmu.edu Mon Mar 9 19:24:12 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6263A698E for ; Mon, 9 Mar 2009 19:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.514, 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 JZyvXYOAFbvl for ; Mon, 9 Mar 2009 19:24:11 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 83E173A6900 for ; Mon, 9 Mar 2009 19:24:11 -0700 (PDT) Received: from 68-247-180-249.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n2A2OcTp024741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 22:24:39 -0400 (EDT) Date: Mon, 09 Mar 2009 22:24:38 -0400 From: Jeffrey Hutzelman To: Chris Lonvick , "Joseph Salowey (jsalowey)" Message-ID: <52AB3BCEC91FA3A2AB213BE5@atlantis.pc.cs.cmu.edu> In-Reply-To: References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> <000601c99e49$b2c18d00$0601a8c0@allison> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] SSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 02:24:12 -0000 --On Monday, March 09, 2009 07:12:50 PM -0700 Chris Lonvick wrote: > If the SSH documents are not clear about filling in a username field, > then I believe that's on oversight due to the lengthy editing process and > not the intent. Yeah, in retrospect, the language in the description of hostbased could have been more transparent on this point, but I don't see it as a major problem. I very much doubt there is both a client out there that uses hostbased and leaves the "wrong" username field empty _and_ a server that actually accepts such a request, and even if there is, such a server would have to come up with a username somehow, unless it was running in an environment where nothing cared what the username was. SSHTM is clearly _not_ such an environment. Also in retrospect, rather than allowing the client username to be empty in hostbased user auth, we should have made it an optional field with a boolean indicating whether it is present, as was done in so many other cases. Isn't hindsight wonderful? -- Jeff From wjhns1@hardakers.net Mon Mar 9 20:08:58 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618883A6A90 for ; Mon, 9 Mar 2009 20:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.028, 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 0Mji9yCAFFai for ; Mon, 9 Mar 2009 20:08:57 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id B94C23A6961 for ; Mon, 9 Mar 2009 20:08:57 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 7B9242C3375; Mon, 9 Mar 2009 20:09:32 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <3A4702CF8F415FE53F1977E9@atlantis.pc.cs.cmu.edu> <000601c99e49$b2c18d00$0601a8c0@allison> <52AB3BCEC91FA3A2AB213BE5@atlantis.pc.cs.cmu.edu> Date: Mon, 09 Mar 2009 20:09:32 -0700 In-Reply-To: <52AB3BCEC91FA3A2AB213BE5@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 09 Mar 2009 22:24:38 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] SSH always provides a username X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 03:08:58 -0000 >>>>> On Mon, 09 Mar 2009 22:24:38 -0400, Jeffrey Hutzelman said: >> If the SSH documents are not clear about filling in a username field, >> then I believe that's on oversight due to the lengthy editing process and >> not the intent. JH> Yeah, in retrospect, the language in the description of hostbased JH> could have been more transparent on this point, but I don't see it as JH> a major problem. I'd appreciate it if you'd check the diff on the just published draft and let me know if you think the wording in this respect is incorrect anywhere. I think it matches your expectations but it would be excellent if you could confirm that. -- Wes Hardaker Sparta, Inc. From d.b.nelson@comcast.net Mon Mar 9 20:34:34 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1833A6B29 for ; Mon, 9 Mar 2009 20:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_40=-0.185] 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 qW5ELAzx2W78 for ; Mon, 9 Mar 2009 20:34:33 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 582703A67B4 for ; Mon, 9 Mar 2009 20:34:33 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA04.westchester.pa.mail.comcast.net with comcast id RCr01b00c0cZkys54Fb8ne; Tue, 10 Mar 2009 03:35:08 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA10.westchester.pa.mail.comcast.net with comcast id RFb81b00B4H2mdz3WFb8Kb; Tue, 10 Mar 2009 03:35:08 +0000 From: "Dave Nelson" To: References: <49B5DA68.50905@deployingradius.com> Date: Mon, 9 Mar 2009 23:35:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49B5DA68.50905@deployingradius.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcmhLn3sgbkJhL7rQPOqGnH6gWs4rgAAllyA Cc: isms@ietf.org Subject: Re: [Isms] FW: radius usage last call followup X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 03:34:35 -0000 Alan DeKok writes... > > Please check the changes until March 23rd. > > Security Section: > > There are good reasons to provision USM access so supplement with > AAA-based access, however. > > > NIT: This doesn't appear to be a sentence. Yeah. Let's see what that was supposed to say... I think it's: There are good reasons to provision USM access to supplement AAA-based access, however. From j.schoenwaelder@jacobs-university.de Tue Mar 10 05:53:16 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608513A6A24 for ; Tue, 10 Mar 2009 05:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.151, 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 WvRbYbkwotHy for ; Tue, 10 Mar 2009 05:53:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 16E9F3A6814 for ; Tue, 10 Mar 2009 05:53:12 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D385EC0027; Tue, 10 Mar 2009 13:53:46 +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 CYPtZ3uDwmG2; Tue, 10 Mar 2009 13:53:45 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CA2AC0022; Tue, 10 Mar 2009 13:53:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C348EA01B19; Tue, 10 Mar 2009 13:53:43 +0100 (CET) Date: Tue, 10 Mar 2009 13:53:43 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090310125343.GA27223@elstar.local> Mail-Followup-To: isms@ietf.org, Pasi Eronen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Pasi Eronen Subject: [Isms] isms wg status and actions X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 12:53:16 -0000 I like to summarize how I see the status of the ISMS WG at this point in time by looking at our four chartered documents: 1) Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models A new version was posted by David Nelson on March 8th incorporating WG last call feedback. I asked people to check the changes until March 23rd. Dan Romascanu was so kind to forward this message to the RADIUSEXT WG and so far we received one editorial nit. If no technical issues are raised, then this document will be ready to be delivered to Pasi by the upcoming IETF meeting. 2) Transport Subsystem for the Simple Network Management Protocol (SNMP) The latest version was posted on February 25th and I asked people on February 26th to check the changes and to report by March 6th. My reading of the mailing list is that no issues were raised and hence I conclude that this document is ready to be delivered to Pasi. I take the token to produce the necessary document writeups. 3) Transport Security Model for SNMP A new version was posted on March 9th incorporating changes discussed recently on the mailing list. The changes are very minor, essentially removing the rtr-nyc4@ example since the user@ notation is considered with rough consensus to be SSH specific. I do not think there are any other outstanding open issues with this document. So please check the changes and if I do not hear about technical problems by March 23rd, I consider this document ready to be delivered to Pasi by the upcoming IETF meeting. 4) Secure Shell Transport Model for SNMP Most of the recent email discussion (which I think we quite productive in moving things forward - thanks folks!) centered around this document. A new version was posted on March 9th incorporating changes that were discussed on the mailing list. In short, additional explanatory text was added to motivate the user@ notation and the elements of procedure have been rewritten in an attempt to simplify them. Please review this new version and let us know by March 23rd whether there are any technical showstoppers left. Please post issues as soon as possible so that we can continue working on resolutions as much as possible here on the list before the IETF meeting. Please let me know if you disagree with my assessment where we are with our chartered work item. I believe we are really very close to be done - so lets try to finish this and deliver by the next IETF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Mar 10 06:26:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2EC28C124 for ; Tue, 10 Mar 2009 06:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.148, 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 EEzzPgb5wFyl for ; Tue, 10 Mar 2009 06:26:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 85D7328B797 for ; Tue, 10 Mar 2009 06:26:04 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A452C0028 for ; Tue, 10 Mar 2009 14:26:39 +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 MAWj3OwKy78g; Tue, 10 Mar 2009 14:26:37 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EBADC0022; Tue, 10 Mar 2009 14:26:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 02F9AA01CB9; Tue, 10 Mar 2009 14:26:35 +0100 (CET) Date: Tue, 10 Mar 2009 14:26:35 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090310132635.GB27521@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] isms meeting in san francisco X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 13:26:06 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, as some of you might have noticed, I allocated an ISMS meeting slot in San Francisco. My original plan was that we would not need this slot since we have delivered all our chartered documents by the next IETF. Since the meeting has been scheduled for Thursday March 26, we can still reach this goal if we keep working productively. That said, I have to inform you that I won't be able to make it to San Francisco but I will join via Jabber. I asked Bert Wijnen whether he is willing to chair the session as he did last time and he agreed to it. Juergen Quittek, one of our earlier ISMS co-chairs, will also be present and serve as a note taker. I am attaching a draft meeting agenda. If we manage to deliver our chartered documents, the meeting will be short. Pasi and I agree that the ISMS WG should go dormant once the WG has delivered the chartered documents. There is, however, work done on alternate secure transports (DTLS) and so I have allocated some time in the agenda to discuss how this work should proceed, e.g., via the individual submission path or perhaps through the OPSAWG, to name a few options. I hope we can get Pasi and Dan into the room to help us sort this out. That said, please go an read the revised documents so that we can make this meeting short and an enjoyable event. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-agenda.txt" ============================================================= Integrated Security Model for SNMP WG (isms) IETF #74, San Francisco THURSDAY, March 26, 2008, 1510-1610, Continental 1&2 ============================================================= WG 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) Delivery celebration | issue resolution (5 | 30 min) (David Harrington) - 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) Handling of ISMS related drafts ( 5 min) (Pasi Eronen, Dan Romascanu) 4) Wrap up and review of action items ( 5 min) (Bert Wijnen) 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) [7] Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management --wRRV7LY7NUeQGEoC-- From cfinss@dial.pipex.com Tue Mar 10 11:15:15 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF6E28C20C for ; Tue, 10 Mar 2009 11:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] 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 3T6ELtqw7jgR for ; Tue, 10 Mar 2009 11:15:14 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 2DDC93A6D1B for ; Tue, 10 Mar 2009 11:14:55 -0700 (PDT) X-Trace: 227033577/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.231/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.231 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: ArEEAD9Ltkk+vBHn/2dsb2JhbACDJDESigy2VAePAQeEBQaGbQ X-IronPort-AV: E=Sophos;i="4.38,337,1233532800"; d="scan'208";a="227033577" X-IP-Direction: IN Received: from 1cust231.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.231]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Mar 2009 18:15:26 +0000 Message-ID: <000501c9a1a3$9346c640$0601a8c0@allison> From: "tom.petch" To: "Jeffrey Hutzelman" , "Wes Hardaker" References: <200903070020.n270KsCZ017753@raisinbran.srv.cs.cmu.edu> <808A8DAD480FEC6DDE829A2E@atlantis.pc.cs.cmu.edu> Date: Tue, 10 Mar 2009 17:37:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] new SSH draft to review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:15:15 -0000 ---- Original Message ----- From: "Jeffrey Hutzelman" To: "Wes Hardaker" Cc: ; Sent: Monday, March 09, 2009 10:20 PM Subject: Re: [Isms] new SSH draft to review > --On Monday, March 09, 2009 02:12:43 PM -0700 Wes Hardaker > wrote: > > >>>>>> On Mon, 09 Mar 2009 17:07:35 -0400, Jeffrey Hutzelman > >>>>>> said: > > > > JH> My reading was that tmSessionID was meaningless unless tmSameSecurity > > JH> is true, and so I was trying to arrive at wording that ensures that > > JH> the sessionID is not used when tmSameSecurity is not true. If the > > JH> intent is that the sessionID may be valid even when tmSameSecurity is > > JH> false, then this latest text is good. > > > > I think most people will have a cache that points sessionID -> real > > pointer much faster than doing a lookup on just secName and address. > > > > Most importantly, if there are multiple sessions established "for some > > reason" that both have the same address and secName then we should > > always prefer the one with a matching sessionID if it exists. > > Provided there _is_ a sessionID, which was the point I was unclear on and, > perhaps, still am. But as long as we're clear on when the sessionID is > expected to be present, I think we're fine. tmSessionID will not always exist and must be valid when tmSameSecurity is false, namely in the NO/CG at least prior to the first message when that message establishes the session. We need tmSessionID in CR to ensure that a Response goes back over the same session as the Request came in on; that is the easy one, tmSessionID must exist, can always be used to identify the session, tmSecurityName and tmTransportAddress are not needed for that purpose, could be omitted. We need tmSessionID in CG. Prior to the first message establishing a session, there can be no tmSessionID (IMHO). So coming down the stack to sshtm, the session is identified by tmSecurityName and tmTransportAddress, sshtm says uniquely so (s.3.1.4). openSession creates and stores tmSessionID alongside tmSecurityName and tmTransportAddress. When a Response arrives in CG, tmSessionID enables sshtm to extract tmSecurityName and tmTransportAddress so that MPP gets back the values it saw earlier and so passes the Response to the right place (MPP has no knowledge of tmStateReference). SSH does not know the correct tmSecurityName (when SSH username comes from user@) and tmTransportAddress (eg lacks user@), only sshtm can do the mapping back to the correct tmSecurityName+tmTransportAddress from tmSessionID. When CG/NO send subsequent messages down the stack, tmSessionID exists but they can have no knowledge of it, they can only (implicitly) use tmSecurityName and tmTransportAddress to identify the session to sshtm (uniquely so, as s.3.1.4.says). Hence, in CG, 5.2 3) C applies, then 5.1 2) A and 3) A using the unmentioned tmSessionID to derive tmSecurityName and tmTransportAddress. In CR, in 5.1 2) and 3), I do not really follow the distinction between B and C. (My take is that for the first message, sshtm is fed tmSessionID with matching tmSecurityName+tmTransportAddress and for subsequent ones it only uses tmSessionID to extract the two last from a cache, but that may just be my way of implementing). Then we have 5.2 3) A. 5.2 3 B) (outbound, all three matching) I cannot see happening, anywhere. If a session is pre-established, as sshtm allows, then the session will exist, arguably so will a tmSessionID, but this will not be used by sshtm until CG/NO sends a first messsage whereupon openSession will be a No-OP and sshtm will cache the tmSessionID alongside the tmSecurityName and tmTransportAddress. If you say that tmSessionID only exists in a CR with tmSameSecurity set to true, then you need something with exactly the same semantics in CG to tie together the three parameters. I am calling that tmSessionID, as 5.3 sort of says. sessionID or tmSessionID? I think that they are the same and that we should only use the one term because securityName and tmSecurityName are different and we spell that out. Hence I use tmSessionID. There is nothing in sstm-15 to gainsay what I have described above although in places, the wording might be clearer. Tom Petch _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From cfinss@dial.pipex.com Tue Mar 10 11:21:54 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED433A684C for ; Tue, 10 Mar 2009 11:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] 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 wg4iLHIHuxld for ; Tue, 10 Mar 2009 11:21:53 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 6A3043A6407 for ; Tue, 10 Mar 2009 11:21:45 -0700 (PDT) X-Trace: 227035542/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.231/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.231 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: ArEEAGtMtkk+vBHn/2dsb2JhbACDJEOKDLZdCY8AAQaCRBCBMQY X-IronPort-AV: E=Sophos;i="4.38,337,1233532800"; d="scan'208";a="227035542" X-IP-Direction: IN Received: from 1cust231.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.231]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Mar 2009 18:22:18 +0000 Message-ID: <001b01c9a1a4$88bf0ba0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20090310125343.GA27223@elstar.local> Date: Tue, 10 Mar 2009 18:19:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Pasi Eronen Subject: Re: [Isms] isms wg status and actions X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:21:54 -0000 Juergen tmsm has a 'implementatioins' in 3.3.1 to be revised at some point. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Cc: "Pasi Eronen" Sent: Tuesday, March 10, 2009 1:53 PM Subject: [Isms] isms wg status and actions > I like to summarize how I see the status of the ISMS WG at this point > in time by looking at our four chartered documents: > > 1) Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > A new version was posted by David Nelson on March 8th incorporating > WG last call feedback. I asked people to check the changes until > March 23rd. Dan Romascanu was so kind to forward this message to > the RADIUSEXT WG and so far we received one editorial nit. If no > technical issues are raised, then this document will be ready to be > delivered to Pasi by the upcoming IETF meeting. > > 2) Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > The latest version was posted on February 25th and I asked people > on February 26th to check the changes and to report by March 6th. > My reading of the mailing list is that no issues were raised and > hence I conclude that this document is ready to be delivered to > Pasi. I take the token to produce the necessary document writeups. > > 3) Transport Security Model for SNMP > > > A new version was posted on March 9th incorporating changes > discussed recently on the mailing list. The changes are very minor, > essentially removing the rtr-nyc4@ example since the user@ notation > is considered with rough consensus to be SSH specific. I do not > think there are any other outstanding open issues with this > document. So please check the changes and if I do not hear about > technical problems by March 23rd, I consider this document ready to > be delivered to Pasi by the upcoming IETF meeting. > > 4) Secure Shell Transport Model for SNMP > > > Most of the recent email discussion (which I think we quite > productive in moving things forward - thanks folks!) centered > around this document. A new version was posted on March 9th > incorporating changes that were discussed on the mailing list. In > short, additional explanatory text was added to motivate the user@ > notation and the elements of procedure have been rewritten in an > attempt to simplify them. Please review this new version and let us > know by March 23rd whether there are any technical showstoppers > left. Please post issues as soon as possible so that we can > continue working on resolutions as much as possible here on the > list before the IETF meeting. > > Please let me know if you disagree with my assessment where we are > with our chartered work item. I believe we are really very close to be > done - so lets try to finish this and deliver by the next IETF. > > /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 wjhns1@hardakers.net Tue Mar 10 19:02:24 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CB63A6A83 for ; Tue, 10 Mar 2009 19:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVgLd8uZNTqp for ; Tue, 10 Mar 2009 19:02:23 -0700 (PDT) Received: from wes.hardakers.net (ip-207-145-35-98.iad.megapath.net [207.145.35.98]) by core3.amsl.com (Postfix) with ESMTP id 9C80C3A677C for ; Tue, 10 Mar 2009 19:02:21 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 7D72C39A0FE; Tue, 10 Mar 2009 11:53:07 -0700 (PDT) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <200903070020.n270KsCZ017753@raisinbran.srv.cs.cmu.edu> <808A8DAD480FEC6DDE829A2E@atlantis.pc.cs.cmu.edu> <000501c9a1a3$9346c640$0601a8c0@allison> Date: Tue, 10 Mar 2009 11:53:06 -0700 In-Reply-To: <000501c9a1a3$9346c640$0601a8c0@allison> (tom petch's message of "Tue, 10 Mar 2009 17:37:01 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] new SSH draft to review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 02:02:24 -0000 David H: make sure you read the line starting with **** >>>>> On Tue, 10 Mar 2009 17:37:01 +0100, "tom.petch" said: tp> tmSessionID will not always exist and must be valid when tp> tmSameSecurity is false, namely in the NO/CG at least prior to the tp> first message when that message establishes the session. You seem to be saying conflicting things there. You say it won't always exist but must be valid? Possibly because the word "exist" implies both existing in the processing point of view and in the global "a live session with this sessionID exists". - It won't passed for the first message going out. - It will have to be passed and match for replies (in which case, tmSameSecurity should be true because TSM will have set it). A session may exist, but the SSHTM can look up the session from the address and name ***as long as tmSameSecurity is false***. - it won't necessarily be passed for other messages going out (other GETs/GETNEXTs/INFORMs). tp> When a Response arrives in CG, tmSessionID enables sshtm to extract tp> tmSecurityName and tmTransportAddress so that MPP gets back the tp> values it saw earlier and so passes the Response to the right place tp> (MPP has no knowledge of tmStateReference). Most implementations will likely use some sort of sessionID for handling this, but the details are actually implementation specific and don't need to be standardized. Most implementations will probably just use a pointer a file-handle, I'd assume. Anything that can be used to communicate the proper session stream to the SSHTM. tp> SSH does not know the correct tmSecurityName (when SSH username tp> comes from user@) and tmTransportAddress (eg lacks user@), only tp> sshtm can do the mapping back to the correct tp> tmSecurityName+tmTransportAddress from tmSessionID. from "something". Again, it doesn't need to be standardized strictly speaking (but then, I think a lot of what is documented doesn't need to be spelled out as strictly; we're trying to define the V3 architecture so we spell things out more completely). The layer between SSHTM and SSH is *not* being standardized except minimally where necessary (more requirements of the interface than standardization). The layer between SSHTM and "up" (through the V3 arch to the application) is the layers that are getting careful and specific wording and standardization. What does need to happen for TMSM and above to work is to somehow, when a message comes in, to be able to associate the correct tmSessionID, tmTransportAddress and tmSecurityname with it. How this happens is implementation dependent. It doesn't matter if all 3 are cached in one location, or only the (unique) sessionID and then that is used as a lookup to retrieve the other two. The important thing is that all 3 are available for every incoming message. Section 5.1 steps 2 and 3 spell this out with great detail to discuss what exact values must be cached/held/matched/whatever from previous points in time. tp> When CG/NO send subsequent messages down the stack, tmSessionID tp> exists but they can have no knowledge of it, they can only tp> (implicitly) use tmSecurityName and tmTransportAddress to identify tp> the session to sshtm (uniquely so, as s.3.1.4.says). Yep. tp> Hence, in CG, 5.2 3) C applies, then 5.1 2) A and 3) A using the tp> unmentioned tmSessionID to derive tmSecurityName and tp> tmTransportAddress. That may be how an implementation does it. Or they may cache the address directly with the session if they're working with a stack that can cache the address directly within a structure that is passed around. It's implementation dependent. tp> In CR, in 5.1 2) and 3), I do not really follow the distinction tp> between B and C. As the first sentence says of each Bs: The B step is for the first message transported on the SSH server side and step C is for all others transported on the SSH server side. I think the wording is pretty clear. tp> 5.2 3 B) (outbound, all three matching) I cannot see happening, tp> anywhere. If TSM specifies all three *and* tmSameSecurity is true, then this step has to happen. If tmSameSecurity is false, it becomes a "may happen". I'm not sure why you can't see it happening? tp> sessionID or tmSessionID? Well, I think the wording could go either way. Right now it's worded so that the sessionID is generic to the SSH stack and cache of sessions, tmSessionID is specific to the SSHTM. Much of the time the tmSessionID is used to look through all the sessionIDs in the stack to find the matching one. Or on the incoming side, the tmSessionID is assigned based on the incoming sessionID. I think it's probably safe to convert everything to the same term, but I also think it's fine as is. -- Wes Hardaker Sparta, Inc. From cfinss@dial.pipex.com Wed Mar 11 03:26:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B748A3A6B69 for ; Wed, 11 Mar 2009 03:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, 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 nbPXiwlocAKS for ; Wed, 11 Mar 2009 03:26:27 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 85C7B3A6B62 for ; Wed, 11 Mar 2009 03:26:26 -0700 (PDT) X-Trace: 227188121/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.214/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.214 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: Ai8FAJgut0k+vBPW/2dsb2JhbACDJEOKDLNhAQcBj0UBBoJFEAEMgSQG X-IronPort-AV: E=Sophos;i="4.38,341,1233532800"; d="scan'208";a="227188121" X-IP-Direction: IN Received: from 1cust214.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.214]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Mar 2009 10:26:57 +0000 Message-ID: <001201c9a22b$49fa3e80$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20090310125343.GA27223@elstar.local> Date: Wed, 11 Mar 2009 10:24:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Pasi Eronen Subject: Re: [Isms] isms wg status and actions sshtm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 10:26:31 -0000 sshtm Editorial (I think) 3.1.2 " requirements of securityLevel were met The SSH Transport Model" lacks a period 3.1.4 (end) " and/or port numbers) will each result in individual SSH sessions." suggest "different SSH sessions" since different is used earlier in the sentence. 4.1.2 tmSessionID is also used to identify sessions in an SSH client as per 5.3 6) which 4.1.2 sort of omits stressing only its role in a CR Suggest adding "tmSessionID is also used when the Secure Shell Transport Model is an SSH client in order to identify the session over which a message is received." although that might be a bit too coy. I am thinking of answering the queries from Jeff about the role of tmSessionID. 5.1.1) I read "session identifier" as code for tmSessionID. If so, I would rather see that stated explicitly. 5.3 6) does explicitly mention tmSessionID in this role. 5.1 2) C "(e.g. the value from step" suggest "(i.e. the value from step" 5.1 3) C "(e.g. the value from step" suggest "(i.e. the value from step" 5.2 3) B I think that as per Jeff's e-mail 3/9/9, this should start " B. If tmSameSecurity is true and there is a session with a matching sessionID, " 5.2.3) C ditto " C. If tmSameSecurity is false and there is a session that matches the tmTransportAddress " 5.2 3) D is interesting in that it caches the destTransport... parameters and not the tmTransport.. ones. This is correct, in the sense that the dest.. variants have come from application to Dispatcher to sshtm and need to go back to the Dispatcher with any response. But it is interesting in that sshtm has just used the tm.. variants in tmStateReference, which have come from Dispatcher to MPP to Security Model to cache to sshtm, to open a session. Could they be different? I do not think so with tsm as currently written, could be with a different Security Model. So I think that the text is correct but we might get asked if this is really right. 5.3 3) 1) "that user-name string that should be presented to the ssh server " spurious second that 5.3 3) 2) "SSH principal" should be "SSH user" 5.3 generally hyphenates user-name while the earlier parts of the I-D do not, and the MIB module throws in a few username. I would prefer consistency. RFC4252 uses user name so I would suggest that. That apart, I have not looked at the MIB module. Tom Petch ps I read in the newspapers that my ISP might go bankrupt today, so if I disappear from this list, that is why. Reading posts in the archives is easy, posting becomes rather harder:-( ----- Original Message ----- From: "Juergen Schoenwaelder" To: Cc: "Pasi Eronen" Sent: Tuesday, March 10, 2009 1:53 PM Subject: [Isms] isms wg status and actions > I like to summarize how I see the status of the ISMS WG at this point > in time by looking at our four chartered documents: > > 1) Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > A new version was posted by David Nelson on March 8th incorporating > WG last call feedback. I asked people to check the changes until > March 23rd. Dan Romascanu was so kind to forward this message to > the RADIUSEXT WG and so far we received one editorial nit. If no > technical issues are raised, then this document will be ready to be > delivered to Pasi by the upcoming IETF meeting. > > 2) Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > The latest version was posted on February 25th and I asked people > on February 26th to check the changes and to report by March 6th. > My reading of the mailing list is that no issues were raised and > hence I conclude that this document is ready to be delivered to > Pasi. I take the token to produce the necessary document writeups. > > 3) Transport Security Model for SNMP > > > A new version was posted on March 9th incorporating changes > discussed recently on the mailing list. The changes are very minor, > essentially removing the rtr-nyc4@ example since the user@ notation > is considered with rough consensus to be SSH specific. I do not > think there are any other outstanding open issues with this > document. So please check the changes and if I do not hear about > technical problems by March 23rd, I consider this document ready to > be delivered to Pasi by the upcoming IETF meeting. > > 4) Secure Shell Transport Model for SNMP > > > Most of the recent email discussion (which I think we quite > productive in moving things forward - thanks folks!) centered > around this document. A new version was posted on March 9th > incorporating changes that were discussed on the mailing list. In > short, additional explanatory text was added to motivate the user@ > notation and the elements of procedure have been rewritten in an > attempt to simplify them. Please review this new version and let us > know by March 23rd whether there are any technical showstoppers > left. Please post issues as soon as possible so that we can > continue working on resolutions as much as possible here on the > list before the IETF meeting. > > Please let me know if you disagree with my assessment where we are > with our chartered work item. I believe we are really very close to be > done - so lets try to finish this and deliver by the next IETF. > > /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 cfinss@dial.pipex.com Wed Mar 11 09:40:50 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7C03A6980 for ; Wed, 11 Mar 2009 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.465, 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 DdVR5Y290uAL for ; Wed, 11 Mar 2009 09:40:49 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 300473A6A07 for ; Wed, 11 Mar 2009 09:40:49 -0700 (PDT) X-Trace: 139179719/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.185/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.185 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: AsYEAHuGt0k+vBO5/2dsb2JhbACDJEOKDLRXB487B4QGBg X-IronPort-AV: E=Sophos;i="4.38,343,1233532800"; d="scan'208";a="139179719" X-IP-Direction: IN Received: from 1cust185.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.185]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Mar 2009 16:41:23 +0000 Message-ID: <01d401c9a25f$990675a0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <200903070020.n270KsCZ017753@raisinbran.srv.cs.cmu.edu><808A8DAD480FEC6DDE829A2E@atlantis.pc.cs.cmu.edu><000501c9a1a3$9346c640$0601a8c0@allison> Date: Wed, 11 Mar 2009 14:21:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] new SSH draft to review X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 16:40:50 -0000 ----- Original Message ----- From: "Wes Hardaker" To: "tom.petch" Cc: "Jeffrey Hutzelman" ; "Wes Hardaker" ; Sent: Tuesday, March 10, 2009 7:53 PM Subject: Re: new SSH draft to review > David H: make sure you read the line starting with **** > > >>>>> On Tue, 10 Mar 2009 17:37:01 +0100, "tom.petch" said: > > tp> tmSessionID will not always exist and must be valid when > tp> tmSameSecurity is false, namely in the NO/CG at least prior to the > tp> first message when that message establishes the session. > > You seem to be saying conflicting things there. Wes I was responding to two separate points of Jeff who was speculating about tmSessionID ie I was saying - tmSessionID will not always exist - there are times when tmSessionID must be valid even though tmSameSecurity is false AND the two together and yes, it does not make sense. The only textual change in this context that we might make to sshtm is an explicit mention of the use of tmSessionID in the CG. We have that in 5.3 for openSession which implies to me that this is what will be used inbound to identify the correct tmSecurityName and tmTransportAddress. I agree that we have a lot of details that might be considered implementation and might have been be left out. But they are there now and so should stay there. Then I look for consistency in our approach, of giving the same level of detail, be it implementation or no, for all functions and it is on this basis that I would add more detail to inbound processing for an CG. We go into a lot of detail for CR, less so for CG. Yes they can implement it in another way, but that is true for a lot of what we say, so having introduced tmSessionID in 5.3 openSession, I would add text to 5.1 and 4.1.2 to make the document coherent. See also below. > - It won't passed for the first message going out. > - It will have to be passed and match for replies (in which case, > tmSameSecurity should be true because TSM will have set it). A > session may exist, but the SSHTM can look up the session from the > address and name ***as long as tmSameSecurity is false***. > - it won't necessarily be passed for other messages going out (other > GETs/GETNEXTs/INFORMs). > > tp> When a Response arrives in CG, tmSessionID enables sshtm to extract > tp> tmSecurityName and tmTransportAddress so that MPP gets back the > tp> values it saw earlier and so passes the Response to the right place > tp> (MPP has no knowledge of tmStateReference). > > Most implementations will likely use some sort of sessionID for handling > this, but the details are actually implementation specific and don't > need to be standardized. Most implementations will probably just use a > pointer a file-handle, I'd assume. Anything that can be used to > communicate the proper session stream to the SSHTM. > > tp> SSH does not know the correct tmSecurityName (when SSH username > tp> comes from user@) and tmTransportAddress (eg lacks user@), only > tp> sshtm can do the mapping back to the correct > tp> tmSecurityName+tmTransportAddress from tmSessionID. > > from "something". Again, it doesn't need to be standardized strictly > speaking (but then, I think a lot of what is documented doesn't need to > be spelled out as strictly; we're trying to define the V3 architecture > so we spell things out more completely). The layer between SSHTM and > SSH is *not* being standardized except minimally where necessary (more > requirements of the interface than standardization). The layer between > SSHTM and "up" (through the V3 arch to the application) is the layers > that are getting careful and specific wording and standardization. > > What does need to happen for TMSM and above to work is to somehow, when > a message comes in, to be able to associate the correct tmSessionID, > tmTransportAddress and tmSecurityname with it. How this happens is > implementation dependent. It doesn't matter if all 3 are cached in one > location, or only the (unique) sessionID and then that is used as a > lookup to retrieve the other two. The important thing is that all 3 are > available for every incoming message. Section 5.1 steps 2 and 3 spell > this out with great detail to discuss what exact values must be > cached/held/matched/whatever from previous points in time. > > tp> When CG/NO send subsequent messages down the stack, tmSessionID > tp> exists but they can have no knowledge of it, they can only > tp> (implicitly) use tmSecurityName and tmTransportAddress to identify > tp> the session to sshtm (uniquely so, as s.3.1.4.says). > > Yep. > > tp> Hence, in CG, 5.2 3) C applies, then 5.1 2) A and 3) A using the > tp> unmentioned tmSessionID to derive tmSecurityName and > tp> tmTransportAddress. > > That may be how an implementation does it. Or they may cache the > address directly with the session if they're working with a stack that > can cache the address directly within a structure that is passed > around. It's implementation dependent. > > tp> In CR, in 5.1 2) and 3), I do not really follow the distinction > tp> between B and C. > > As the first sentence says of each Bs: The B step is for the first > message transported on the SSH server side and step C is for all others > transported on the SSH server side. I think the wording is pretty > clear. > > tp> 5.2 3 B) (outbound, all three matching) I cannot see happening, > tp> anywhere. > > If TSM specifies all three *and* tmSameSecurity is true, then this step > has to happen. If tmSameSecurity is false, it becomes a "may happen". > > I'm not sure why you can't see it happening? My other comment. My mistake; it will happen in a CG (I was mentally inserting a spurious condition). Jeff suggested adding 'If tmSameSecurity is true .." to B) and "If tmSameSecurity is false .." to C) which I think is correct and clearer. Then, 5.2 is outbound processing. In a CR, tmSameSecurity must be true so messages get binned in 3) A or handled by 3) B; strictly, 3 B) need only match on tmSessionID, no need for tmTransportAddress or tmSecurityName. In a CG/NO, tmSameSecurity is false, so 3) C applies; tmSessionID is unknown at this stage. Tom Petch > tp> sessionID or tmSessionID? > > Well, I think the wording could go either way. Right now it's worded so > that the sessionID is generic to the SSH stack and cache of sessions, > tmSessionID is specific to the SSHTM. Much of the time the tmSessionID > is used to look through all the sessionIDs in the stack to find the > matching one. Or on the incoming side, the tmSessionID is assigned > based on the incoming sessionID. > > I think it's probably safe to convert everything to the same term, but I > also think it's fine as is. > > -- > Wes Hardaker > Sparta, Inc. From cfinss@dial.pipex.com Tue Mar 17 03:36:09 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECE53A6A56 for ; Tue, 17 Mar 2009 03:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 XLL6MT4qbhWd for ; Tue, 17 Mar 2009 03:36:07 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 0DE073A6B6C for ; Tue, 17 Mar 2009 03:36:05 -0700 (PDT) X-Trace: 194966462/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.184/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.184 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: ApwEAO8Zv0k+vBG4/2dsb2JhbACDJYpYuA8BBwGPBgEGgjQQAQyBJgY X-IronPort-AV: E=Sophos;i="4.38,377,1233532800"; d="scan'208";a="194966462" X-IP-Direction: IN Received: from 1cust184.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.184]) by smtp.pipex.tiscali.co.uk with SMTP; 17 Mar 2009 10:36:44 +0000 Message-ID: <007301c9a6e3$a280b220$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20090310125343.GA27223@elstar.local> <001201c9a22b$49fa3e80$0601a8c0@allison> Date: Tue, 17 Mar 2009 10:32:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] isms wg status and actions sshtm - tmSessionID X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 10:36:09 -0000 I would like to give one of these topics another prod. sshtm is correct but could confuse, indeed I believe that it may already have done so. 4.1.2 gives a clear description of the role of tmSessionID in the cache and covers the case in the CR when a Response must use the same session as the Request. No other use case is mentioned there. This is fine until you reach 5.3 6) when tmSessionID appears again in the context of openSession which is clearly CG and not CR; and there is no other reference to its use in a CG. I think that this can confuse, indeed may be why Jeff suggested a fortnight ago JH> My reading was that tmSessionID was meaningless unless tmSameSecurity JH> is true, and so I was trying to arrive at wording that ensures that JH> the sessionID is not used when tmSameSecurity is not true. ie the only use case for tmSessionID is in the CR with tmSameSecurity set to true which is what 4.1.2 suggests. There is a need in the CG, as we have agreed, to identify on an inbound message the parameters with which the session was set up so that these can be passed to the Dispatcher else the message cannot get to the right application with the right parameters. I see this as so close to the use of tmSessionID in a CR that we should call it tmSessionID, indeed that is what I read into the current text in openSession. But then I think this needs alluding to in 4.1.2 eg by adding "tmSessionID may also be used to ensure that the correct parameters are associated with an incoming Response so that the message is passed correctly to the application" and by slotting into the middle of 5.1 1) "This may be achieved by the use of tmSessionID". Wes's response is 'too much implementation detail'. Agreed, but that is the house style of these memos and it is far too late to change that; rather, make the level of detail consistent where I believe that what we say for the CR is currently much more detailed than what we say for the CG. Hence my proposed additions. As I say, not wrong but could be clearer. Tom Petch ----- Original Message ----- From: "tom.petch" To: "Juergen Schoenwaelder" ; Cc: "Pasi Eronen" Sent: Wednesday, March 11, 2009 10:24 AM Subject: Re: [Isms] isms wg status and actions sshtm > sshtm Editorial (I think) > > 3.1.2 " requirements of securityLevel were met The SSH Transport Model" > lacks a period > > 3.1.4 (end) " and/or port numbers) will each result in individual SSH sessions." > suggest "different SSH sessions" since different is used earlier in the > sentence. > > 4.1.2 tmSessionID is also used to identify sessions in an SSH client as per 5.3 > 6) which 4.1.2 sort of omits stressing only its role in a CR > Suggest adding > > "tmSessionID is also used when the Secure Shell Transport Model is an SSH > client in order to identify the session over which a message is received." > > although that might be a bit too coy. I am thinking of answering the queries > from Jeff about the role of tmSessionID. > > 5.1.1) I read "session identifier" as code for tmSessionID. If so, I would > rather see that stated explicitly. 5.3 6) does explicitly mention tmSessionID in > this role. > > 5.1 2) C "(e.g. the value from step" > suggest "(i.e. the value from step" > > 5.1 3) C "(e.g. the value from step" > suggest "(i.e. the value from step" > > 5.2 3) B I think that as per Jeff's e-mail 3/9/9, this should start > " B. If tmSameSecurity is true and there is a session with a matching > sessionID, " > > 5.2.3) C ditto > " C. If tmSameSecurity is false and there is a session that matches the > tmTransportAddress " > > 5.2 3) D is interesting in that it caches the destTransport... parameters and > not the tmTransport.. ones. This is correct, in the sense that the dest.. > variants have come from application to Dispatcher to sshtm and need to go back > to the Dispatcher with any response. But it is interesting in that sshtm has > just used the tm.. variants in tmStateReference, which have come from Dispatcher > to MPP to Security Model to cache to sshtm, to open a session. Could they be > different? I do not think so with tsm as currently written, could be with a > different Security Model. So I think that the text is correct but we might get > asked if this is really right. > > 5.3 3) 1) "that user-name string that should be presented to the ssh server " > spurious second that > > 5.3 3) 2) "SSH principal" should be "SSH user" > > 5.3 generally hyphenates user-name while the earlier parts of the I-D do not, > and the MIB module throws in a few username. I would prefer consistency. > RFC4252 uses user name so I would suggest that. > > That apart, I have not looked at the MIB module. > > Tom Petch > > ps I read in the newspapers that my ISP might go bankrupt today, so if I > disappear from this list, that is why. Reading posts in the archives is easy, > posting becomes rather harder:-( > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: "Pasi Eronen" > Sent: Tuesday, March 10, 2009 1:53 PM > Subject: [Isms] isms wg status and actions > > > > I like to summarize how I see the status of the ISMS WG at this point > > in time by looking at our four chartered documents: > > > > 1) Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > > Network Management Protocol (SNMP) Transport Models > > > > > > A new version was posted by David Nelson on March 8th incorporating > > WG last call feedback. I asked people to check the changes until > > March 23rd. Dan Romascanu was so kind to forward this message to > > the RADIUSEXT WG and so far we received one editorial nit. If no > > technical issues are raised, then this document will be ready to be > > delivered to Pasi by the upcoming IETF meeting. > > > > 2) Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > > > > The latest version was posted on February 25th and I asked people > > on February 26th to check the changes and to report by March 6th. > > My reading of the mailing list is that no issues were raised and > > hence I conclude that this document is ready to be delivered to > > Pasi. I take the token to produce the necessary document writeups. > > > > 3) Transport Security Model for SNMP > > > > > > A new version was posted on March 9th incorporating changes > > discussed recently on the mailing list. The changes are very minor, > > essentially removing the rtr-nyc4@ example since the user@ notation > > is considered with rough consensus to be SSH specific. I do not > > think there are any other outstanding open issues with this > > document. So please check the changes and if I do not hear about > > technical problems by March 23rd, I consider this document ready to > > be delivered to Pasi by the upcoming IETF meeting. > > > > 4) Secure Shell Transport Model for SNMP > > > > > > Most of the recent email discussion (which I think we quite > > productive in moving things forward - thanks folks!) centered > > around this document. A new version was posted on March 9th > > incorporating changes that were discussed on the mailing list. In > > short, additional explanatory text was added to motivate the user@ > > notation and the elements of procedure have been rewritten in an > > attempt to simplify them. Please review this new version and let us > > know by March 23rd whether there are any technical showstoppers > > left. Please post issues as soon as possible so that we can > > continue working on resolutions as much as possible here on the > > list before the IETF meeting. > > > > Please let me know if you disagree with my assessment where we are > > with our chartered work item. I believe we are really very close to be > > done - so lets try to finish this and deliver by the next IETF. > > > > /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 j.schoenwaelder@jacobs-university.de Fri Mar 27 03:10:27 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253AD3A698D for ; Fri, 27 Mar 2009 03:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.176, 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 C+Q53VX+qCHv for ; Fri, 27 Mar 2009 03:10:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 30BD93A6825 for ; Fri, 27 Mar 2009 03:10:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1749FC0013 for ; Fri, 27 Mar 2009 11:11:18 +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 edERygRPcVoH; Fri, 27 Mar 2009 11:11:15 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E052FC000D; Fri, 27 Mar 2009 11:11:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7485BA41F77; Fri, 27 Mar 2009 11:10:59 +0100 (CET) Date: Fri, 27 Mar 2009 11:10:59 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090327101059.GA22795@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] draft ietf 74 meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 10:10:27 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am attaching the minutes of yesterday's meeting. Please check that everything has been recorded accurately. Special thanks to Juergen Quittek for taking notes and jabbering concurrently and Bert Wijnen for running the meeting. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-74-minutes.txt" ======================================================= Integrated Security Model for SNMP WG (isms) IETF #74, San Francisco THURSDAY, March 26, 2008, 1510-1610, Continental 1&2 Taken by Juergen Quittek ======================================================= WG Chair: Juergen Schoenwaelder Meeting Chair: Bert Wijnen WG URL: http://tools.ietf.org/wg/isms/ Jabber: xmpp:isms@jabber.ietf.org Agenda: 1) Agenda bashing, WG status ( 5 min) (Bert Wijnen) - Blue sheets - Minute and note takers - Jabber scribe 2) Delivery celebration | issue resolution (5 | 30 min) (David Harrington) - 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) Handling of ISMS related drafts (10 min) (Pasi Eronen, Dan Romascanu) 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 Summary: The WG deliverables passed WG last call and will be delivered to the responsible AD. The known editorial comments will be dealt with as part of the IETF last call process. WG members expressed interest to do followup work. This requires a rechartering discussion that will take place on the WG mailing list. During the rechartering discussion, it needs to become clear what the available resources are (editors, reviewers, (co-)chairs) and whether the active people can commit to realistic milestones. Meeting Notes: Bert Wijnen gave an overview of the ISMS WG documents. There were no requests to change the agenda. Wes reported for David Harrington. All four documents passed WG last call. - Transport Subsystem for SNMP [1] Only editorial changes have been applied since the last version. Jeff Hutzelman: I will review all drafts over the weekend and send my comments next week. Bert: These comments may then be taken as input for IETF last call. - Transport Security Model for SNMP [2] Editorial changes have been applied. The MIB copyright still needs an update. No issues raised in the session. Dave Harrington: This document is ready for AD review. - Secure Shell Transport Model for SNMP [3] This draft caused a lot of discussion in the last months, particularly concerning the transmission of a user name. Wes is not sure that a WG consensus has been reached. However, this document is considered to be ready for AD review. No concerns were sated in the session. - RADIUS Usage for SNMP SSH Security Model [4] This draft is considered highly stable. Editorial changes were only applied in order to achieve consistency between different ISMS drafts. It is considered ready for AD review. There are no technical issues left in any of the documents. The chair and the presenter thanked David Harrington for his exceptional work and dedication. Since no issue has been raised on any document, the WG chair considers all WG documents to have WG consensus and will pass them to AD review. Editorial issues will be dealt with together with any IETF last call comments. There is a known implementation at Jacobs University in Bremen. Also Wes Hardaker has a partial one. The WG chair and the responsible area director agree that the WG should become dormant after submitting all documents of the current charter to AD. Wes Hardaker suggests that the WG should continue being active because there are related drafts out there that have support from the community. Dave Harrington supports this view pointing out that the use of RADIUS attributes to manage access control had been postponed some time ago. There is an unfinished document on this issue. The WG should adopt this document and update it's charter. Jeff Hutzelman also suggests rechartering in order to complete the RADIUS work and to potentially pick up the DTLS work started by Wes Hardaker. Bert Wijnen asked for hands. 5 were raised in support for continuing the WG. No one was raised in support of closing the WG. Pasi Eronen: The WG need to re-carter anyway. The support from the community is weak. Reviewers are few. Jeff Hutzelman: I suggest we go ahead and prepare an updated charter and make the decision based on these discussions. Juergen Quittek: What bout setting deadline until when the WG should have created a new charter and received commitment from document authors? If this does not happen until soon we still may close the WG. Juergen Schoenwaelder (via Jabber): We should consider alternatives such as continuing the work in the OPSAWG. David Harrington: Going there with a new audience would be a mistake. In the ISMS WG a lot of knowledge has been accumulated and understanding between SNMP folks and SSH folks has developed very well. Wes Hardaker: Having this WG in the security area and not in the OAM area helped to get security experts in. They might not follow to OPSAWG. Jeff Hutzelman: There are reasons to continue. But we need editors and a chair that are willing to work. We cannot make a decision now without knowing this. Dan Romascanu: Moving the work to the OPSAWG depends on whether people from here are willing to also go to the OPSAWG. Wes Hardaker: Let's ask people here about their support for progressing and reviewing the documents. Bert Wijnen: Who supports Wes' DTLS document? 9 hands show up, no one opposed. Who would review the document? 6 hands showed up. In this room we have sufficient support for this document. Bert Wijnen: Who supports the document on simplified VACM? No hand showed up. David Harrington: I would help the authors with this document. Bert Wijnen: What about the remaining document on RADIUS usage to manage VACM ()? Who thinks we need to work on this document? 6 Hands showed up. Bert Wijnen: Who would help editing the document? No hands showed up. Bert Wijnen: Who would be willing to review? 5 hands showed up. David Harrington: I would be willing to co-chair. Bert Wijnen: We cannot make a decision here. If ISMS continues, we would need a new charter. Who would help? Jeff Hutzelman, Wes Hardaker and David Harrington offered support. David Harrington: I think this RADIUS support for access control is very important. A poll at NANOG showed up RADIUS integration as the most wanted feature. --lrZ03NoBR/3+SXJZ-- From j.schoenwaelder@jacobs-university.de Fri Mar 27 03:30:44 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D5F3A6A32 for ; Fri, 27 Mar 2009 03:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.174, 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 Z2rkK9Gtpvj8 for ; Fri, 27 Mar 2009 03:30:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 59C0C3A6933 for ; Fri, 27 Mar 2009 03:30:43 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DDB3C0015 for ; Fri, 27 Mar 2009 11:31:37 +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 Ybcqoi81d9Op; Fri, 27 Mar 2009 11:31:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D2DEC000D; Fri, 27 Mar 2009 11:31:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 31462A41FC8; Fri, 27 Mar 2009 11:31:20 +0100 (CET) Date: Fri, 27 Mar 2009 11:31:20 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090327103119.GB22795@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 10:30:44 -0000 Hi, since no more technical issues were raised yesterday, I will now go ahead and produce the document writeups and submit the chartered documents to our AD. This means the WG has completed its charter. During the meeting, people expressed interest to do followup work. This requires the WG to recharter and we need to have committed editors, document reviewers and (co-)chairs. To address the last point first, I am not able to continue as the chair of this WG. I might continue as co-chair but the decision will also depend on the outcome of the rechartering discussion and the commitment people can make to complete followup work in a reasonable time frame. >From the motion in the meeting room yesterday, the following work items are to be considered during the rechartering discussions: * DTLS transport for SNMP. Wes Hardaker has an active ID and there seem to be implementations underway. There was quite some support in the meeting room yesterday. * RADIUS support to control the View-based Access Control Model (VACM). There was a document some time ago that has expired. There was some support in the room to work on RADIUS support for VACM but it is unclear at the moment whether we have editors to work on such a document. * Simplified View-based Access Control Model (SVACM). The document authors could not be present at the meeting yesterday. The interest to pursue this work in the ISMS WG at the meeting was very low. Jeff Hutzelman, Wes Hardaker and David Harrington offered support to work on a new charter proposal. Please help them by expressing your support or concerns for the various suggested followup work items. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 27 06:08:35 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99BF3A6BBE; Fri, 27 Mar 2009 06:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.172, 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 jgIXHG2ESt1s; Fri, 27 Mar 2009 06:08:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 164FF3A68D1; Fri, 27 Mar 2009 06:08:34 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3383C0016; Fri, 27 Mar 2009 14:09:27 +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 E4V+EA2dMG9y; Fri, 27 Mar 2009 14:09: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 8DBE6C0012; Fri, 27 Mar 2009 14:09:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 36225A4257F; Fri, 27 Mar 2009 14:09:09 +0100 (CET) Date: Fri, 27 Mar 2009 14:09:08 +0100 From: Juergen Schoenwaelder To: "iesg-secretary@ietf.org" Message-ID: <20090327130908.GA24176@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Mailman-Approved-At: Fri, 27 Mar 2009 09:04:53 -0700 Cc: Pasi Eronen Subject: [Isms] Request to publish draft-ietf-isms-tmsm-16.txt as Proposed Standard RFC X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:08:35 -0000 Pasi, please take this document to the next step. The WG has consensus to request publication as a Proposed Standard RFC. Document Shepherd Write-Up for . Template used was dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Schoenwaelder is the document shepherd. I have reviewed the document several times including the latest version and I believe it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has gone through multiple WG last calls and has had over time significant review by subject matter experts. I do not have any concerns regarding the level of review for this document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not believe any extra special review (other than normal IETF Last Call) is needed. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG consensus and the WG wants the document to be published as a Proposed Standard. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document passes ID-nits 2.10.03. Some references have been updated since the ID was posted, which can be resolved easily during the IETF last call process. There are no formal reviews needed for this document. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative documents have been published. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document establishes a registry for SNMP transport domains. The IANA section defines the initial content, an allocation procedure, and it suggests a reasonable name. An Expert Review process is not defined. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not contain any formal notations that can be checked for correctness. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. The subsystem can contain Transport Models comparable to other subsystems in the RFC 3411 architecture. The Transport Subsystem can be used to expand the transports to include secure transports such as SSH or TLS. Working Group Summary The working group went over several revisions of this document while developing a Transport Model for SSH. The document did stabilize several revisions ago and has mainly been kept back to track clarifications and to ensure the new subsystem works with the SSH transport defined in a companion document. There has been strong WG consensus on revision 16 of this document. Document Quality There are two known implementations in progress of secure transport models. A concrete SSH subsystem has been worked out by the ISMS working group and a DTLS subsystem is in progress as an individual draft and it seems the Transport Subsystem defined in this document is capable to supports both secure transports. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 27 06:08:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A1C3A6C3A; Fri, 27 Mar 2009 06:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.169, 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 Wgbup7U2ZeYV; Fri, 27 Mar 2009 06:08:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 92CB23A68D1; Fri, 27 Mar 2009 06:08:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3328C0016; Fri, 27 Mar 2009 14:09:37 +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 ihwUE0-50uKC; Fri, 27 Mar 2009 14:09:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1393EC0012; Fri, 27 Mar 2009 14:09:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C41B6A4259D; Fri, 27 Mar 2009 14:09:20 +0100 (CET) Date: Fri, 27 Mar 2009 14:09:20 +0100 From: Juergen Schoenwaelder To: "iesg-secretary@ietf.org" Message-ID: <20090327130920.GB24176@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Mailman-Approved-At: Fri, 27 Mar 2009 09:04:53 -0700 Cc: Pasi Eronen Subject: [Isms] Request to publish draft-ietf-isms-transport-security-model-12.txt as Proposed Standard RFC X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:08:45 -0000 Pasi, please take this document to the next step. The WG has consensus to request publication as a Proposed Standard RFC. Document Shepherd Write-Up for . Template used was dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Schoenwaelder is the document shepherd. I have reviewed the document several times including the latest version and I believe it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has gone through multiple WG last calls and has had over time significant review by subject matter experts. I do not have any concerns regarding the level of review for this document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not believe any extra special review (other than normal IETF Last Call) is needed. The document, however, still needs a MIB doctor review. Since the document is edited by MIB doctors, I do not expect major problems here. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG consensus and the WG wants the document to be published as a Proposed Standard. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document passes ID-nits 2.10.03. The trust text in the MIB module needs to be updated, pending the general resolution of this issue. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative references have been published or are submitted together with this document to the IESG. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA section exists and seems to be complete. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The MIB module contained in the document compiles cleanly with smilint 0.4.5. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The document defines a Transport Security Model for the Simple Network Management Protocol (SNMP) for use with secure Transport Models in the Transport Subsystem. The document also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. Working Group Summary The document did stabilize several revisions ago and has mainly been updated recently to track clarifications. There has been WG consensus on revision 12 of this document and there were no controversies on the technical solution since the IETF meeting in Dublin. Document Quality There are two known implementations in progress of the Transport Security Model. A concrete SSH subsystem has been worked out by the ISMS working group and a DTLS subsystem is in progress as an individual draft and it seems the Transport Security Model defined in this document is capable to support both secure transports. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 27 06:08:54 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47393A6C3F; Fri, 27 Mar 2009 06:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VbpqiECJZxV; Fri, 27 Mar 2009 06:08:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6ED863A68D1; Fri, 27 Mar 2009 06:08:53 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B10A3C0012; Fri, 27 Mar 2009 14:09:47 +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 rZnvlg8YvbvX; Fri, 27 Mar 2009 14:09:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6CF2C0016; Fri, 27 Mar 2009 14:09:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A2DD6A425BB; Fri, 27 Mar 2009 14:09:30 +0100 (CET) Date: Fri, 27 Mar 2009 14:09:30 +0100 From: Juergen Schoenwaelder To: "iesg-secretary@ietf.org" Message-ID: <20090327130930.GC24176@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Mailman-Approved-At: Fri, 27 Mar 2009 09:04:53 -0700 Cc: Pasi Eronen Subject: [Isms] Request to publish draft-ietf-isms-secshell-15.txt as Proposed Standard RFC X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:08:54 -0000 Pasi, please take this document to the next step. The WG has consensus to request publication as a Proposed Standard RFC. Document Shepherd Write-Up for . Template used was dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Schoenwaelder is the document shepherd. I have reviewed the document several times including the latest version and I believe it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has gone through multiple WG last calls and has had over time significant review by subject matter experts. I do not have any concerns regarding the level of review for this document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not believe any extra special review (other than normal IETF Last Call) is needed. The document, however, still needs a MIB doctor review. Since the document is edited by MIB doctors, I do not expect major problems here. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG consensus and the WG wants the document to be published as a Proposed Standard. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document passes ID-nits 2.10.03. The trust text in the MIB module needs to be updated, pending the general resolution of this issue. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative references have been published or are submitted together with this document to the IESG. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA section exists and seems to be complete. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The MIB module contained in the document compiles cleanly with smilint 0.4.5. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The document defines a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell protocol (SSH). The document also defines a portion of the Management Information Base (MIB) for monitoring and managing the Secure Shell Transport Model for SNMP. Working Group Summary The document has mainly been updated recently to track clarifications and to improve the readability. There has been WG consensus on revision 15 of this document and there are no controversies on the technical solution. Document Quality There are two known implementations in progress of the Secure Shell Transport Model. There are no further vendor commitments at the moment to implement this specification. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 27 06:09:12 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B383A6BBE; Fri, 27 Mar 2009 06:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVW8imk3B8S6; Fri, 27 Mar 2009 06:09:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0FF733A68D1; Fri, 27 Mar 2009 06:09:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EF09C0025; Fri, 27 Mar 2009 14:10:05 +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 sHmjekwajaRg; Fri, 27 Mar 2009 14:10:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6608EC0012; Fri, 27 Mar 2009 14:10:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1D92EA425D9; Fri, 27 Mar 2009 14:09:48 +0100 (CET) Date: Fri, 27 Mar 2009 14:09:48 +0100 From: Juergen Schoenwaelder To: "iesg-secretary@ietf.org" Message-ID: <20090327130948.GD24176@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Mailman-Approved-At: Fri, 27 Mar 2009 09:04:53 -0700 Cc: Pasi Eronen Subject: [Isms] Request to publish draft-ietf-isms-radius-usage-05.txt as Proposed Standard RFC X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:09:12 -0000 Pasi, please take this document to the next step. The WG has consensus to request publication as a Proposed Standard RFC. Document Shepherd Write-Up for . Template used was dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Schoenwaelder is the document shepherd. I have reviewed the document several times including the latest version and I believe it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has gone through multiple WG last calls and has had over time significant review by subject matter experts. I do not have any concerns regarding the level of review for this document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not believe any extra special review (other than normal IETF Last Call) is needed. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG consensus and the WG wants the document to be published as a Proposed Standard. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document passes ID-nits 2.10.03. It contains one unused reference (RFC3415) and some have been updated since the ID was posted, which can be resolved easily during the IETF last call process. There are no formal reviews needed for this document. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative references have been published, are currently processed by the IESG, or are submitted together with this document to the IESG. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA section exists and seems to be complete. There are essentially just RFC editor instructions since this document depends on allocations of a document processed by the IESG. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not contain any formal notations that can be checked for correctness. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The document describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. Working Group Summary The document has been stable for several revisions. Most updates reflected changes in the companion document produced by the Radius Extensions working group and clarifications to adapt the SNMP terminology. There has been WG consensus on revision 05 of this document. Document Quality There are no known implementations in progress nor are there any known vendor commitments at the moment to implement this specification. Note that this document defines how Radius attributes are to be used in the context of secure SNMP Transport Models and bridges between two worlds. The WG last call has been posted to the Radius Extensions working group and Radius experts have been involved as document editors. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Fri Mar 27 09:30:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57043A6CA1 for ; Fri, 27 Mar 2009 09:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=0.435, 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 MA+114QS4sZ3 for ; Fri, 27 Mar 2009 09:30:36 -0700 (PDT) Received: from wes.hardakers.net (dhcp-15ae.meeting.ietf.org [130.129.21.174]) by core3.amsl.com (Postfix) with ESMTP id ACF7D3A6CA4 for ; Fri, 27 Mar 2009 09:30:34 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 5EB7F39A0F1 for ; Fri, 27 Mar 2009 09:31:29 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20090327101059.GA22795@elstar.local> Date: Fri, 27 Mar 2009 09:31:29 -0700 In-Reply-To: <20090327101059.GA22795@elstar.local> (Juergen Schoenwaelder's message of "Fri, 27 Mar 2009 11:10:59 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Isms] Ismsdraft ietf 74 meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 16:30:36 -0000 JS> - Secure Shell Transport Model for SNMP [3] JS> This draft caused a lot of discussion in the last months, JS> particularly concerning the transmission of a user name. Wes is not JS> sure that a WG consensus has been reached. However, this document is JS> considered to be ready for AD review. No concerns were sated in the JS> session. This is definitely *not* what I said. I said that I'm confident that WG consensus on the technical issues has happened and that the previous discussions were surrounding wording of that consensus only. I believe that the current text, as read by the working group members that have read it, is left to just minor editorial issues. JS> David Harrington: I think this RADIUS support for access control is JS> very important. A poll at NANOG showed up RADIUS integration as the JS> most wanted feature. David said "second most wanted feature" (ssh being the first). (Comment from me on that: the survey I did had two different elements to it, one was about authentication and one was about transport. Sometimes references to that survey tend to blur the survey into one result list, when it should really be two.) -- Wes Hardaker Sparta, Inc. From dnelson@elbrysnetworks.com Fri Mar 27 12:32:57 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176E53A67D9 for ; Fri, 27 Mar 2009 12:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.257 X-Spam-Level: X-Spam-Status: No, score=-0.257 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_40=-0.185] 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 omXvYdt7Dcbm for ; Fri, 27 Mar 2009 12:32:56 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 26D9F3A6899 for ; Fri, 27 Mar 2009 12:32:48 -0700 (PDT) Received: (qmail 7723 invoked from network); 27 Mar 2009 14:33:38 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 27 Mar 2009 14:33:38 -0400 From: "David B. Nelson" To: References: <20090327103119.GB22795@elstar.local> Date: Fri, 27 Mar 2009 14:33:30 -0400 Organization: Elbrys Networks, Inc. Message-ID: <238B21C88B154B0DA8F92428E957AAD2@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090327103119.GB22795@elstar.local> Thread-Index: AcmuxzeFNyE+l+hQQje5w9sq//an5QAQeBcg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 19:32:57 -0000 Juergen Schoenwaelder writes... > * RADIUS support to control the View-based Access Control Model > (VACM). There was a document some time ago that has expired. There > was some support in the room to work on RADIUS support for VACM but > it is unclear at the moment whether we have editors to work on such > a document. I've always felt that this wok was an important companion to the work we have already completed. I tried to find some time to submit an initial individual draft prior to IETF-74, but got side tracked by other responsibilities. My co-author on the RADIUS Usage draft had at one point expressed an interest to me in working on such a draft. I can't speak for his current level of interest or commitment, of course. If the WG wants to re-charter and include this work, I would be willing to contribute as a co-author. I would need substantial assistance with the SNMP aspects of this work. Additionally, since this work is no longer related to my daily employment activities, it would need to be on time-available basis. One of the challenges with this work item will be reconciling the notion in SNMP that authentication is a separate concern from authorization, and the notion in RADIUS that authorization must be bound (in one way or another) to an authentication. From kaushik@cisco.com Fri Mar 27 20:01:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3473A6AF2 for ; Fri, 27 Mar 2009 20:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU7YiCZ+LL6u for ; Fri, 27 Mar 2009 20:01:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 076C53A6AE0 for ; Fri, 27 Mar 2009 20:01:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,436,1233532800"; d="scan'208";a="162988061" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Mar 2009 03:02:05 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2S3253r019645; Fri, 27 Mar 2009 20:02:05 -0700 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 n2S325eq002989; Sat, 28 Mar 2009 03:02:05 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 20:02:05 -0700 Received: from 10.21.115.162 ([10.21.115.162]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Sat, 28 Mar 2009 03:02:04 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 27 Mar 2009 20:01:18 -0700 From: kaushik To: "David B. Nelson" , Message-ID: Thread-Topic: [Isms] wg rechartering Thread-Index: AcmuxzeFNyE+l+hQQje5w9sq//an5QAQeBcgABIXxWA= In-Reply-To: <238B21C88B154B0DA8F92428E957AAD2@xpsuperdvd2> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Mar 2009 03:02:05.0314 (UTC) FILETIME=[932C5E20:01C9AF51] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1832; t=1238209325; x=1239073325; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Isms]=20wg=20rechartering |Sender:=20; bh=WZGBDpAVRowD/uwKhbTdZhdiCdNQGri0JI8ZNBGfv5Q=; b=Da/zm5SPkkQGPpQGFm/5jQTEacqb2qOXBDtPjKbpAR+xi1CIhhCaSPNzw3 waROf4IxRQfMvkMFPJ3+S7ptqokDu15RnW4CL0SUeEs3kkXhRi6nPZYT+H0e ohv1XNdk4d; Authentication-Results: sj-dkim-3; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 03:01:11 -0000 I agree with David that the RADIUS work is not complete until we address authorization. I would be willing to co-author a document that tries to address this if the working group wants to include this work. Regards, kaushik On 3/27/09 11:33 AM, "David B. Nelson" wrote: > Juergen Schoenwaelder writes... > >> * RADIUS support to control the View-based Access Control Model >> (VACM). There was a document some time ago that has expired. There >> was some support in the room to work on RADIUS support for VACM but >> it is unclear at the moment whether we have editors to work on such >> a document. > > I've always felt that this wok was an important companion to the work we > have already completed. I tried to find some time to submit an initial > individual draft prior to IETF-74, but got side tracked by other > responsibilities. My co-author on the RADIUS Usage draft had at one point > expressed an interest to me in working on such a draft. I can't speak for > his current level of interest or commitment, of course. > > If the WG wants to re-charter and include this work, I would be willing to > contribute as a co-author. I would need substantial assistance with the > SNMP aspects of this work. Additionally, since this work is no longer > related to my daily employment activities, it would need to be on > time-available basis. > > One of the challenges with this work item will be reconciling the notion in > SNMP that authentication is a separate concern from authorization, and the > notion in RADIUS that authorization must be bound (in one way or another) to > an authentication. > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Fri Mar 27 23:43:39 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A8B3A69D6 for ; Fri, 27 Mar 2009 23:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_05=-1.11, 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 Vrfbch+T49PY for ; Fri, 27 Mar 2009 23:43:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DB3593A679C for ; Fri, 27 Mar 2009 23:43:37 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D753C001D; Sat, 28 Mar 2009 07:44: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 NhVwgMfvbm+I; Sat, 28 Mar 2009 07:44:30 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF17DC000F; Sat, 28 Mar 2009 07:44:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4C973A43D00; Sat, 28 Mar 2009 07:44:13 +0100 (CET) Date: Sat, 28 Mar 2009 07:44:13 +0100 From: Juergen Schoenwaelder To: kaushik Message-ID: <20090328064413.GB25935@elstar.local> Mail-Followup-To: kaushik , "David B. Nelson" , "isms@ietf.org" References: <238B21C88B154B0DA8F92428E957AAD2@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 06:43:39 -0000 On Sat, Mar 28, 2009 at 04:01:18AM +0100, kaushik wrote: > I agree with David that the RADIUS work is not complete until we > address authorization. I would be willing to co-author a document > that tries to address this if the working group wants to include > this work. Can you two produce an ID that describes the problem and potential solutions so we have something concrete to look at? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Sat Mar 28 06:36:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64CC63A6A06 for ; Sat, 28 Mar 2009 06:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=0.077, 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 kiSlvh6cguYG for ; Sat, 28 Mar 2009 06:36:40 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 66C8D3A67FB for ; Sat, 28 Mar 2009 06:36:40 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA03.westchester.pa.mail.comcast.net with comcast id Yb651b0030mv7h053ddcQx; Sat, 28 Mar 2009 13:37:36 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA11.westchester.pa.mail.comcast.net with comcast id Yddc1b0084H2mdz3XddcLx; Sat, 28 Mar 2009 13:37:36 +0000 From: "Dave Nelson" To: "'Juergen Schoenwaelder'" , "'kaushik'" References: <238B21C88B154B0DA8F92428E957AAD2@xpsuperdvd2> <20090328064413.GB25935@elstar.local> Date: Sat, 28 Mar 2009 09:37:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20090328064413.GB25935@elstar.local> Thread-Index: AcmvcKn+zLTYbZdgSdCtHmiG7DPOzQANmbog Cc: isms@ietf.org Subject: Re: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 13:36:41 -0000 > Can you two produce an ID that describes the problem and potential > solutions so we have something concrete to look at? I suppose. I'm not sure that the problem statement text would be so lengthy as to warrant an ID, though. The end user product requirement is "make SNMP access control work with a RADIUS AAA infrastructure". The SNMP architectural product requirement is "make an Access Control Model that gets at least some of its principal-specific access control information from a RADIUS server". When I say "some of", I'm thinking that the RADIUS server might perform the mapping of authenticated user identity, e.g. securityName, to an access control group. I don't think it's necessary for all of the access control information to be received dynamically from RADIUS. It seems reasonable to me that a [small] number of organizational roles are defined, and for each of these roles an access control policy is configured into something similar to one or more of the existing MIB tables of the VACM. That is to say, the policy rules for each role may be configured into local configuration data store, but that the mapping of identity to role occurs in a RADIUS Server. An alternate solution might create an Access Control Model that's effectively an "RPC wrapper" which sends all the incoming ASI parameters to the RADIUS Server and receives all the ASI return values from the RADIUS server. I'm thinking that doesn't scale well. I'm thinking that, as we did with the SSHTM, we need to create local session context so that the Access Control Model only needs to contact the RADIUS server upon the first request within a given session. I think there will be challenges, as there were with the secure transport models, because the existing ACM, VACM, is stateless, much like USM, is stateless. The other day, I alluded to the second challenge, that of maintaining the RADIUS architecture by tying the access control authorization request to a [previous] authentication request for the principal. How's that for a quick "problem statement"? From ietfdbh@comcast.net Sat Mar 28 09:29:48 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA093A6A99 for ; Sat, 28 Mar 2009 09:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 2z6JDX1QIgRf for ; Sat, 28 Mar 2009 09:29:48 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id E3D183A6A6A for ; Sat, 28 Mar 2009 09:29:47 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id YfSL1b00817dt5G55gWkJH; Sat, 28 Mar 2009 16:30:44 +0000 Received: from Harrington73653 ([67.99.198.4]) by OMTA13.westchester.pa.mail.comcast.net with comcast id YgWU1b00p06AstP3ZgWXRj; Sat, 28 Mar 2009 16:30:42 +0000 From: "David Harrington" To: "'Dave Nelson'" , "'Juergen Schoenwaelder'" , "'kaushik'" References: <238B21C88B154B0DA8F92428E957AAD2@xpsuperdvd2><20090328064413.GB25935@elstar.local> Date: Sat, 28 Mar 2009 09:30:28 -0700 Message-ID: <014a01c9afc2$8953da60$f4438182@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: thread-index: AcmvcKn+zLTYbZdgSdCtHmiG7DPOzQANmbogAAbY6TA= Cc: isms@ietf.org Subject: Re: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 16:29:48 -0000 Can you republish the expired draft as starting point? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Saturday, March 28, 2009 6:38 AM > To: 'Juergen Schoenwaelder'; 'kaushik' > Cc: isms@ietf.org > Subject: Re: [Isms] wg rechartering > > > Can you two produce an ID that describes the problem and potential > > solutions so we have something concrete to look at? > > I suppose. I'm not sure that the problem statement text > would be so lengthy > as to warrant an ID, though. > > The end user product requirement is "make SNMP access control > work with a > RADIUS AAA infrastructure". > > The SNMP architectural product requirement is "make an Access > Control Model > that gets at least some of its principal-specific access > control information > from a RADIUS server". > > When I say "some of", I'm thinking that the RADIUS server > might perform the > mapping of authenticated user identity, e.g. securityName, to > an access > control group. I don't think it's necessary for all of the > access control > information to be received dynamically from RADIUS. It seems > reasonable to > me that a [small] number of organizational roles are defined, > and for each > of these roles an access control policy is configured into > something similar > to one or more of the existing MIB tables of the VACM. That > is to say, the > policy rules for each role may be configured into local > configuration data > store, but that the mapping of identity to role occurs in a > RADIUS Server. > > An alternate solution might create an Access Control Model that's > effectively an "RPC wrapper" which sends all the incoming ASI > parameters to > the RADIUS Server and receives all the ASI return values from > the RADIUS > server. I'm thinking that doesn't scale well. I'm thinking > that, as we did > with the SSHTM, we need to create local session context so > that the Access > Control Model only needs to contact the RADIUS server upon > the first request > within a given session. > > I think there will be challenges, as there were with the > secure transport > models, because the existing ACM, VACM, is stateless, much > like USM, is > stateless. > > The other day, I alluded to the second challenge, that of > maintaining the > RADIUS architecture by tying the access control authorization > request to a > [previous] authentication request for the principal. > > How's that for a quick "problem statement"? > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From d.b.nelson@comcast.net Sat Mar 28 10:06:08 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AC63A6A03 for ; Sat, 28 Mar 2009 10:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.812, 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 GjeCROe84Jqs for ; Sat, 28 Mar 2009 10:06:07 -0700 (PDT) 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 2372D3A68F1 for ; Sat, 28 Mar 2009 10:06:07 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA01.westchester.pa.mail.comcast.net with comcast id Ycsw1b00R0mv7h051h73a6; Sat, 28 Mar 2009 17:07:03 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA11.westchester.pa.mail.comcast.net with comcast id Yh731b00H4H2mdz3Xh73Zm; Sat, 28 Mar 2009 17:07:03 +0000 From: "Dave Nelson" To: References: <238B21C88B154B0DA8F92428E957AAD2@xpsuperdvd2><20090328064413.GB25935@elstar.local> <014a01c9afc2$8953da60$f4438182@china.huawei.com> Date: Sat, 28 Mar 2009 13:07:04 -0400 Message-ID: <5DA498F9D6034CCFA70575D2FE53EA77@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <014a01c9afc2$8953da60$f4438182@china.huawei.com> Thread-Index: AcmvcKn+zLTYbZdgSdCtHmiG7DPOzQANmbogAAbY6TAAANyHoA== Subject: Re: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 17:06:08 -0000 David Harrington writes... > Can you republish the expired draft as starting point? Which expired draft is that? draft-narayan-isms-sshsm-radius-02.txt? I see that draft name referenced in the ISMS minutes. That's an earlier version of the RADIUS Usage draft that we've just submitted to the IESG. In taking a quick look at that draft, I don't see any *substantial* discussion of access control authorization. The only reference seems to be: 2.4. SNMP Access Control Authorization [radman] describes a RADIUS attribute that can be used for SNMP access control authorization, however, the details of how an SNMP Access Control Model, such as the View-based Access Control Model (VACM), might utilize RADIUS authorization are the topic of current research, and beyond the scope of this document. We may have had another early draft that delved deeper into access control authorization, but it's not that one. From j.schoenwaelder@jacobs-university.de Mon Mar 30 01:10:52 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453BD3A68F9 for ; Mon, 30 Mar 2009 01:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.178, 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 ebFJ6sQSw9TY for ; Mon, 30 Mar 2009 01:10:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1DD8C3A67D2 for ; Mon, 30 Mar 2009 01:10:50 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81017C0003; Mon, 30 Mar 2009 10:11:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Gz-I8IJumwFd; Mon, 30 Mar 2009 10:11:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E287C0002; Mon, 30 Mar 2009 10:11:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D2803A4505C; Mon, 30 Mar 2009 10:11:29 +0200 (CEST) Date: Mon, 30 Mar 2009 10:11:29 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090330081129.GA27613@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: <20090327101059.GA22795@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Ismsdraft ietf 74 meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 08:10:52 -0000 On Fri, Mar 27, 2009 at 05:31:29PM +0100, Wes Hardaker wrote: > > JS> - Secure Shell Transport Model for SNMP [3] > > JS> This draft caused a lot of discussion in the last months, > JS> particularly concerning the transmission of a user name. Wes is not > JS> sure that a WG consensus has been reached. However, this document is > JS> considered to be ready for AD review. No concerns were sated in the > JS> session. > > This is definitely *not* what I said. I said that I'm confident that WG > consensus on the technical issues has happened and that the previous > discussions were surrounding wording of that consensus only. I believe > that the current text, as read by the working group members that have > read it, is left to just minor editorial issues. Yes, I should have noticed that. I fixed this and uploaded revised minutes. > JS> David Harrington: I think this RADIUS support for access control is > JS> very important. A poll at NANOG showed up RADIUS integration as the > JS> most wanted feature. > > David said "second most wanted feature" (ssh being the first). Fixed 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 From dnelson@elbrysnetworks.com Mon Mar 30 12:03:56 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DBF3A6A75 for ; Mon, 30 Mar 2009 12:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=0.216, 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 3fhVH3TJp6BB for ; Mon, 30 Mar 2009 12:03:55 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id C63283A695F for ; Mon, 30 Mar 2009 12:03:54 -0700 (PDT) Received: (qmail 10547 invoked from network); 30 Mar 2009 14:04:51 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 30 Mar 2009 14:04:51 -0400 From: "David B. Nelson" To: References: <238B21C88B154B0DA8F92428E957AAD2@xpsuperdvd2><20090328064413.GB25935@elstar.local> Date: Mon, 30 Mar 2009 14:04:48 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcmvcKn+zLTYbZdgSdCtHmiG7DPOzQANmbogAG33dSA= In-Reply-To: Subject: Re: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:03:56 -0000 Is the following information (previously sent on March 28) sufficient for the purposes of the re-chartering discussion? > The end user product requirement is "make SNMP access control work > with a RADIUS AAA infrastructure". > > The SNMP architectural product requirement is "make an Access > Control Model that gets at least some of its principal-specific > access control information from a RADIUS server". > > When I say "some of", I'm thinking that the RADIUS server might > perform the mapping of authenticated user identity, e.g. securityName, > to an access control group. I don't think it's necessary for all > of the access control information to be received dynamically from > RADIUS. It seems reasonable to me that a [small] number of > organizational roles are defined, and for each of these roles > an access control policy is configured into something similar > to one or more of the existing MIB tables of the VACM. That > is to say, the policy rules for each role may be configured into > local configuration data store, but that the mapping of identity > to role occurs in a RADIUS Server. > > An alternate solution might create an Access Control Model that's > effectively an "RPC wrapper" which sends all the incoming ASI > parameters to the RADIUS Server and receives all the ASI return > values from the RADIUS server. I'm thinking that doesn't scale > well. I'm thinking that, as we did with the SSHTM, we need to > create local session context so that the Access Control Model only > needs to contact the RADIUS server upon the first request within a > given session. > > I think there will be challenges, as there were with the secure > transport models, because the existing ACM, VACM, is stateless, > much like USM, is stateless. > > The other day, I alluded to the second challenge, that of maintaining > the RADIUS architecture by tying the access control authorization > request to a [previous] authentication request for the principal. If the WG chooses not to go dormant, and it's re-chartered to do more work, we will obviously need authors, editors, and reviewers. Kaushik and I have indicated our willingness to co-author a draft if the WG re-charters to include this work. We would also need proposed charter text to succinctly describe the scope of work, and that's what I think we need next. A draft would follow the re-chartering exercise. Right? From j.schoenwaelder@jacobs-university.de Mon Mar 30 13:39:58 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4223A6D7A for ; Mon, 30 Mar 2009 13:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.172, 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 gA0lbES8yQPP for ; Mon, 30 Mar 2009 13:39:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B8EAA3A6CBA for ; Mon, 30 Mar 2009 13:39:57 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A129DC0008; Mon, 30 Mar 2009 22:40:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id drLuDBbx8TzC; Mon, 30 Mar 2009 22:40:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01403C002A; Mon, 30 Mar 2009 22:40:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 415EAA46BCA; Mon, 30 Mar 2009 22:40:37 +0200 (CEST) Date: Mon, 30 Mar 2009 22:40:37 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20090330204037.GB13540@elstar.local> Mail-Followup-To: "David B. Nelson" , "isms@ietf.org" References: <238B21C88B154B0DA8F92428E957AAD2@xpsuperdvd2> <20090328064413.GB25935@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 20:39:58 -0000 On Mon, Mar 30, 2009 at 08:04:48PM +0200, David B. Nelson wrote: > If the WG chooses not to go dormant, and it's re-chartered to do > more work, we will obviously need authors, editors, and reviewers. > Kaushik and I have indicated our willingness to co-author a draft if > the WG re-charters to include this work. > > We would also need proposed charter text to succinctly describe the > scope of work, and that's what I think we need next. A draft would > follow the re-chartering exercise. Right? I like to understand what precisely the work is the WG wants to sign up for. It is quite normal these days to charter work in the IETF for which there is an initial ID that can be reviewed before a decision is taken to take on the work item and which serves as a suitable starting point. If there is nobody to produce such an initial ID, why should the IETF charter this work? It took us years to get SNMP over SSH worked out in a way that is consistent with RFC3411 and so I do want to understand the relevant architectural constraints for the proposed followup work so that it becomes clear what it takes to work with them. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dnelson@elbrysnetworks.com Mon Mar 30 15:17:13 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779F63A6B04 for ; Mon, 30 Mar 2009 15:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=1.118, 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 9L9wl3gOzynj for ; Mon, 30 Mar 2009 15:17:12 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 73BC53A6AD6 for ; Mon, 30 Mar 2009 15:17:12 -0700 (PDT) Received: (qmail 15281 invoked from network); 30 Mar 2009 17:18:09 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 30 Mar 2009 17:18:09 -0400 From: "David B. Nelson" To: References: <238B21C88B154B0DA8F92428E957AAD2@xpsuperdvd2> <20090328064413.GB25935@elstar.local> <20090330204037.GB13540@elstar.local> Date: Mon, 30 Mar 2009 17:18:06 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acmxd9PVq1jFnU6KRwOHHqfThWkUUgAA5wTA In-Reply-To: <20090330204037.GB13540@elstar.local> Subject: Re: [Isms] wg rechartering X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 22:17:13 -0000 Juergen Schoenwaelder writes... > If there is nobody to produce such an initial ID, why > should the IETF charter this work? Conversely, if there is no WG chartered to do the work, why should anyone write an ID? :-) However, I do see your point. > It took us years to get SNMP over SSH worked out in a way > that is consistent with RFC3411 and so I do want to understand > the relevant architectural constraints for the proposed followup > work so that it becomes clear what it takes to work with them. Yes. I think it would make sense to flesh out those details and constraints prior to making a decision to take on the work -- or spending much time writing formal IDs. Of course, it may be that the incremental effort to wrap such a write-up in ID format is small. On the other hand, I'm not one who believes that the only way to discuss such issues is to write an ID and then solicit review. There's a long-standing tradition in the IETF of informally hashing out such issues on the appropriate mailing list. If we can't get a discussion of the issues started here, then I'd suggest that *both* the ID and the charter discussion are moot points. :-)