From isms-bounces@ietf.org Tue Sep 2 08:10:02 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE34D3A68CE; Tue, 2 Sep 2008 08:10:01 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B873A6AD0 for ; Tue, 2 Sep 2008 08:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=0.734, 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 ESBdzGs5ZbHR for ; Tue, 2 Sep 2008 08:09:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 558363A6AC7 for ; Tue, 2 Sep 2008 08:09:58 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24419C0008; Tue, 2 Sep 2008 17:09:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8J3YNJZFwk6L; Tue, 2 Sep 2008 17:09:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 724D5C0006; Tue, 2 Sep 2008 17:09:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 993036B8998; Tue, 2 Sep 2008 17:09:24 +0200 (CEST) Date: Tue, 2 Sep 2008 17:09:24 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20080902150924.GA7094@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , David Harrington , 'Wes Hardaker' , 'ISMS WG' References: <200808272301.m7RN12ZQ018151@toasties.srv.cs.cmu.edu> <036401c90925$7b5a5f90$0600a8c0@china.huawei.com> <03b301c90952$c61c6e10$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: 'ISMS WG' Subject: Re: [Isms] mapping here, mapping there, mapping everywhere X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Thu, Aug 28, 2008 at 07:05:36PM -0400, Jeffrey Hutzelman wrote: > I suspect the best thing to do is to assume that the architecture has a > 32-character limit for security names, keep that same limit in TSM, and > arrange for SSHTM to never emit names longer than that. I tend to agree here (speaking as technical contributor). > I think it is probably OK to say that... > > - by default, the tmSecurityName produced by sshtm consists of the string > "ssh:" followed by the SSH username > - if the tmSecurityName would exceed 32 characters in length, then sshtm > MUST instead generate some error/drop the request/whatever > > The thing we perhaps leave unstated is that it is permissible to provide an > implementation-specific means to configure a non-default mapping, in which > sshtm produces a tmSecurityName consisting of the string "ssh:" followed by > something other than the SSH username. As far as I understand the prefix proposal, I can select that prefixes are not stripped. This essentially means that the length of SSH usernames is limited to 32-strlen("ssh:"), no? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 2 08:40:59 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5318228C19E; Tue, 2 Sep 2008 08:40:59 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4BB3A6BA9 for ; Tue, 2 Sep 2008 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.142 X-Spam-Level: X-Spam-Status: No, score=-0.142 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Yj-WHJwmrNm1 for ; Tue, 2 Sep 2008 08:40:57 -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 461233A67BD for ; Tue, 2 Sep 2008 08:40:57 -0700 (PDT) X-Trace: 131095463/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.50.132 X-SBRS: None X-RemoteIP: 213.116.50.132 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAGH7vEjVdDKE/2dsb2JhbACDRziIDKd/A2oLcQ X-IronPort-AV: E=Sophos;i="4.32,317,1217804400"; d="scan'208";a="131095463" X-IP-Direction: IN Received: from 1cust132.tnt101.lnd4.gbr.da.uu.net (HELO allison) ([213.116.50.132]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2008 16:40:58 +0100 Message-ID: <01f201c90d08$f587ffc0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20080829134415.GA1084@elstar.local> Date: Tue, 2 Sep 2008 15:18:32 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Isms] d) was dublin isms meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Friday, August 29, 2008 3:44 PM Subject: [Isms] dublin isms meeting minutes > d) We can assume that SSH provides to us a suitable user name > that does not need a specific mapping. For SSH authentication > mechanisms such as GSSAPI, we can assume that SSH internally > maps into a user name that can be used outside of SSH. This puzzles me. To quote Jeff from the thread on 'mapping here ...', "I suspect the best thing to do is to assume that the architecture has a 32-character limit for security names, keep that same limit in TSM, and arrange for SSHTM to never emit names longer than that." which sounds suspiciously like a requirement for a mapping in SSHTM to me. In previous discussions on this, it was posited that user names might be (lengthy) OIDs or fingerprints and that DOCSIS had particular requirements here (not sure what they were). And, when this came up before, there were doubts about compatability of character set. I take it that " this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]." is essentially the same as "user name on the client host in ISO-10646 UTF-8 encoding [RFC3629] ? Tom Petch _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 2 09:18:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA32828C1C9; Tue, 2 Sep 2008 09:18:36 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6014B28C1BB for ; Tue, 2 Sep 2008 09:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.857, 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 NROzTU3wb0+W for ; Tue, 2 Sep 2008 09:18:29 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id BE9F428C1BF for ; Tue, 2 Sep 2008 09:18:29 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m82GISum016101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 12:18:29 -0400 (EDT) Date: Tue, 02 Sep 2008 12:17:52 -0400 From: Jeffrey Hutzelman To: "tom.petch" , Juergen Schoenwaelder , isms@ietf.org Message-ID: In-Reply-To: <200809021541.m82Ff8Sk028388@raisinbran.srv.cs.cmu.edu> References: <20080829134415.GA1084@elstar.local> <200809021541.m82Ff8Sk028388@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] d) was dublin isms 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Tuesday, September 02, 2008 03:18:32 PM +0200 "tom.petch" wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Sent: Friday, August 29, 2008 3:44 PM > Subject: [Isms] dublin isms meeting minutes > > > >> d) We can assume that SSH provides to us a suitable user name >> that does not need a specific mapping. For SSH authentication >> mechanisms such as GSSAPI, we can assume that SSH internally >> maps into a user name that can be used outside of SSH. > > This puzzles me. To quote Jeff from the thread on 'mapping here ...', > > "I suspect the best thing to do is to assume that the architecture has a > 32-character limit for security names, keep that same limit in TSM, and > arrange for SSHTM to never emit names longer than that." > > which sounds suspiciously like a requirement for a mapping in SSHTM to me. Not at all. It's a requirement for not emitting names longer than 32 characters. A mapping might be a way to achieve that, but so is a length limitation. In fact, starting in the very next sentence after that quote, I propose a length limit, with longer names being an error. I also suggest that it would be reasonable to allow implementations to provide a mapping mechanism. > In previous discussions on this, it was posited that user names might be > (lengthy) OIDs or fingerprints and that DOCSIS had particular > requirements here (not sure what they were). ssh usernames will never be OID's or fingerprints; they are strings. If another secure transport identifies clients with something more complex than a string, then the TM for that transport will need some form of transport-specific mapping from those objects to strings that can be used as SNMP security names. For an example, see Wes's DTLS TM. > And, when this came up before, there were doubts about compatability of > character set. > > I take it that > > " this > information is represented using the ISO/IEC > IS 10646-1 character set, encoded as an octet > string using the UTF-8 transformation format > described in [RFC2279]." > > is essentially the same as > > "user name on the client host in ISO-10646 UTF-8 encoding [RFC3629] > ? Yes. 3629 obsoletes 2279. See RFC3629 section 12 for a list of differences. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 2 09:26:57 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB913A69D2; Tue, 2 Sep 2008 09:26:57 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BC83A69D2 for ; Tue, 2 Sep 2008 09:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=0.409, 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 HKDabEhC-+mW for ; Tue, 2 Sep 2008 09:26:55 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 8B9393A6807 for ; Tue, 2 Sep 2008 09:26:55 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 9rBy1a00U0FhH24A4sSgTc; Tue, 02 Sep 2008 16:26:40 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id 9sSe1a00B4HwxpC8UsSf6F; Tue, 02 Sep 2008 16:26:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=f6Ij4AiQJQ8A:10 a=yb8-6tgRtNgA:10 a=48vgC7mUAAAA:8 a=X5Dxl52PGQllT56xe_oA:9 a=trpOCF1N1QfDE5_GsUYA:7 a=o4bf2Ux5zBazq6AtGeIGOJrIQBEA:4 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , "'Juergen Schoenwaelder'" , References: <20080829134415.GA1084@elstar.local> <01f201c90d08$f587ffc0$0601a8c0@allison> Date: Tue, 2 Sep 2008 12:26:38 -0400 Message-ID: <009601c90d18$ad983760$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckNElE4mI9am7HfQ4CqTf9alpBpxgAA1wdw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <01f201c90d08$f587ffc0$0601a8c0@allison> Subject: Re: [Isms] d) was dublin isms 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, The character set used for snmpAdminString and the character string used for SSH user name are consistent. RFC2279 cited for snmpAdminString and RFC3629 cited for SSH user name are different, but the changes between 2279 and 3629 were determined to have no effect on snmpAdminString or SSH user name. In addition, binary fields required by a specific athentication method are separate from the user name field in SSH user-auth messages. >From RFC4252: " All authentication requests MUST use the following message format. Only the first few fields are defined; the remaining fields depend on the authentication method. byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] string service name in US-ASCII string method name in US-ASCII .... method specific fields " dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Tuesday, September 02, 2008 9:19 AM > To: Juergen Schoenwaelder; isms@ietf.org > Subject: [Isms] d) was dublin isms meeting minutes > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Sent: Friday, August 29, 2008 3:44 PM > Subject: [Isms] dublin isms meeting minutes > > > > > d) We can assume that SSH provides to us a suitable user name > > that does not need a specific mapping. For SSH authentication > > mechanisms such as GSSAPI, we can assume that SSH internally > > maps into a user name that can be used outside of SSH. > > This puzzles me. To quote Jeff from the thread on 'mapping > here ...', > > "I suspect the best thing to do is to assume that the > architecture has a > 32-character limit for security names, keep that same limit > in TSM, and arrange > for SSHTM to never emit names longer than that." > > which sounds suspiciously like a requirement for a mapping in > SSHTM to me. > > In previous discussions on this, it was posited that user > names might be > (lengthy) OIDs or fingerprints and that DOCSIS had particular > requirements here > (not sure what they were). > > > And, when this came up before, there were doubts about > compatability of > character set. > > I take it that > > " this > information is represented using the ISO/IEC > IS 10646-1 character set, encoded as an octet > string using the UTF-8 transformation format > described in [RFC2279]." > > is essentially the same as > > "user name on the client host in ISO-10646 UTF-8 encoding [RFC3629] > ? > > > Tom Petch > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 2 09:39:05 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6114D3A684A; Tue, 2 Sep 2008 09:39:05 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C033A684A for ; Tue, 2 Sep 2008 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.675, 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 lRFb67HyxaSu for ; Tue, 2 Sep 2008 09:39:02 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id E90FB3A6832 for ; Tue, 2 Sep 2008 09:39:02 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 9nQy1a00117UAYkA9sf9B1; Tue, 02 Sep 2008 16:39:09 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id 9sf61a00Q4HwxpC8Zsf7G3; Tue, 02 Sep 2008 16:39:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=NhY9w3BhVRoA:10 a=SmJV75Gbn2EA:10 a=48vgC7mUAAAA:8 a=CJYDGtE1huOShmvgF38A:9 a=J6oL-vgPvtihBWf93zEA:7 a=0TVlwMGjOsYGk_uD6Q2yt43KIkQA:4 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" , "'Juergen Schoenwaelder'" , References: <20080829134415.GA1084@elstar.local><200809021541.m82Ff8Sk028388@raisinbran.srv.cs.cmu.edu> Date: Tue, 2 Sep 2008 12:39:06 -0400 Message-ID: <009701c90d1a$6bfcf320$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckNF5HmjpajIEG1SGqbPpidyNzKCQAASzXQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [Isms] d) was dublin isms 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, The (two-way) mapping should be predictable so operators can know what values to SET (or otherwise configure) into MIB modules such as the RFC3413 MIB modules, the VACM tables, the EVENT-MIB, the DISMAN-MIB, etc. for use with incoming or outgoing messages. Preferably, the predictability should be consistent across implementations. Therefore, allowing implementation-specific mapping mechanisms would seem to be problematic if the resultant mappings would be inconsistent across implementations. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Jeffrey Hutzelman > Sent: Tuesday, September 02, 2008 12:18 PM > To: tom.petch; Juergen Schoenwaelder; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] d) was dublin isms meeting minutes > > --On Tuesday, September 02, 2008 03:18:32 PM +0200 "tom.petch" > wrote: > > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > To: > > Sent: Friday, August 29, 2008 3:44 PM > > Subject: [Isms] dublin isms meeting minutes > > > > > > > >> d) We can assume that SSH provides to us a suitable user name > >> that does not need a specific mapping. For SSH authentication > >> mechanisms such as GSSAPI, we can assume that SSH internally > >> maps into a user name that can be used outside of SSH. > > > > This puzzles me. To quote Jeff from the thread on > 'mapping here ...', > > > > "I suspect the best thing to do is to assume that the > architecture has a > > 32-character limit for security names, keep that same limit > in TSM, and > > arrange for SSHTM to never emit names longer than that." > > > > which sounds suspiciously like a requirement for a mapping > in SSHTM to me. > > Not at all. It's a requirement for not emitting names longer than 32 > characters. A mapping might be a way to achieve that, but so > is a length > limitation. In fact, starting in the very next sentence > after that quote, > I propose a length limit, with longer names being an error. > I also suggest > that it would be reasonable to allow implementations to > provide a mapping > mechanism. > > > In previous discussions on this, it was posited that user > names might be > > (lengthy) OIDs or fingerprints and that DOCSIS had particular > > requirements here (not sure what they were). > > ssh usernames will never be OID's or fingerprints; they are > strings. If > another secure transport identifies clients with something > more complex > than a string, then the TM for that transport will need some form of > transport-specific mapping from those objects to strings that > can be used > as SNMP security names. For an example, see Wes's DTLS TM. > > > And, when this came up before, there were doubts about > compatability of > > character set. > > > > I take it that > > > > " this > > information is represented using the ISO/IEC > > IS 10646-1 character set, encoded as an octet > > string using the UTF-8 transformation format > > described in [RFC2279]." > > > > is essentially the same as > > > > "user name on the client host in ISO-10646 UTF-8 encoding [RFC3629] > > ? > > Yes. 3629 obsoletes 2279. See RFC3629 section 12 for a list of > differences. > > -- 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 isms-bounces@ietf.org Tue Sep 2 13:24:40 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650BF28C18A; Tue, 2 Sep 2008 13:24:40 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B70628C18A for ; Tue, 2 Sep 2008 13:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=0.393, 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 Mjn0RL3UA415 for ; Tue, 2 Sep 2008 13:24:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 22A0F28C181 for ; Tue, 2 Sep 2008 13:24:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CEEAC0051; Tue, 2 Sep 2008 22:24:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tISjjOXR+taU; Tue, 2 Sep 2008 22:24:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74F7AC0048; Tue, 2 Sep 2008 22:24:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BD4866B909E; Tue, 2 Sep 2008 22:24:34 +0200 (CEST) Date: Tue, 2 Sep 2008 22:24:34 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20080902202434.GA8042@elstar.local> Mail-Followup-To: "tom.petch" , isms@ietf.org References: <20080829134415.GA1084@elstar.local> <01f201c90d08$f587ffc0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <01f201c90d08$f587ffc0$0601a8c0@allison> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] d) was dublin isms meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Sep 02, 2008 at 03:18:32PM +0200, tom.petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Sent: Friday, August 29, 2008 3:44 PM > Subject: [Isms] dublin isms meeting minutes > > > > > d) We can assume that SSH provides to us a suitable user name > > that does not need a specific mapping. For SSH authentication > > mechanisms such as GSSAPI, we can assume that SSH internally > > maps into a user name that can be used outside of SSH. > > This puzzles me. To quote Jeff from the thread on 'mapping here ...', > > "I suspect the best thing to do is to assume that the architecture > has a 32-character limit for security names, keep that same limit in > TSM, and arrange for SSHTM to never emit names longer than that." The statement d) essentially says that we can assume that SSH gives us a user name to work with, independent of which user authentication mechanism is actually used by SSH. This is different form the question whether an SSH user name can be used directly without a mapping as an snmpSecurityName. >From the character set perspective, we seem to be fine with using SSH user names as snmpSecurityNames. The only problem seem to be length restrictions. SSH says it is a string, so the architectural limit is 2^32 bytes carrying UTF-8 characters. I am sure implementations will have much smaller limits. (I just played with my openssh and I got the impression that it actually silently truncated around some 100 ASCII characters but I have not verified this. But this limit is if it exists an implementation limit, not a protocol imposed limit.) We have (depending on whether the prefix needs to be accounted for or not) 32 or 28 bytes available, which is not really much. There is a growing tendency to use email addresses as identifiers for people (lets not discuss whether this makes sense) and then 28 bytes is pretty much nothing. The same is true for names written in a script that requires several bytes per character in UTF8. So it seems we have to provide an answer what happens if we run into length issues. And David wants all this to be predictable, that is not implementation and thus vendor specific. One potential solution could be an SSHTM mapping table which has the following properties: if (matching user name exists in the table) { use the associate securityname } else { if (length(user name) < N) { use the user name } else { drop the session and bump an appropriate counter } } /js (speaking as technical contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 2 13:56:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFE23A6918; Tue, 2 Sep 2008 13:56:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3D928C171 for ; Tue, 2 Sep 2008 13:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TW7wGnQWCBR for ; Tue, 2 Sep 2008 13:56:24 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 744A23A6948 for ; Tue, 2 Sep 2008 13:56:23 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so1240509eyd.31 for ; Tue, 02 Sep 2008 13:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dAIz2LU8jmcpQDC8vQ0TehxEUbbaFtIEdNGoQPgMolo=; b=FRRudsmKTngMNMn58cuJemhECG2P0m72VA8/Su2i3mckyFupurbVa3SEKeEA0dgjG0 GHYLsExeaxXk3BhjGJa4NRWfH/YPbdsXqbweULvAvhZO3/d7pmuP8i+n3R6Ci2bvSLi6 9SZddjHk7JW0Tr5TwWkn9ofIJg/HFlK+kjk3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=kciffee3OwEaFmY1NFAi5a00vrXgn4nJskPvEnaUBeLzjKNMTMqwo13F6XQ6A9ZNNs 1w7ODTqZwvilXFHeUbk6uzNSKRGHPbzyUx6HWNbAwtT32VG1FySxNqqA/9HoxWRzh/uq RZl05kCeWm0eYHI12tZnAcv3gRfjpDrKBg8ts= Received: by 10.210.89.4 with SMTP id m4mr8858567ebb.132.1220388988104; Tue, 02 Sep 2008 13:56:28 -0700 (PDT) Received: by 10.210.135.19 with HTTP; Tue, 2 Sep 2008 13:56:28 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 16:56:28 -0400 From: "Ira McDonald" To: j.schoenwaelder@jacobs-university.de, tom.petch , isms@ietf.org, "Ira McDonald" In-Reply-To: <20080902202434.GA8042@elstar.local> MIME-Version: 1.0 Content-Disposition: inline References: <20080829134415.GA1084@elstar.local> <01f201c90d08$f587ffc0$0601a8c0@allison> <20080902202434.GA8042@elstar.local> Subject: Re: [Isms] d) was dublin isms 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Further than RFC 3629 is needed, to prevent pesky security attacks, I think. RFC 5198 compliant normalization (NFC) of the security name presented by SSHTM should be REQUIRED. My two cents, - Ira On Tue, Sep 2, 2008 at 4:24 PM, Juergen Schoenwaelder wrote: > On Tue, Sep 02, 2008 at 03:18:32PM +0200, tom.petch wrote: >> ----- Original Message ----- >> From: "Juergen Schoenwaelder" >> To: >> Sent: Friday, August 29, 2008 3:44 PM >> Subject: [Isms] dublin isms meeting minutes >> >> >> >> > d) We can assume that SSH provides to us a suitable user name >> > that does not need a specific mapping. For SSH authentication >> > mechanisms such as GSSAPI, we can assume that SSH internally >> > maps into a user name that can be used outside of SSH. >> >> This puzzles me. To quote Jeff from the thread on 'mapping here ...', >> >> "I suspect the best thing to do is to assume that the architecture >> has a 32-character limit for security names, keep that same limit in >> TSM, and arrange for SSHTM to never emit names longer than that." > > The statement d) essentially says that we can assume that SSH gives us > a user name to work with, independent of which user authentication > mechanism is actually used by SSH. This is different form the question > whether an SSH user name can be used directly without a mapping as an > snmpSecurityName. > > From the character set perspective, we seem to be fine with using SSH > user names as snmpSecurityNames. The only problem seem to be length > restrictions. SSH says it is a string, so the architectural limit is > 2^32 bytes carrying UTF-8 characters. I am sure implementations will > have much smaller limits. (I just played with my openssh and I got the > impression that it actually silently truncated around some 100 ASCII > characters but I have not verified this. But this limit is if it > exists an implementation limit, not a protocol imposed limit.) > > We have (depending on whether the prefix needs to be accounted for or > not) 32 or 28 bytes available, which is not really much. There is a > growing tendency to use email addresses as identifiers for people > (lets not discuss whether this makes sense) and then 28 bytes is > pretty much nothing. The same is true for names written in a script > that requires several bytes per character in UTF8. So it seems we have > to provide an answer what happens if we run into length issues. And > David wants all this to be predictable, that is not implementation and > thus vendor specific. > > One potential solution could be an SSHTM mapping table which has the > following properties: > > if (matching user name exists in the table) { > use the associate securityname > } else { > if (length(user name) < N) { > use the user name > } else { > drop the session and bump an appropriate counter > } > } > > /js (speaking as technical contributor) > > -- > 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 > -- Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music/High North Inc email: blueroofmusic@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 2 16:42:16 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD5A3A6B20; Tue, 2 Sep 2008 16:42:15 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549E73A6ABD for ; Tue, 2 Sep 2008 16:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=0.883, 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 2T5mu5umftjg for ; Tue, 2 Sep 2008 16:42:13 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id EE5C33A69A1 for ; Tue, 2 Sep 2008 16:42:12 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 8EB1E980B1 for ; Tue, 2 Sep 2008 16:42:16 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 6D66239A274 for ; Tue, 2 Sep 2008 16:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=Y4JzqL+Rq3uS5dRqQpd0o03sVpA=; b=qO7vKcgrF2vjYTzt3vYcoB3WVZBu mw9Od9TA3Zaq1JTIPQ0lI8CHfz9pF2TYf4/IO0bztsl+cVpj2HDU5vmZr7VsBvuF Vw3Se8zqgoGJQY3oRikVU8l/f5SXcI9N2XjGOeZSjNMloBrXTqZt/tPRr7g+L6bI uaXfU5Y7Y9x6CAw= Received: by wes.hardakers.net (Postfix, from userid 274) id 3C05F2C3371; Tue, 2 Sep 2008 16:42:16 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Tue, 02 Sep 2008 16:42:15 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] review of changes to -13 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I just did a quick review of the -13 update and thanks for working so diligently on it! In particular, I love the new wording surrounding unique session identification (3.3.1) and how implementations may use particular combinations of parameters or utilize internal session pointers. I think this much more closely aligns with real-word code bases. Thanks for tackling that sticky issue. I have the following minor things to point out that are new nits as a result of the edits done. I didn't do a complete reread, but I did read all the changed sentences based on the diff (which, as you said would be the case, was rather extensive). I have one long issue, and a bunch of short ones. I'll send the long one in a different message. ==== Minor edits. * Section 3.2.1 *** "Any Transport Model SHOULD define one minimum-compliance security mechanism, but should also be able to support additional existing and new mechanisms." *** I think this is somewhat hard to understand why it's being stated without an example. EG, for SSH what is the minimum-compliance statement? There was a reference to certificates, which was at least an example, but it's been removed now. If you want to leave it generic, how about: ***** "Any Transport Model SHOULD define minimally required security features of the transport protocol. The Transport Model SHOULD also be able to support additional existing and new mechanisms." *** It A) uses "feature" instead of "mechanism" which I think makes it clearer that an author should discuss minimal setup of the protocol features and B) Creates two SHOULDs instead of one for each of the separate concepts * Section 3.2.1.2 *** I don't think the *s around '*before*' are really needed. *** "those security functions" is a reference to something nebulous. I'm not sure what it's referencing, so I'm guessing RFC3411 "functions"? How about: A secure transport performs any needed security functions on the message, before the message is decoded. Note that some of these or similar functions might then be repeated by the selected Security Model. * Section 3.2.1.3 *** Nit suggestion: use "stream" (eg "message stream") instead of "tunnel". (Tunnels are more frequently reserved for IP-level packet transporting where the higher layer doesn't even know of it's existence, which is not the case here). * Section 3.2.4 *** nit: "so cannot" => "so it cannot" *** "If two different Transport Model" => "If two different Transport Model*s*" ***** Same sentence: I'm not sure the first comma is needed. * Section 3.3 *** "session-like mechanism." => "session-like mechanism*s*." * Section 3.3.2, 3rd paragraph *** should => SHOULDs (like the previous paragraph)? * Section 5.2.3 *** "to security level" => "to security levels" * Section 6.3 *** "The contents of this cache are" => "The contents of this cache is" * Section 6.4 *** "the USM Security Model has no need of values" => "the USM Security Model has no need of *the* values" * Section 6.2, re "DISCUSS" *** FYI, I don't see any issues with the rewritten section that caused technical changes that should not have happened. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 2 16:55:29 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671023A6ABD; Tue, 2 Sep 2008 16:55:29 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760EA3A6A5A for ; Tue, 2 Sep 2008 16:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_20=-0.74, 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 8OHCH58icXxs for ; Tue, 2 Sep 2008 16:55:27 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 56D293A6A59 for ; Tue, 2 Sep 2008 16:55:27 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 5358B980B4 for ; Tue, 2 Sep 2008 16:55:34 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 20C1739A274 for ; Tue, 2 Sep 2008 16:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=MwAP3OKeuzqpkAN/yqwGV+6xPmo=; b=uy5NKLO0KDsUSPB8phAYu/q7d4Mu j/RsySFjFN2eXcuHlqWRrjK2CvCihg5S6wgVPPuGdn9PLRdcS7+0E4PUyYMXA7GV 1fPs7f9shTfS8BMj+LOtdBy8KphzBXfyNPhtdsQ46kB4RQPLTcMjei846/4a/z5u dmGMXZnxZt6KlFM= Received: by wes.hardakers.net (Postfix, from userid 274) id E10302C3371; Tue, 2 Sep 2008 16:55:33 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Tue, 02 Sep 2008 16:55:33 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Starting note: this discussion assumes 1:1 mappings and prefixes turned off (ie, the default). The text below is divided into two sections: a long winded reason for text I'm suggesting followed by additional related discussion information. * Section 5.2.2, "transport principal": The one major think I needs to be worded a bit better is section 5.2.2. In particular, it discusses the "transport principal". The problem is that what we're using as a transport principal is different depending on who is opening the connection. We keep coming back to this, so I'm trying again to point out the problem again but with a different set of ugly pictures. Let's take the case of a CG talking to a CR: SNMPv3 SSH SNMPv3 Protocol +-----------+ +---------------------------------------+ |CG | |CR | | +----+ | I'm foo | +----+ +-----+ +------+ | | | TM | |--------------->| | TM | --> | TSM | --> | VACM | | | +----+ | | +----+ +-----+ +------+ | | |<---------------| . | +-----------+ I'm x.y.com +------------------------------o--------+ O O +----------------+ |I'll let "foo" | |in today I guess| +----------------+ In the above, the transport principal (and via propagation the tmSecurityNanme and the securityName) is "foo" right? It's what the CR makes the decision by. The VACM is saying yea or nay based on it. It's what the CG presents to the CR in the form of a SSH user name (in this TM example). But, the CG MUST also verify that it's talking to the right CR as well and it does this by verifying that x.y.com is presenting the hostname it expects and that the public key it's presented matched the expected value and that the entity on the remote side can prove they have the private half of the key. The point is that there are two identities here: "foo", and "x.y.com". The current text is really only talking about "foo" but it doesn't clearly say that. And, to make matters more confusing... When the NG/NR process steps in then it gets more confusing: SNMPv3 SSH SNMPv3 Protocol +---------------------------------------+ +-----------+ |NG | I'm foo |CR | | +------+ +-----+ +----+ |--------------->| +----+ | | | VACM |--->| TSM |----->| TM | | | | TM | | | +------+ +-----+ +----+ |<---------------| +----+ | | . | I'm x.y.com | | +-------o-------------------------------+ +-----------+ O O +--------------------+ |I'll let "foo" | |see my notifications| |today ... | +--------------------+ (Note: The NG should still be configured to realize that x.y.com is presenting the expected and authenticated SSH credentials) This is where the problem lies. In this case, we're still using a SSH user name to identify *ourselves* and that is the outgoing securityName which is passed to tmSecurityNanme which becomes the principal identity. The problem is that the name being used by the VACM (and potentially other places) is always the one that the client side uses to authenticate itself. That needs to be made clear in the text, IMHO. I think the current text leads to confusion about this. This is the text in the last copy: transport principal: the transport-authenticated identity, on whose behalf the secure transport connection was (or should be) established. This value is transport-, mechanism- and implementation- specific, and is only used within a given transport model. The only reason I know the correct authenticated identity to use is because I've been thinking about it for 3 years along with the rest of the group. I don't think most of the rest of the first-time-readers will be able to pull out the proper value. This was an incredibly long winded way of proposing a replacement paragraph: transport principal: the authenticated identity that will be used to identify the authoritative principal for the SNMPv3 messages being sent. For asymmetric protocols which may be presenting different identity names for each side of the connection the transport principal will be the locally offered identity name for outgoing connections and the remotely authenticated name for incoming connections. This value is transport-, mechanism- and implementation- specific, and is only used within a given transport model. For SSH, the text assures that "foo" is always what is used within both the NG and the CR. For DTLS, it always uses the certificate that was used to open the connection. Aside reminder: (with my "bar@" secshell specification patch, it actually allows for the authentication to take place using "bar" according to the SSH server side even though we still refer to it locally as "foo" within a NG for doing authorization checks) -- end of proposal text -- -- start of extra discussion about reversing connections -- The security paranoid people should now be asking themselves 1) ok, but what happens if the NG is sent a command from a CG? What happens then? (ie, a call-home situation where the client is a NG/CR). The answer is that the NG application, if it was also a command responder (CR), would accept the request and believe it came from securityName "foo". *If* the VACM was configured to allow the "foo" user to access the CR then it would be allowed. Even though it hadn't presented the "foo" user name itself. This is probably worth noting in the Security Considerations as well. 2) ok, but what happens if the CR is sent a notification from a NG? What happens then? (ie, the client is a CG/NR). The answer, again, is that the securityName must be "foo" *and* if the application had registered itself as both a CG and a CR using the registerContextEngineID() ASI from section 4.1.5 of RFC3411 then it would accept the notification and do "something" with it. There is no (standardized) authorization process for notifications received, so it would simply be accepted. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 3 00:47:43 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDC43A6996; Wed, 3 Sep 2008 00:47:43 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A790E3A68ED for ; Wed, 3 Sep 2008 00:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.100, 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 9TFEocGui5Gt for ; Wed, 3 Sep 2008 00:47:40 -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 E9C403A6BE9 for ; Wed, 3 Sep 2008 00:46:58 -0700 (PDT) X-Trace: 77731615/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.139.76 X-SBRS: None X-RemoteIP: 62.188.139.76 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAFzdvUg+vItM/2dsb2JhbACDR4hGowQJhn0BAmkBC3E X-IronPort-AV: E=Sophos;i="4.32,320,1217804400"; d="scan'208";a="77731615" X-IP-Direction: IN Received: from 1cust76.tnt10.lnd4.gbr.da.uu.net (HELO allison) ([62.188.139.76]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Sep 2008 08:45:41 +0100 Message-ID: <004e01c90d8f$b9ad5a40$0601a8c0@allison> From: "tom.petch" To: "Ira McDonald" , , References: <20080829134415.GA1084@elstar.local> <01f201c90d08$f587ffc0$0601a8c0@allison> <20080902202434.GA8042@elstar.local> Date: Wed, 3 Sep 2008 08:38:28 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] d) was dublin isms meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "Ira McDonald" To: ; "tom.petch" ; ; "Ira McDonald" Sent: Tuesday, September 02, 2008 10:56 PM Subject: Re: [Isms] d) was dublin isms meeting minutes > > Further than RFC 3629 is needed, to prevent pesky > security attacks, I think. > > RFC 5198 compliant normalization (NFC) of the security > name presented by SSHTM should be REQUIRED. > Ira The two passages I quoted without a citation were from the SNMP and SSH standards respectively, on the limits on 'user names', and I wasn't sure if the RFC and the two different ISO references were 100% compatible (and if they are, why do we have two different documents? sigh:-( I think it difficult to fit RFC5198 into the pre-existing structure of SSH and SNMP. Tom Petch > My two cents, > - Ira > > On Tue, Sep 2, 2008 at 4:24 PM, Juergen Schoenwaelder > wrote: > > On Tue, Sep 02, 2008 at 03:18:32PM +0200, tom.petch wrote: > >> ----- Original Message ----- > >> From: "Juergen Schoenwaelder" > >> To: > >> Sent: Friday, August 29, 2008 3:44 PM > >> Subject: [Isms] dublin isms meeting minutes > >> > >> > >> > >> > d) We can assume that SSH provides to us a suitable user name > >> > that does not need a specific mapping. For SSH authentication > >> > mechanisms such as GSSAPI, we can assume that SSH internally > >> > maps into a user name that can be used outside of SSH. > >> > >> This puzzles me. To quote Jeff from the thread on 'mapping here ...', > >> > >> "I suspect the best thing to do is to assume that the architecture > >> has a 32-character limit for security names, keep that same limit in > >> TSM, and arrange for SSHTM to never emit names longer than that." > > > > The statement d) essentially says that we can assume that SSH gives us > > a user name to work with, independent of which user authentication > > mechanism is actually used by SSH. This is different form the question > > whether an SSH user name can be used directly without a mapping as an > > snmpSecurityName. > > > > From the character set perspective, we seem to be fine with using SSH > > user names as snmpSecurityNames. The only problem seem to be length > > restrictions. SSH says it is a string, so the architectural limit is > > 2^32 bytes carrying UTF-8 characters. I am sure implementations will > > have much smaller limits. (I just played with my openssh and I got the > > impression that it actually silently truncated around some 100 ASCII > > characters but I have not verified this. But this limit is if it > > exists an implementation limit, not a protocol imposed limit.) > > > > We have (depending on whether the prefix needs to be accounted for or > > not) 32 or 28 bytes available, which is not really much. There is a > > growing tendency to use email addresses as identifiers for people > > (lets not discuss whether this makes sense) and then 28 bytes is > > pretty much nothing. The same is true for names written in a script > > that requires several bytes per character in UTF8. So it seems we have > > to provide an answer what happens if we run into length issues. And > > David wants all this to be predictable, that is not implementation and > > thus vendor specific. > > > > One potential solution could be an SSHTM mapping table which has the > > following properties: > > > > if (matching user name exists in the table) { > > use the associate securityname > > } else { > > if (length(user name) < N) { > > use the user name > > } else { > > drop the session and bump an appropriate counter > > } > > } > > > > /js (speaking as technical contributor) > > > > -- > > 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 > > > > > > -- > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Blue Roof Music/High North Inc > email: blueroofmusic@gmail.com > winter: > 579 Park Place Saline, MI 48176 > 734-944-0094 > summer: > PO Box 221 Grand Marais, MI 49839 > 906-494-2434 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 3 02:43:50 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F8A3A6C80; Wed, 3 Sep 2008 02:43:49 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205123A6C94 for ; Wed, 3 Sep 2008 02:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=0.672, 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 aTgS87BlK+YT for ; Wed, 3 Sep 2008 02:43:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 23B903A6C7D for ; Wed, 3 Sep 2008 02:43:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B92EC0066; Wed, 3 Sep 2008 11:43:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PMXQBXGSA9Xz; Wed, 3 Sep 2008 11:43:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBB1BC008F; Wed, 3 Sep 2008 11:43:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 445576B9780; Wed, 3 Sep 2008 11:43:05 +0200 (CEST) Date: Wed, 3 Sep 2008 11:43:05 +0200 From: Juergen Schoenwaelder To: Ira McDonald Message-ID: <20080903094305.GA8704@elstar.local> Mail-Followup-To: Ira McDonald , "tom.petch" , isms@ietf.org References: <20080829134415.GA1084@elstar.local> <01f201c90d08$f587ffc0$0601a8c0@allison> <20080902202434.GA8042@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] d) was dublin isms meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Sep 02, 2008 at 04:56:28PM -0400, Ira McDonald wrote: > RFC 5198 compliant normalization (NFC) of the security > name presented by SSHTM should be REQUIRED. I think the SNMPv3 specifications never talk about normalization of SnmpAdminStrings. So the issue is of much larger scope and to tackle this, someone needs to write a separate document about UTF-8 string normalization in the whole SNMP framework. But this then is clearly not in the scope of ISMS. All ISMS could do is to require normalization for TSM and SSHTM but that would not really solve the general problem as long as all other configuration tables and in particular VACM are agnostic to string normalization. Perhaps someone should write a best practices like document that SnmpAdminString values really should be normalized (but that causes nasty length changes) or that SnmpAdminString values should be normalized before any comparisons are done. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 3 09:30:00 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9443A6C69; Wed, 3 Sep 2008 09:30:00 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B083A6CE6 for ; Wed, 3 Sep 2008 09:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 RanZTwUmwFF6 for ; Wed, 3 Sep 2008 09:29:57 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 43CCD3A6CCF for ; Wed, 3 Sep 2008 09:29:57 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so1462985eyd.31 for ; Wed, 03 Sep 2008 09:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=wfrF2RbHhTllHkZp3CBjfXU7Hte0SMNJZbOGgJdPqn8=; b=lnHoRx0XfGKC4seU1UloUx8+gbVlWUmq2w9W07jafgRfESNdp5kZXQ6GMHD9e4xCXg rCkDbjzWQudUePwhrbVetU5wZhhNBT7i7npp8XClEPBmLcFANTo2+4R0uaG1kArIFViw rkkvnxVZmMB7F+q/Ta+hSqL+rhdmeMokiMzEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pQ8LskInxlnY7ptAs8GVGmydKWq3UIy6FjRuXiFAI+UbpyoOFo/dWqpotUjdouUfTF R0oreusc6OPorElRf11nTkCLYcQMUyqLxNkqZT2bng0YrVMtRyfQrdCqm369Myw6SlMx KRBktxdWQ/LGkiLeqDJaxvdC7pxp2fP2yjAks= Received: by 10.210.41.1 with SMTP id o1mr10312166ebo.143.1220459340800; Wed, 03 Sep 2008 09:29:00 -0700 (PDT) Received: by 10.210.135.19 with HTTP; Wed, 3 Sep 2008 09:29:00 -0700 (PDT) Message-ID: Date: Wed, 3 Sep 2008 12:29:00 -0400 From: "Ira McDonald" To: j.schoenwaelder@jacobs-university.de, "Ira McDonald" , tom.petch , isms@ietf.org In-Reply-To: <20080903094305.GA8704@elstar.local> MIME-Version: 1.0 Content-Disposition: inline References: <20080829134415.GA1084@elstar.local> <01f201c90d08$f587ffc0$0601a8c0@allison> <20080902202434.GA8042@elstar.local> <20080903094305.GA8704@elstar.local> Subject: Re: [Isms] d) was dublin isms 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Oops - a can of worms here. Let me clarify, I hope. The vast majority of uses of SnmpAdminString in IETF and private MIBs are for simple description objects that need to be internationalized - no normalization is needed - string comparisons would be a design flaw. But the Unicode Consortium and others have written extensively about why *names* (of principals, protocols, etc.) MUST be normalized to avoid some rather serious security problems. SSHTM is already constraining SSH usage, so security name normalization seems appropriate. Separately (as Juergen has pointed out), the whole use of UTF-8 in VACM and other MIBs probably needs to be addressed - but changing SNMPv3 was deemed out-of-scope for ISMS - why? - the undeployability of SNMPv3 is the whole point of the ISMS WG, I thought? Cheers, - Ira On Wed, Sep 3, 2008 at 5:43 AM, Juergen Schoenwaelder wrote: > On Tue, Sep 02, 2008 at 04:56:28PM -0400, Ira McDonald wrote: > >> RFC 5198 compliant normalization (NFC) of the security >> name presented by SSHTM should be REQUIRED. > > I think the SNMPv3 specifications never talk about normalization of > SnmpAdminStrings. So the issue is of much larger scope and to tackle > this, someone needs to write a separate document about UTF-8 string > normalization in the whole SNMP framework. But this then is clearly > not in the scope of ISMS. > > All ISMS could do is to require normalization for TSM and SSHTM but > that would not really solve the general problem as long as all other > configuration tables and in particular VACM are agnostic to string > normalization. > > Perhaps someone should write a best practices like document that > SnmpAdminString values really should be normalized (but that causes > nasty length changes) or that SnmpAdminString values should be > normalized before any comparisons are done. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music/High North Inc email: blueroofmusic@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 3 10:26:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3783A6B7E; Wed, 3 Sep 2008 10:26:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16BE3A6B6C for ; Wed, 3 Sep 2008 10:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, 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 FmESj0csk5cn for ; Wed, 3 Sep 2008 10:26:23 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id B00B03A6B5E for ; Wed, 3 Sep 2008 10:26:21 -0700 (PDT) Received: from 70-5-45-223.area3.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m83HPc1l010015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 13:25:39 -0400 (EDT) Date: Wed, 03 Sep 2008 13:25:38 -0400 From: Jeffrey Hutzelman To: Ira McDonald , j.schoenwaelder@jacobs-university.de, "tom.petch" , isms@ietf.org Message-ID: In-Reply-To: <200809031630.m83GU9Uc017429@raisinbran.srv.cs.cmu.edu> References: <20080829134415.GA1084@elstar.local> <01f201c90d08$f587ffc0$0601a8c0@allison> <20080902202434.GA8042@elstar.local> <20080903094305.GA8704@elstar.local> <200809031630.m83GU9Uc017429@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] d) was dublin isms 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, September 03, 2008 12:29:00 PM -0400 Ira McDonald wrote: > Hi, > > Oops - a can of worms here. > > Let me clarify, I hope. > > The vast majority of uses of SnmpAdminString in IETF and private MIBs > are for simple description objects that need to be internationalized - no > normalization is needed - string comparisons would be a design flaw. > > But the Unicode Consortium and others have written extensively about > why *names* (of principals, protocols, etc.) MUST be normalized to avoid > some rather serious security problems. Some of us, at least, understand the issues here quite well and don't need them reviewed for us. However, fixing this problem in either SSH or SNMP is simply not in scope for us. > SSHTM is already constraining SSH usage, so security name normalization > seems appropriate. Firstly, no, we're not really "constraining" SSH usage. We're using SSH, but we place no constraints on SSH's choice of algorithms or authentication methods, and we make no changes to the SSH protocol. Making changes to the SSH protocol would be out of the scope of both our charter and our expertise (while there are some SSH people here, myself included, the WG as a whole does not have the right expertise for that). Now, you could decide to normalize usernames you get out of SSH, but that doesn't really solve the problem, because it doesn't address the issue of comparisons done inside SSH that affect whether you get in at all. > Separately (as Juergen has pointed out), the whole use of UTF-8 in VACM > and other MIBs probably needs to be addressed - but changing SNMPv3 > was deemed out-of-scope for ISMS - why? - the undeployability of SNMPv3 > is the whole point of the ISMS WG, I thought? The point of ISMS is to provide the tools needed to integrate SNMP with operators' existing security infrastructures. It is specifically intended not to change either SNMP or SSH, but simply to make them work together. The goal is to describe how to plug the existing pieces together, not to change those pieces to suit our liking. While, again, we could normalize SNMP security names in the security model before passing them along, that wouldn't solve the problem. It doesn't solve the problem because it doesn't fix USM, or other security models, and it also doesn't fix the other ways in which VACM gets security names, such as via the MIBs that define the access controls it enforces. In fact, this means that not only would normalization in the SM not fix the problem, it could actually make it worse. Suppose you have a SM that normalizes every name it sees to NFC, but some operators clients (including those used to configure VACM) run on a platform which has input methods that tend to produce decomposed forms? Now the SM's normalization practically guarantees that the security names it passes to vacm won't match anything in its database. The answer to this is normalization-insensitive comparison, which is to say, normalizing values to be compared at the last possible moment before the comparison. But that has to be done in VACM, and changing the behavior of VACM is very much out of scope for this WG, as it should be. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 3 14:47:32 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDAC3A6AE0; Wed, 3 Sep 2008 14:47:32 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36BC3A6AB6 for ; Wed, 3 Sep 2008 14:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[AWL=0.639, 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 TeXr+jeTjzkN for ; Wed, 3 Sep 2008 14:47:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4F9F83A6AD5 for ; Wed, 3 Sep 2008 14:46:26 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D89A7C00C4; Wed, 3 Sep 2008 23:45:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0yI8pjJphW3v; Wed, 3 Sep 2008 23:45:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EC0DC00C0; Wed, 3 Sep 2008 23:45:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C2D086BA3CB; Wed, 3 Sep 2008 23:45:47 +0200 (CEST) Date: Wed, 3 Sep 2008 23:45:47 +0200 From: Juergen Schoenwaelder To: Ira McDonald Message-ID: <20080903214547.GA10282@elstar.local> Mail-Followup-To: Ira McDonald , "tom.petch" , isms@ietf.org References: <20080829134415.GA1084@elstar.local> <01f201c90d08$f587ffc0$0601a8c0@allison> <20080902202434.GA8042@elstar.local> <20080903094305.GA8704@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] d) was dublin isms meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, Sep 03, 2008 at 12:29:00PM -0400, Ira McDonald wrote: > The vast majority of uses of SnmpAdminString in IETF and private MIBs > are for simple description objects that need to be internationalized - no > normalization is needed - string comparisons would be a design flaw. SnmpAdminStrings are used as identifiers in several places in SNMPv3 MIB modules and these strings are compared during the processing in the elements of procedure. Are you saying SNMPv3's usage of UTF-8 is flawed? Perhaps it is, but to be fair it must be noted that SNMPv3 was done about 10 years ago and UTF-8 normalization was probably not that well understood at that point in time. If SNMPv3's usage of UTF-8 is flawed, someone should write up a document explaining the issue and proposing ways to fix things and then it can be discussed if and where in the IETF this work should be done. Looking at the current ISMS charter, I don't think ISMS is the place to do this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 3 17:32:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D454C3A6CDC; Wed, 3 Sep 2008 17:32:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1406E3A6CDC for ; Wed, 3 Sep 2008 17:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 n7GKKZuLWjme for ; Wed, 3 Sep 2008 17:32:46 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.178]) by core3.amsl.com (Postfix) with ESMTP id B9C103A6C96 for ; Wed, 3 Sep 2008 17:32:45 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c28so1568919ika.5 for ; Wed, 03 Sep 2008 17:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HLqioi697XjKNrEoL8C8Agv0fkraLx1hRJNvnJtZWpQ=; b=J+D9xx2gnXN1js9iCNemv7yktNdlrhPNWTq/SikPCpDvrVS7l0R2gzcWsqmrHEDlth kp8igQcCGwBL/ZmGk80MlWnbat7DXHXJS4a4lYT+2d8o9NkqkQ78HEQ2rbbwd3EYUdsL 3QY5qVWIcYOQi37EdSyAXUqDT9LZUdoDuI4/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=R8vIhtSa5lG3dQPIz6i5H9KJ5K74XEiwoP2YxVnK2KaGoeibxR+iTnIwgtxmpsq29a szQzIENfmb/CtXYv6mtoyksPTTTHPqn7T3XfoZ9HOUMLXKTguC+UZxBxVAruy2Z8ZtCG G0H80rHKb2YIdCMa90ggRcAVXdFYroN8x9qj8= Received: by 10.210.16.1 with SMTP id 1mr25020ebp.156.1220488371195; Wed, 03 Sep 2008 17:32:51 -0700 (PDT) Received: by 10.210.135.19 with HTTP; Wed, 3 Sep 2008 17:32:51 -0700 (PDT) Message-ID: Date: Wed, 3 Sep 2008 20:32:51 -0400 From: "Ira McDonald" To: j.schoenwaelder@jacobs-university.de, "Ira McDonald" , tom.petch , isms@ietf.org In-Reply-To: <20080903214547.GA10282@elstar.local> MIME-Version: 1.0 Content-Disposition: inline References: <20080829134415.GA1084@elstar.local> <01f201c90d08$f587ffc0$0601a8c0@allison> <20080902202434.GA8042@elstar.local> <20080903094305.GA8704@elstar.local> <20080903214547.GA10282@elstar.local> Subject: Re: [Isms] d) was dublin isms 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Right - as Jeff and Juergen have said - the topic's out-of-scope. Perhaps in Security Considerations a one-liner referencing RFC 5198, UTR36 (Security Considerations), and UTR39 (Security Mechanisms)? Juergen - Yes - the use of UTF-8 for identifiers without normalization (in SNMPv3 or anywhere else) is flawed - that's not new news. Cheers, - Ira On Wed, Sep 3, 2008 at 5:45 PM, Juergen Schoenwaelder wrote: > On Wed, Sep 03, 2008 at 12:29:00PM -0400, Ira McDonald wrote: > >> The vast majority of uses of SnmpAdminString in IETF and private MIBs >> are for simple description objects that need to be internationalized - no >> normalization is needed - string comparisons would be a design flaw. > > SnmpAdminStrings are used as identifiers in several places in SNMPv3 > MIB modules and these strings are compared during the processing in > the elements of procedure. Are you saying SNMPv3's usage of UTF-8 is > flawed? Perhaps it is, but to be fair it must be noted that SNMPv3 was > done about 10 years ago and UTF-8 normalization was probably not that > well understood at that point in time. > > If SNMPv3's usage of UTF-8 is flawed, someone should write up a > document explaining the issue and proposing ways to fix things and > then it can be discussed if and where in the IETF this work should be > done. Looking at the current ISMS charter, I don't think ISMS is the > place to do this. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music/High North Inc email: blueroofmusic@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 4 03:59:00 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78883A68DA; Thu, 4 Sep 2008 03:59:00 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34E03A67D0 for ; Thu, 4 Sep 2008 03:58:58 -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 LyoiSSqJkRIO for ; Thu, 4 Sep 2008 03:58:58 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id E89723A68DA for ; Thu, 4 Sep 2008 03:58:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qXtSUYuck9Z4nTFhcVoXCP2atItMmHaFskUwJlzvRfFujvpGPnmFO5r7U52Y8Aa5; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.39] (helo=elwamui-little.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KbCYJ-0000Nf-CU for isms@ietf.org; Thu, 04 Sep 2008 06:59:03 -0400 Received: from 216.7.144.53 by webmail.earthlink.net with HTTP; Thu, 4 Sep 2008 06:59:03 -0400 Message-ID: <9269048.1220525943467.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Date: Thu, 4 Sep 2008 06:59:03 -0400 (GMT-04:00) From: Randy Presuhn To: isms@ietf.org Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4ec4d99226ed6f1db7de80ecada46f36c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.39 Subject: Re: [Isms] d) was dublin isms meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randy Presuhn List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - >From: Juergen Schoenwaelder >Sent: Sep 3, 2008 5:45 PM >To: Ira McDonald >Cc: isms@ietf.org >Subject: Re: [Isms] d) was dublin isms meeting minutes > >On Wed, Sep 03, 2008 at 12:29:00PM -0400, Ira McDonald wrote: > >> The vast majority of uses of SnmpAdminString in IETF and private MIBs >> are for simple description objects that need to be internationalized - no >> normalization is needed - string comparisons would be a design flaw. > >SnmpAdminStrings are used as identifiers in several places in SNMPv3 >MIB modules and these strings are compared during the processing in >the elements of procedure. Are you saying SNMPv3's usage of UTF-8 is >flawed? Perhaps it is, but to be fair it must be noted that SNMPv3 was >done about 10 years ago and UTF-8 normalization was probably not that >well understood at that point in time. The issue was raised when SnmpAdminString was being defined, and has popped up a couple of times since, but the WG hasn't wanted to deal with it. (It's not *that* hard, but life would be simpler if we had just dealt with it from the beginning.) >If SNMPv3's usage of UTF-8 is flawed, someone should write up a >document explaining the issue and proposing ways to fix things and >then it can be discussed if and where in the IETF this work should be >done. Looking at the current ISMS charter, I don't think ISMS is the >place to do this. Given the way SNMP works in general (get-next, etc.) I think the best we can do at this point is to advise that the party generating a string in the first place (e.g., a manager creating an index value or setting a string) is responsible for normalizing (we should say which normalization form to use). If the agent is to enforce normalization constraints, that should be included in the DESCRIPTION of the relevant object-types. To set an object to a potentially non-normalized value, and to have the agent automagically normalizing it, is asking for trouble, especially with INDEXes Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Sep 4 08:11:17 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B8B3A685A; Thu, 4 Sep 2008 08:11:17 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68253A685A for ; Thu, 4 Sep 2008 08:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 2yL9fBF3i4Rt for ; Thu, 4 Sep 2008 08:11:16 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 084283A6826 for ; Thu, 4 Sep 2008 08:11:15 -0700 (PDT) Received: from 70-5-45-223.area3.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m84FB9eD000433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 11:11:10 -0400 (EDT) Date: Thu, 04 Sep 2008 11:11:09 -0400 From: Jeffrey Hutzelman To: Randy Presuhn , isms@ietf.org Message-ID: <1B959C98962EE5ADFF4433A5@atlantis.pc.cs.cmu.edu> In-Reply-To: <200809041059.m84AxtEU019739@grapenut.srv.cs.cmu.edu> References: <200809041059.m84AxtEU019739@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] d) was dublin isms 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, September 04, 2008 06:59:03 AM -0400 Randy Presuhn wrote: > To set an object to a potentially non-normalized value, and to > have the agent automagically normalizing it, is asking for > trouble, especially with INDEXes Actually, it turns out you can do something reasonable here, if you're careful. The key is that when a field was not originally defined to be normalized, you more or less have to store what you were given. However, you can do lookups which are normalization-insensitive but prefer an exact match. My understanding is that this approach has worked fairly well for Sun in ZFS. In any case, this is a topic for another working group, or perhaps an individual submission. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 12 00:51:59 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC903A6BFC; Fri, 12 Sep 2008 00:51:59 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC893A6BFF for ; Fri, 12 Sep 2008 00:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.575, 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 YSIs1kV8P7-k for ; Fri, 12 Sep 2008 00:51: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 08C5F3A6BFC for ; Fri, 12 Sep 2008 00:51:57 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8225CC00B9; Fri, 12 Sep 2008 09:51:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Vlm6NvtAnAuk; Fri, 12 Sep 2008 09:51:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 385BDC00B7; Fri, 12 Sep 2008 09:51:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2FB8A6C6C00; Fri, 12 Sep 2008 09:51:24 +0200 (CEST) Date: Fri, 12 Sep 2008 09:51:24 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080912075124.GA3563@elstar.local> Mail-Followup-To: isms@ietf.org, Pasi Eronen MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Pasi Eronen Subject: [Isms] meeting in minneapolis X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, by Monday, WG chais have to file meeting slot requests for the upcoming IETF in Minneapolis (16-21 November 2008). I plan to ask for a one hour meeting slot but I hope that we do not really need it and that we can cancel it before the meeting. Here is the relevant quote from the minutes of the Dublin meeting: It was agreed to have revised core ISMS documents in September resolving the open issues and going to WG last call. Any issues coming up during WG last call should be resolved in October so that the revised documents can go to the IESG in November. So the goal is to get the documents ready for WG last call this months and since there has been lots of good review work done recently, I hope that the issues popping up during WG last call can be resolved on this list before the next 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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 12 10:49:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639993A6B15; Fri, 12 Sep 2008 10:49:56 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEC73A6B15 for ; Fri, 12 Sep 2008 10:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_05=-1.11, 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 HrksKBH041Et for ; Fri, 12 Sep 2008 10:49:53 -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 80D493A6846 for ; Fri, 12 Sep 2008 10:49:53 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id A28E9399B2F for ; Fri, 12 Sep 2008 10:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=fTr9SuPJOC6qbdt3qeheOkc0QRQ=; b=A4doU6dUiOkWn6FLWuoYhKao3dl0 yoHy0tyyx/NqP45CO68aq5zoWi3CbaMTNh87dcdb3urba9mmpgGKh1lJ3cZ4a+yp 383Qj5Z9QPoRs91nPruQpmKWxgy4iu44axZdQre1FV+IVHD0lovr9Rko0f/2z06m XqYjzqxwpjzHm5o= Received: by wes.hardakers.net (Postfix, from userid 274) id 83C4F399B30; Fri, 12 Sep 2008 10:49:58 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Fri, 12 Sep 2008 10:49:58 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] Question on TSM outgoing step 1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org To quote the TSM-08 document: 1) If there is a securityStateReference, then this is a response message. Extract transportDomain, transportAddress, securityName, securityLevel, securityModel, and tmStateReference from the securityStateReference cache. Set the tmRequestedSecurityLevel to the value of the extracted securityLevel. The cachedSecurityData for this message can now be discarded. Set the tmSameSecurity parameter in the tmStateReference cache to true. I'm not sure why the cache is supposed to contain half of that information that the second sentence is saying to extract. Most of it is passed in via the ASI parameters, and almost none of it is actually used in the following text. (the most confusing one would be the reference to the "securityModel" which should always be "self" and am not sure how it would ever be anything other than "TSM"). The third sentence (tmRequestedSecurityLevel = securityLevel) also doesn't make sense since no where in the incoming procedures did we cache the securityLevel in the first place. And regardless, wouldn't it make more sense to set the tmRequestedSecurityLevel to what was requested from the ASI parameters rather than a cached value? Suggestions: 1) Change the second sentence to just: "Extract tmStateReference from the securityStateReference cache." or even: "Extract tmStateReference and any other implementation-dependent parameters from the securityStateReference cache." 2) Change the forth sentence to: "Set the tmRequestedSecurityLevel to the securityLevel value. (unless I'm missing something on this particular point... I think the MP already assigns the security level to be the same, so all we have to do is pass what's passed on to us to the TM) -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 12 11:09:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B753A6C51; Fri, 12 Sep 2008 11:09:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB2928C17A for ; Fri, 12 Sep 2008 11:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=-0.705, 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 Zk+uCc-s8Mzc for ; Fri, 12 Sep 2008 11:09:23 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id C01143A6AA8 for ; Fri, 12 Sep 2008 11:09:02 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA02.westchester.pa.mail.comcast.net with comcast id Dndk1a00D1HzFnQ52u97qJ; Fri, 12 Sep 2008 18:09:07 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.westchester.pa.mail.comcast.net with comcast id Du991a00N4HwxpC3au9AgM; Fri, 12 Sep 2008 18:09:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=8Nu3p6cNFfEA:10 a=bGyuRmjDrgIA:10 a=48vgC7mUAAAA:8 a=KnAt9sai1_a1AygO-oYA:9 a=O4FJ-2hWpo8QZNwEG3QA:7 a=j7ebKQxPdGFwsydsJ5vUyshNOBgA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" , "'ISMS WG'" References: Date: Fri, 12 Sep 2008 14:09:09 -0400 Message-ID: <02f501c91502$a79b71f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AckU//2PI1Z9nCShSZW+1im/11nqPQAAXwqA Subject: Re: [Isms] Question on TSM outgoing step 1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, The cache should contain all the security properties related to the incoming request, and make sure the same security properties are applied to the response. My documentation might be missing osmehting, but that is the intent. Extracting securityModel is a left-over from when we were discussing if the TM can specify which securtityModel should be used, and is also left over from cut-and-paste from SNMPv3, where extracting the securityModel is important because the SNMPv3 message carries that in the securityParameters. We should probably add a check to ensure that, on the response, we are using the same security model as was used with the request. If the request specified authpriv, then the response should also be sent authpriv. That is why we do not take the securityLevel form the ASI, but from the securityCache. IIRC, the MPM doesn't look in the securityCache. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Friday, September 12, 2008 1:50 PM > To: ISMS WG > Subject: [Isms] Question on TSM outgoing step 1 > > > To quote the TSM-08 document: > > 1) If there is a securityStateReference, then this is a response > message. Extract transportDomain, transportAddress, securityName, > securityLevel, securityModel, and tmStateReference from the > securityStateReference cache. Set the tmRequestedSecurityLevel to > the value of the extracted securityLevel. The > cachedSecurityData for > this message can now be discarded. Set the tmSameSecurity > parameter > in the tmStateReference cache to true. > > I'm not sure why the cache is supposed to contain half of that > information that the second sentence is saying to extract. Most of it > is passed in via the ASI parameters, and almost none of it is actually > used in the following text. (the most confusing one would be the > reference to the "securityModel" which should always be "self" and am > not sure how it would ever be anything other than "TSM"). > > The third sentence (tmRequestedSecurityLevel = securityLevel) also > doesn't make sense since no where in the incoming procedures did we > cache the securityLevel in the first place. And regardless, > wouldn't it > make more sense to set the tmRequestedSecurityLevel to what was > requested from the ASI parameters rather than a cached value? > > > > Suggestions: > > 1) Change the second sentence to just: > > "Extract tmStateReference from the securityStateReference cache." > > or even: > > "Extract tmStateReference and any other implementation-dependent > parameters from the securityStateReference cache." > > 2) Change the forth sentence to: > > "Set the tmRequestedSecurityLevel to the securityLevel value. > > (unless I'm missing something on this particular point... I think > the MP already assigns the security level to be the same, so all we > have to do is pass what's passed on to us to the TM) > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 12 13:10:52 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB273A68CB; Fri, 12 Sep 2008 13:10:52 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDDB3A6841 for ; Fri, 12 Sep 2008 13:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=0.767, 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 iHzbQ3ogewpA for ; Fri, 12 Sep 2008 13:10:50 -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 7EC383A67E3 for ; Fri, 12 Sep 2008 13:10:50 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 713CF399B2F; Fri, 12 Sep 2008 13:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=9ignVKv4E9QgZN+cs6eKx4gTI+0=; b=q6A/ DBfFdtp7/ouagrXjc89H3OecyTJ52TWrZP5bIc+zs477f+9Ko872qgL3Pl90qMgB oERTpIBtuN5/JEZoxRndAE3qxDVi1cchRRzYXh+GAn6gFbml/cyfK97LeOkWXNHr AlpZIpsY2kbHIC/xyp4JCTkdvYSc5a8GwkcRwjk= Received: by wes.hardakers.net (Postfix, from userid 274) id E7564399B30; Fri, 12 Sep 2008 13:10:57 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <02f501c91502$a79b71f0$0600a8c0@china.huawei.com> Date: Fri, 12 Sep 2008 13:10:57 -0700 In-Reply-To: <02f501c91502$a79b71f0$0600a8c0@china.huawei.com> (David Harrington's message of "Fri, 12 Sep 2008 14:09:09 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: 'ISMS WG' Subject: Re: [Isms] Question on TSM outgoing step 1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Fri, 12 Sep 2008 14:09:09 -0400, "David Harrington" said: DH> The cache should contain all the security properties related to the DH> incoming request, and make sure the same security properties are DH> applied to the response. If you want to do that then text saying that needs to be added, as well as text put into the incoming EOP describing to cache that data. DH> We should probably add a check to ensure that, on the response, we are DH> using the same security model as was used with the request. That sounds more like a job for the MP than the security model itself... DH> If the request specified authpriv, then the response should also be DH> sent authpriv. That is why we do not take the securityLevel form the DH> ASI, but from the securityCache. IIRC, the MPM doesn't look in the DH> securityCache. I agree if you want the security model to be authoritative, that's the right place to do it. (from an implementation point of view, though, the security model can't be authoritative since other modules can trump it's decisions anyway since they get to handle the packet after the SM gets done with it). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 12 13:19:21 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D9B3A6BB1; Fri, 12 Sep 2008 13:19:21 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4542F3A6C53 for ; Fri, 12 Sep 2008 13:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 EirCZip0UajG for ; Fri, 12 Sep 2008 13:19:19 -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 834853A6BA7 for ; Fri, 12 Sep 2008 13:19:19 -0700 (PDT) Received: from atlantis.pc.cs.cmu.edu (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m8CKJHoW000886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 16:19:20 -0400 (EDT) Date: Fri, 12 Sep 2008 16:19:16 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , David Harrington Message-ID: In-Reply-To: <200809122011.m8CKB2et006294@raisinbran.srv.cs.cmu.edu> References: <02f501c91502$a79b71f0$0600a8c0@china.huawei.com> <200809122011.m8CKB2et006294@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: 'ISMS WG' , jhutz@cmu.edu Subject: Re: [Isms] Question on TSM outgoing step 1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Friday, September 12, 2008 01:10:57 PM -0700 Wes Hardaker wrote: >>>>>> On Fri, 12 Sep 2008 14:09:09 -0400, "David Harrington" >>>>>> said: > > DH> We should probably add a check to ensure that, on the response, we are > DH> using the same security model as was used with the request. > > That sounds more like a job for the MP than the security model itself... Maybe David means s/security model/secure transport/ ? -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 12 13:41:23 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020103A6B49; Fri, 12 Sep 2008 13:41:23 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883693A6B49 for ; Fri, 12 Sep 2008 13:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[AWL=0.725, 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 Lfu4Lkgrln93 for ; Fri, 12 Sep 2008 13:41:21 -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 AF43E3A6957 for ; Fri, 12 Sep 2008 13:41:21 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id B2C1B399B2F; Fri, 12 Sep 2008 13:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=N3+hvBWRIF45NDZ73ohYdQEgwLA=; b=RzMc 7bEgWawPyDTVxYn55wWM19xbrz620Rv9Dl95UJ/D2T3boc4gRjhs6s3wmsR0OJdx q41FrkN/oGI/p/4UYdCZ6v/3akGIB9FSGD0R96yvW8Yuh18zWwd82BQHgHYjN57k AJ8S/IMsaBIRka52bhvlPMbr3th41EdPYvEiOQA= Received: by wes.hardakers.net (Postfix, from userid 274) id 89DB4399B30; Fri, 12 Sep 2008 13:41:29 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <02f501c91502$a79b71f0$0600a8c0@china.huawei.com> <200809122011.m8CKB2et006294@raisinbran.srv.cs.cmu.edu> Date: Fri, 12 Sep 2008 13:41:29 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Fri, 12 Sep 2008 16:19:16 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: 'ISMS WG' Subject: Re: [Isms] Question on TSM outgoing step 1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Fri, 12 Sep 2008 16:19:16 -0400, Jeffrey Hutzelman said: DH> We should probably add a check to ensure that, on the response, we are DH> using the same security model as was used with the request. >> >> That sounds more like a job for the MP than the security model itself... JH> Maybe David means s/security model/secure transport/ ? The current text currently says the security model, when processing an out going message, should extract the securityModel parameter from it's cache. That's what we were talking about. (The Domain is also listed as to be extracted from the cache; so both the transport and the model are listed as to be extracted from the cache currently). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 12 14:28:08 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC163A6957; Fri, 12 Sep 2008 14:28:08 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD733A6957 for ; Fri, 12 Sep 2008 14:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFZsFc6o1ioR for ; Fri, 12 Sep 2008 14:28:05 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 93AA43A6881 for ; Fri, 12 Sep 2008 14:28:05 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with comcast id Dsmc1a01C0mv7h05AxUD4W; Fri, 12 Sep 2008 21:28:13 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id DxUC1a00U4HwxpC3XxUC5i; Fri, 12 Sep 2008 21:28:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=8Nu3p6cNFfEA:10 a=bGyuRmjDrgIA:10 a=qhR144aw9x-wUIr0u7YA:9 a=pJicxfo3inqKy__qz-shoY0wON8A:4 a=86L1PGDMzkIA:10 a=si9q_4b84H0A:10 a=6-x43y6uxGMA:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Wes Hardaker'" References: <02f501c91502$a79b71f0$0600a8c0@china.huawei.com> <200809122011.m8CKB2et006294@raisinbran.srv.cs.cmu.edu> Date: Fri, 12 Sep 2008 17:28:12 -0400 Message-ID: <030e01c9151e$76366bd0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AckVFNhYREkeMQ/5Sm2ZqiwVpSJP3gACSr4A Cc: 'ISMS WG' Subject: Re: [Isms] Question on TSM outgoing step 1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org No, I meant security model. The security model that gets asked to send the response should check that the securityCache has a matching securityModel, and if not send an error back to the MPM (and application) that sent the response to a different securityModel than the request came through. It is an error for an application to send a response via a different securityModel. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, September 12, 2008 4:19 PM > To: Wes Hardaker; David Harrington > Cc: 'ISMS WG'; jhutz@cmu.edu > Subject: Re: [Isms] Question on TSM outgoing step 1 > > --On Friday, September 12, 2008 01:10:57 PM -0700 Wes Hardaker > wrote: > > >>>>>> On Fri, 12 Sep 2008 14:09:09 -0400, "David Harrington" > >>>>>> said: > > > > DH> We should probably add a check to ensure that, on the > response, we are > > DH> using the same security model as was used with the request. > > > > That sounds more like a job for the MP than the security > model itself... > > Maybe David means s/security model/secure transport/ ? > > -- Jeff > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Sep 12 21:55:00 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DB33A6BB5; Fri, 12 Sep 2008 21:55:00 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB693A6BB5 for ; Fri, 12 Sep 2008 21:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.176 X-Spam-Level: X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[AWL=0.564, 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 skUBfXDnlJmU for ; Fri, 12 Sep 2008 21:54:57 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 84AFC3A6862 for ; Fri, 12 Sep 2008 21:54:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qA0Q5x6VAAdo/RKtz5e7J6eEory+uxFm1Qgc1JpePcGNH1mEQL+ZsAkC+WC/lmfl; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.144.221] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KeNA1-0004Ea-Ec for isms@ietf.org; Sat, 13 Sep 2008 00:55:05 -0400 Message-ID: <000e01c9155d$30014060$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200809041059.m84AxtEU019739@grapenut.srv.cs.cmu.edu> <1B959C98962EE5ADFF4433A5@atlantis.pc.cs.cmu.edu> Date: Fri, 12 Sep 2008 21:57:11 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4182328d245bb47b266a728bda1bb8426350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.144.221 Subject: Re: [Isms] d) was dublin isms 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "Jeffrey Hutzelman" > To: "Randy Presuhn" ; > Cc: > Sent: Thursday, September 04, 2008 8:11 AM > Subject: Re: [Isms] d) was dublin isms meeting minutes > > --On Thursday, September 04, 2008 06:59:03 AM -0400 Randy Presuhn > wrote: > > > To set an object to a potentially non-normalized value, and to > > have the agent automagically normalizing it, is asking for > > trouble, especially with INDEXes > > Actually, it turns out you can do something reasonable here, if you're > careful. The key is that when a field was not originally defined to be > normalized, you more or less have to store what you were given. However, > you can do lookups which are normalization-insensitive but prefer an exact > match. My understanding is that this approach has worked fairly well for > Sun in ZFS. ... It might work there, but for SNMP get-next, get-bulk, and VACM to work correctly, messing with the value of INDEXes is a complete no-no. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 16 08:20:44 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C6628C0E5; Tue, 16 Sep 2008 08:20:44 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E608E3A6B1A for ; Tue, 16 Sep 2008 08:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.512, 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 PRVzzpJO6+uJ for ; Tue, 16 Sep 2008 08:20:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 322B63A6B64 for ; Tue, 16 Sep 2008 08:20:42 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A212BC0050; Tue, 16 Sep 2008 17:20:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VzOEe8mzYTtC; Tue, 16 Sep 2008 17:20:46 +0200 (CEST) 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 1BBCEC004A; Tue, 16 Sep 2008 17:20:45 +0200 (CEST) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id C7F896CF07A; Tue, 16 Sep 2008 17:20:44 +0200 (CEST) Date: Tue, 16 Sep 2008 17:20:44 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Wes Hardaker , ISMS WG References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ISMS WG Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I have not seen any reaction to this message by Wes. Does this mean everybody agrees to the proposed changes? /js PS: I personally very much like the figures - I think they are helpful. Does it make sense to include them in the SSH TM specifications? On Tue, Sep 02, 2008 at 04:55:33PM -0700, Wes Hardaker wrote: > > Starting note: this discussion assumes 1:1 mappings and prefixes > turned off (ie, the default). The text below is divided into two > sections: a long winded reason for text I'm suggesting followed by > additional related discussion information. > > > * Section 5.2.2, "transport principal": > > The one major think I needs to be worded a bit better is section > 5.2.2. In particular, it discusses the "transport principal". The > problem is that what we're using as a transport principal is different > depending on who is opening the connection. We keep coming back to > this, so I'm trying again to point out the problem again but with a > different set of ugly pictures. > > Let's take the case of a CG talking to a CR: > > SNMPv3 SSH SNMPv3 > Protocol > +-----------+ +---------------------------------------+ > |CG | |CR | > | +----+ | I'm foo | +----+ +-----+ +------+ | > | | TM | |--------------->| | TM | --> | TSM | --> | VACM | | > | +----+ | | +----+ +-----+ +------+ | > | |<---------------| . | > +-----------+ I'm x.y.com +------------------------------o--------+ > O > O > +----------------+ > |I'll let "foo" | > |in today I guess| > +----------------+ > > In the above, the transport principal (and via propagation the > tmSecurityNanme and the securityName) is "foo" right? It's what the > CR makes the decision by. The VACM is saying yea or nay based on it. > It's what the CG presents to the CR in the form of a SSH user name (in > this TM example). But, the CG MUST also verify that it's talking to > the right CR as well and it does this by verifying that x.y.com is > presenting the hostname it expects and that the public key it's > presented matched the expected value and that the entity on the remote > side can prove they have the private half of the key. > > The point is that there are two identities here: "foo", and > "x.y.com". The current text is really only talking about "foo" but it > doesn't clearly say that. > > And, to make matters more confusing... When the NG/NR process steps > in then it gets more confusing: > > > SNMPv3 SSH SNMPv3 > Protocol > > +---------------------------------------+ +-----------+ > |NG | I'm foo |CR | > | +------+ +-----+ +----+ |--------------->| +----+ | > | | VACM |--->| TSM |----->| TM | | | | TM | | > | +------+ +-----+ +----+ |<---------------| +----+ | > | . | I'm x.y.com | | > +-------o-------------------------------+ +-----------+ > O > O > +--------------------+ > |I'll let "foo" | > |see my notifications| > |today ... | > +--------------------+ > > > (Note: The NG should still be configured to realize that x.y.com is > presenting the expected and authenticated SSH credentials) > > > This is where the problem lies. In this case, we're still using a SSH > user name to identify *ourselves* and that is the outgoing > securityName which is passed to tmSecurityNanme which becomes the > principal identity. > > The problem is that the name being used by the VACM (and potentially > other places) is always the one that the client side uses to > authenticate itself. That needs to be made clear in the text, IMHO. > I think the current text leads to confusion about this. This is the > text in the last copy: > > transport principal: the transport-authenticated identity, on > whose behalf the secure transport connection was (or should be) > established. This value is transport-, mechanism- and > implementation- specific, and is only used within a given > transport model. > > The only reason I know the correct authenticated identity to use is > because I've been thinking about it for 3 years along with the rest of > the group. I don't think most of the rest of the first-time-readers > will be able to pull out the proper value. This was an incredibly > long winded way of proposing a replacement paragraph: > > transport principal: the authenticated identity that will be used to > identify the authoritative principal for the SNMPv3 messages being > sent. For asymmetric protocols which may be presenting different > identity names for each side of the connection the transport > principal will be the locally offered identity name for outgoing > connections and the remotely authenticated name for incoming > connections. This value is transport-, mechanism- and > implementation- specific, and is only used within a given transport > model. > > For SSH, the text assures that "foo" is always what is used within > both the NG and the CR. For DTLS, it always uses the certificate that > was used to open the connection. > > > > Aside reminder: (with my "bar@" secshell specification patch, it > actually allows for the authentication to take place using "bar" > according to the SSH server side even though we still refer to it > locally as "foo" within a NG for doing authorization checks) > > -- end of proposal text -- > > -- start of extra discussion about reversing connections -- > > The security paranoid people should now be asking > themselves > > 1) ok, but what happens if the NG is sent a command from a > CG? What happens then? (ie, a call-home situation where the > client is a NG/CR). > > The answer is that the NG application, if it was also a command > responder (CR), would accept the request and believe it came from > securityName "foo". *If* the VACM was configured to allow the > "foo" user to access the CR then it would be allowed. Even though > it hadn't presented the "foo" user name itself. This is probably > worth noting in the Security Considerations as well. > > 2) ok, but what happens if the CR is sent a notification from a NG? > What happens then? (ie, the client is a CG/NR). > > The answer, again, is that the securityName must be "foo" *and* if > the application had registered itself as both a CG and a CR using > the registerContextEngineID() ASI from section 4.1.5 of RFC3411 > then it would accept the notification and do "something" with it. > There is no (standardized) authorization process for notifications > received, so it would simply be accepted. > > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Sep 16 09:26:46 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863673A6984; Tue, 16 Sep 2008 09:26:46 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6798E3A6C01 for ; Tue, 16 Sep 2008 09:26:45 -0700 (PDT) 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.475, 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 x4F0db5ijQmR for ; Tue, 16 Sep 2008 09:26:33 -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 6E1CF3A6984 for ; Tue, 16 Sep 2008 09:26:33 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA05.westchester.pa.mail.comcast.net with comcast id FP0S1a00L0mv7h055USbEQ; Tue, 16 Sep 2008 16:26:36 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id FUSa1a00G4HwxpC3XUSawj; Tue, 16 Sep 2008 16:26:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=nlmJBhFHFEAA:10 a=atgtiim5ssUA:10 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=jdKsIBHMSzdB8JdOfkYA:9 a=q6dPYC8wONPJeyR7aKoA:7 a=mgV5j3Eo6Zu8tANar00dlC-CMREA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Wes Hardaker'" References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> Date: Tue, 16 Sep 2008 12:26:34 -0400 Message-ID: <04af01c91818$fc7fde90$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> Thread-Index: AckYD9HJH5PU05sOQKWHZTSJOF6J8gAB8S4Q Cc: 'ISMS WG' Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I am in the process of editing the documents. As I try to apply Wes's proposals to the documents, I will have a much better idea whether I agree with them. Wes's and others' proposed text changes have been tremendously helpful in getting the documents updated. While processing some of the previous proposals, I have found some problems with proposed wordings that cause implicit technical changes. I cannot really react to this until I try to apply them to the drafts. Demands of my day job are constraining my time available to edit drafts and discuss the issues, so I have been focusing on getting the edits into the documents rather than participating in the email discussions. I am watching the discussions and working to make sure the documents reflect consensus, but choose not to spend a lot of time discussing the points until I see how they actually affect the documents. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, September 16, 2008 11:21 AM > To: Wes Hardaker > Cc: ISMS WG > Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals > > Hi, > > I have not seen any reaction to this message by Wes. Does this mean > everybody agrees to the proposed changes? > > /js > > PS: I personally very much like the figures - I think they are > helpful. Does it make sense to include them in the SSH TM > specifications? > > On Tue, Sep 02, 2008 at 04:55:33PM -0700, Wes Hardaker wrote: > > > > Starting note: this discussion assumes 1:1 mappings and prefixes > > turned off (ie, the default). The text below is divided into two > > sections: a long winded reason for text I'm suggesting followed by > > additional related discussion information. > > > > > > * Section 5.2.2, "transport principal": > > > > The one major think I needs to be worded a bit better is section > > 5.2.2. In particular, it discusses the "transport principal". The > > problem is that what we're using as a transport principal > is different > > depending on who is opening the connection. We keep coming back to > > this, so I'm trying again to point out the problem again but with a > > different set of ugly pictures. > > > > Let's take the case of a CG talking to a CR: > > > > SNMPv3 SSH SNMPv3 > > Protocol > > +-----------+ > +---------------------------------------+ > > |CG | |CR > | > > | +----+ | I'm foo | +----+ +-----+ > +------+ | > > | | TM | |--------------->| | TM | --> | TSM | --> > | VACM | | > > | +----+ | | +----+ +-----+ > +------+ | > > | |<---------------| > . | > > +-----------+ I'm x.y.com > +------------------------------o--------+ > > O > > O > > > +----------------+ > > > |I'll let "foo" | > > |in > today I guess| > > > +----------------+ > > > > In the above, the transport principal (and via propagation the > > tmSecurityNanme and the securityName) is "foo" right? It's what the > > CR makes the decision by. The VACM is saying yea or nay > based on it. > > It's what the CG presents to the CR in the form of a SSH > user name (in > > this TM example). But, the CG MUST also verify that it's talking to > > the right CR as well and it does this by verifying that x.y.com is > > presenting the hostname it expects and that the public key it's > > presented matched the expected value and that the entity on > the remote > > side can prove they have the private half of the key. > > > > The point is that there are two identities here: "foo", and > > "x.y.com". The current text is really only talking about > "foo" but it > > doesn't clearly say that. > > > > And, to make matters more confusing... When the NG/NR process steps > > in then it gets more confusing: > > > > > > SNMPv3 SSH SNMPv3 > > Protocol > > > > +---------------------------------------+ > +-----------+ > > |NG | I'm foo > |CR | > > | +------+ +-----+ +----+ > |--------------->| +----+ | > > | | VACM |--->| TSM |----->| TM | | > | | TM | | > > | +------+ +-----+ +----+ > |<---------------| +----+ | > > | . | I'm x.y.com > | | > > +-------o-------------------------------+ > +-----------+ > > O > > O > > +--------------------+ > > |I'll let "foo" | > > |see my notifications| > > |today ... | > > +--------------------+ > > > > > > (Note: The NG should still be configured to realize that x.y.com is > > presenting the expected and authenticated SSH credentials) > > > > > > This is where the problem lies. In this case, we're still > using a SSH > > user name to identify *ourselves* and that is the outgoing > > securityName which is passed to tmSecurityNanme which becomes the > > principal identity. > > > > The problem is that the name being used by the VACM (and potentially > > other places) is always the one that the client side uses to > > authenticate itself. That needs to be made clear in the text, IMHO. > > I think the current text leads to confusion about this. This is the > > text in the last copy: > > > > transport principal: the transport-authenticated identity, on > > whose behalf the secure transport connection was (or should be) > > established. This value is transport-, mechanism- and > > implementation- specific, and is only used within a given > > transport model. > > > > The only reason I know the correct authenticated identity to use is > > because I've been thinking about it for 3 years along with > the rest of > > the group. I don't think most of the rest of the first-time-readers > > will be able to pull out the proper value. This was an incredibly > > long winded way of proposing a replacement paragraph: > > > > transport principal: the authenticated identity that will > be used to > > identify the authoritative principal for the SNMPv3 messages being > > sent. For asymmetric protocols which may be presenting different > > identity names for each side of the connection the transport > > principal will be the locally offered identity name for outgoing > > connections and the remotely authenticated name for incoming > > connections. This value is transport-, mechanism- and > > implementation- specific, and is only used within a given > transport > > model. > > > > For SSH, the text assures that "foo" is always what is used within > > both the NG and the CR. For DTLS, it always uses the > certificate that > > was used to open the connection. > > > > > > > > Aside reminder: (with my "bar@" secshell specification patch, it > > actually allows for the authentication to take place using "bar" > > according to the SSH server side even though we still refer to it > > locally as "foo" within a NG for doing authorization checks) > > > > -- end of proposal text -- > > > > -- start of extra discussion about reversing connections -- > > > > The security paranoid people should now be asking > > themselves > > > > 1) ok, but what happens if the NG is sent a command from a > > CG? What happens then? (ie, a call-home situation where the > > client is a NG/CR). > > > > The answer is that the NG application, if it was also a command > > responder (CR), would accept the request and believe it came from > > securityName "foo". *If* the VACM was configured to allow the > > "foo" user to access the CR then it would be allowed. > Even though > > it hadn't presented the "foo" user name itself. This is probably > > worth noting in the Security Considerations as well. > > > > 2) ok, but what happens if the CR is sent a notification from a NG? > > What happens then? (ie, the client is a CG/NR). > > > > The answer, again, is that the securityName must be > "foo" *and* if > > the application had registered itself as both a CG and a CR using > > the registerContextEngineID() ASI from section 4.1.5 of RFC3411 > > then it would accept the notification and do "something" with it. > > There is no (standardized) authorization process for > notifications > > received, so it would simply be accepted. > > > > -- > > Wes Hardaker > > Sparta, Inc. > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 17 08:31:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204E628C29D; Wed, 17 Sep 2008 08:31:06 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0356A28C2A5 for ; Wed, 17 Sep 2008 08:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 hDFqp7ZZzeH3 for ; Wed, 17 Sep 2008 08:30:54 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 4C88F28C254 for ; Wed, 17 Sep 2008 08:30:54 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA07.westchester.pa.mail.comcast.net with comcast id FpcE1a0060QuhwU57rX6By; Wed, 17 Sep 2008 15:31:06 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.westchester.pa.mail.comcast.net with comcast id FrWj1a00P4HwxpC3NrWj25; Wed, 17 Sep 2008 15:30:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=nlmJBhFHFEAA:10 a=atgtiim5ssUA:10 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=_lZdu8sKjZM_EJAfiPUA:9 a=hZdpSk6nFY-LAfn8WaYA:7 a=mxYsd2T4ATLQ6SFZ6rCxsX7PAN0A:4 a=nXjPMxIiGpsA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Wes Hardaker'" References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> Date: Wed, 17 Sep 2008 11:31:05 -0400 Message-ID: <055401c918da$66bded30$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> Thread-Index: AckYD9HJH5PU05sOQKWHZTSJOF6J8gAwRaPw Cc: 'ISMS WG' Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Actually, the pictures are incorrect from an RFC3411 perspective. And it is important to not confuse readers with incorrect pictures. So if we include pictures similar to this, then we need to be sure to label them as being inaccurate representations of RFC3411 modularity, but as guides to understanding the issue. -- We have started to mix things up in a way that could be confusing, but also might be enabling. And we may need to consider the security issues related to how an operator configures notifications. In SNMPv3, securityName was meant to be an identifier of the principal on whose behalf operations would be performed. The principal would be the same on both sides since the community models and USM used shared keys, and therefore the identifier would be the same on both sides (and the securityModel and securityName are passed in an snmpv3 message to permit algorithm agility). With SSH, the asymetric security introduces two principals - the client and the server, but once the user is authenticated using user-auth, both sides have the same SSH user name associated with the session because the authenticated user name is in the SSH_MSG_USERAUTH_SUCCESS message (except possibly for GSSAPI - gee thank guys ;-), and that can be mapped to consistent securityNames on both sides. An application passes the desired SSH principal to the SSH client, the client and server agree on which name is authenticated, and the SSH implementation passes the user name to the application (somehow). With the "user@foo.com" transport addressing, we are breaking the basic assumption. Now the operator has two principals - a local principal for ACM and a remote principal for authentication, and we have no rules that they must be the same; in fact, we deliberately allow them to be different (and expect them to be different). Therefore the securityName used by the NO no longer necessarily represents the principal to be authenticated. An operator can configure the NO to do a ACM check against "foo", but is there anything that prevents the operator from specifying the receiving principal (foo@x.y.com) or the receiving host (x.y.com) as the securityName? We have lost the binding between the name used for ACM and the name used for authentication. In the community models and USM, I think you cannot misconfigure a system to specify securityName="dbh" is to be authenticated by the remote system, and securityname="root" to determine what is allowed to be sent. Now you can. I know the SNMPv3 WG wanted these two identities to be bound together because I wrote a proposal to allow them to be different by sending one identity in the security parameters and another in the PDU, and it was totally rejected because there was no binding - the ACM was supposed to be applied to the authenticated principal (even if authz was done before authn). So this change to use "user@x.y.com" seems to be a definite override of an SNMPv3 WG consensus. As we discussed earlier this year, the wording in the SNMPv3 documents does not force this binding. I assure you that was an oversight related to the fact that the ACM decision is an optional feature of the application subsystem (although required by the existing application "models"). If the operator can configure the NO to use two different principals, what are the security considerations of that change? I think we need to consider any vulnerabilities caused by a lack of any binding between authn and authz. We also should consider security properties when 1) the operator uses an unauthenticated local name for the ACM, 2) the operator uses the authenticated remote user (user@x.y.com) for ACM, and 3) the operator uses the authenticated remote host (x.y.com) for ACM, and 4). I can see operators experimenting with different possibilities, and we should understand the security implications. Maybe we should REQUIRE or RECOMMEND a particular approach to ensure consistent interoperable security properties. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, September 16, 2008 11:21 AM > To: Wes Hardaker > Cc: ISMS WG > Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals > > Hi, > > I have not seen any reaction to this message by Wes. Does this mean > everybody agrees to the proposed changes? > > /js > > PS: I personally very much like the figures - I think they are > helpful. Does it make sense to include them in the SSH TM > specifications? > > On Tue, Sep 02, 2008 at 04:55:33PM -0700, Wes Hardaker wrote: > > > > Starting note: this discussion assumes 1:1 mappings and prefixes > > turned off (ie, the default). The text below is divided into two > > sections: a long winded reason for text I'm suggesting followed by > > additional related discussion information. > > > > > > * Section 5.2.2, "transport principal": > > > > The one major think I needs to be worded a bit better is section > > 5.2.2. In particular, it discusses the "transport principal". The > > problem is that what we're using as a transport principal > is different > > depending on who is opening the connection. We keep coming back to > > this, so I'm trying again to point out the problem again but with a > > different set of ugly pictures. > > > > Let's take the case of a CG talking to a CR: > > > > SNMPv3 SSH SNMPv3 > > Protocol > > +-----------+ > +---------------------------------------+ > > |CG | |CR > | > > | +----+ | I'm foo | +----+ +-----+ > +------+ | > > | | TM | |--------------->| | TM | --> | TSM | --> > | VACM | | > > | +----+ | | +----+ +-----+ > +------+ | > > | |<---------------| > . | > > +-----------+ I'm x.y.com > +------------------------------o--------+ > > O > > O > > > +----------------+ > > > |I'll let "foo" | > > |in > today I guess| > > > +----------------+ > > > > In the above, the transport principal (and via propagation the > > tmSecurityNanme and the securityName) is "foo" right? It's what the > > CR makes the decision by. The VACM is saying yea or nay > based on it. > > It's what the CG presents to the CR in the form of a SSH > user name (in > > this TM example). But, the CG MUST also verify that it's talking to > > the right CR as well and it does this by verifying that x.y.com is > > presenting the hostname it expects and that the public key it's > > presented matched the expected value and that the entity on > the remote > > side can prove they have the private half of the key. > > > > The point is that there are two identities here: "foo", and > > "x.y.com". The current text is really only talking about > "foo" but it > > doesn't clearly say that. > > > > And, to make matters more confusing... When the NG/NR process steps > > in then it gets more confusing: > > > > > > SNMPv3 SSH SNMPv3 > > Protocol > > > > +---------------------------------------+ > +-----------+ > > |NG | I'm foo > |CR | > > | +------+ +-----+ +----+ > |--------------->| +----+ | > > | | VACM |--->| TSM |----->| TM | | > | | TM | | > > | +------+ +-----+ +----+ > |<---------------| +----+ | > > | . | I'm x.y.com > | | > > +-------o-------------------------------+ > +-----------+ > > O > > O > > +--------------------+ > > |I'll let "foo" | > > |see my notifications| > > |today ... | > > +--------------------+ > > > > > > (Note: The NG should still be configured to realize that x.y.com is > > presenting the expected and authenticated SSH credentials) > > > > > > This is where the problem lies. In this case, we're still > using a SSH > > user name to identify *ourselves* and that is the outgoing > > securityName which is passed to tmSecurityNanme which becomes the > > principal identity. > > > > The problem is that the name being used by the VACM (and potentially > > other places) is always the one that the client side uses to > > authenticate itself. That needs to be made clear in the text, IMHO. > > I think the current text leads to confusion about this. This is the > > text in the last copy: > > > > transport principal: the transport-authenticated identity, on > > whose behalf the secure transport connection was (or should be) > > established. This value is transport-, mechanism- and > > implementation- specific, and is only used within a given > > transport model. > > > > The only reason I know the correct authenticated identity to use is > > because I've been thinking about it for 3 years along with > the rest of > > the group. I don't think most of the rest of the first-time-readers > > will be able to pull out the proper value. This was an incredibly > > long winded way of proposing a replacement paragraph: > > > > transport principal: the authenticated identity that will > be used to > > identify the authoritative principal for the SNMPv3 messages being > > sent. For asymmetric protocols which may be presenting different > > identity names for each side of the connection the transport > > principal will be the locally offered identity name for outgoing > > connections and the remotely authenticated name for incoming > > connections. This value is transport-, mechanism- and > > implementation- specific, and is only used within a given > transport > > model. > > > > For SSH, the text assures that "foo" is always what is used within > > both the NG and the CR. For DTLS, it always uses the > certificate that > > was used to open the connection. > > > > > > > > Aside reminder: (with my "bar@" secshell specification patch, it > > actually allows for the authentication to take place using "bar" > > according to the SSH server side even though we still refer to it > > locally as "foo" within a NG for doing authorization checks) > > > > -- end of proposal text -- > > > > -- start of extra discussion about reversing connections -- > > > > The security paranoid people should now be asking > > themselves > > > > 1) ok, but what happens if the NG is sent a command from a > > CG? What happens then? (ie, a call-home situation where the > > client is a NG/CR). > > > > The answer is that the NG application, if it was also a command > > responder (CR), would accept the request and believe it came from > > securityName "foo". *If* the VACM was configured to allow the > > "foo" user to access the CR then it would be allowed. > Even though > > it hadn't presented the "foo" user name itself. This is probably > > worth noting in the Security Considerations as well. > > > > 2) ok, but what happens if the CR is sent a notification from a NG? > > What happens then? (ie, the client is a CG/NR). > > > > The answer, again, is that the securityName must be > "foo" *and* if > > the application had registered itself as both a CG and a CR using > > the registerContextEngineID() ASI from section 4.1.5 of RFC3411 > > then it would accept the notification and do "something" with it. > > There is no (standardized) authorization process for > notifications > > received, so it would simply be accepted. > > > > -- > > Wes Hardaker > > Sparta, Inc. > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 17 08:35:11 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C2328C254; Wed, 17 Sep 2008 08:35:11 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3EC3A6C47 for ; Wed, 17 Sep 2008 08:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.686, 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 kfTKA31Mqlp4 for ; Wed, 17 Sep 2008 08:35:09 -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 CF36B3A6834 for ; Wed, 17 Sep 2008 08:35:08 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D18EE399B49; Wed, 17 Sep 2008 08:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=77sRodGZyB4Nqn17FhrQWghBlAg=; b=K8KH 3L9XNbg+hHBbQXhKEYc6HJeoQSTDrVShhNy3OGkfJKDBOVn8SsuFJfbCaNwiUkxP f85HiNwRl4GebwumPvIqDjIU3GODgOaS4d9eYcJn09Ef8H0OdjXeI4ydbF9FTN27 Wi1ooP5Kd8N3Vz6HiI826FMXvgH1cjauC9a0OtA= Received: by wes.hardakers.net (Postfix, from userid 274) id 639AA399B4A; Wed, 17 Sep 2008 08:35:21 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> <055401c918da$66bded30$0600a8c0@china.huawei.com> Date: Wed, 17 Sep 2008 08:35:20 -0700 In-Reply-To: <055401c918da$66bded30$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 17 Sep 2008 11:31:05 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: 'ISMS WG' Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org DH> So if we include pictures similar to this, then we need to be sure to DH> label them as being inaccurate representations of RFC3411 modularity, DH> but as guides to understanding the issue. They were indented to be helpful to real-world implementation and discussion around what is happening and weren't intended to be used within the documents... If you want an architecturally labeled diagram, one could easily be created. (The reason I didn't do a complete diagram was I was trying for simplicity for understanding the situation; eg, the engine blocks don't really exist in the CR in an architecture, but everyone does implement the engine directly in the CR application in the real world) -- We have started to mix things up in a way that could be confusing, but also might be enabling. And we may need to consider the security issues related to how an operator configures notifications. In SNMPv3, securityName was meant to be an identifier of the principal on whose behalf operations would be performed. The principal would be the same on both sides since the community models and USM used shared keys, and therefore the identifier would be the same on both sides (and the securityModel and securityName are passed in an snmpv3 message to permit algorithm agility). With SSH, the asymetric security introduces two principals - the client and the server, but once the user is authenticated using user-auth, both sides have the same SSH user name associated with the session because the authenticated user name is in the SSH_MSG_USERAUTH_SUCCESS message (except possibly for GSSAPI - gee thank guys ;-), and that can be mapped to consistent securityNames on both sides. An application passes the desired SSH principal to the SSH client, the client and server agree on which name is authenticated, and the SSH implementation passes the user name to the application (somehow). With the "user@foo.com" transport addressing, we are breaking the basic assumption. Now the operator has two principals - a local principal for ACM and a remote principal for authentication, and we have no rules that they must be the same; in fact, we deliberately allow them to be different (and expect them to be different). Therefore the securityName used by the NO no longer necessarily represents the principal to be authenticated. An operator can configure the NO to do a ACM check against "foo", but is there anything that prevents the operator from specifying the receiving principal (foo@x.y.com) or the receiving host (x.y.com) as the securityName? We have lost the binding between the name used for ACM and the name used for authentication. In the community models and USM, I think you cannot misconfigure a system to specify securityName="dbh" is to be authenticated by the remote system, and securityname="root" to determine what is allowed to be sent. Now you can. I know the SNMPv3 WG wanted these two identities to be bound together because I wrote a proposal to allow them to be different by sending one identity in the security parameters and another in the PDU, and it was totally rejected because there was no binding - the ACM was supposed to be applied to the authenticated principal (even if authz was done before authn). So this change to use "user@x.y.com" seems to be a definite override of an SNMPv3 WG consensus. As we discussed earlier this year, the wording in the SNMPv3 documents does not force this binding. I assure you that was an oversight related to the fact that the ACM decision is an optional feature of the application subsystem (although required by the existing application "models"). If the operator can configure the NO to use two different principals, what are the security considerations of that change? I think we need to consider any vulnerabilities caused by a lack of any binding between authn and authz. We also should consider security properties when 1) the operator uses an unauthenticated local name for the ACM, 2) the operator uses the authenticated remote user (user@x.y.com) for ACM, and 3) the operator uses the authenticated remote host (x.y.com) for ACM, and 4). I can see operators experimenting with different possibilities, and we should understand the security implications. Maybe we should REQUIRE or RECOMMEND a particular approach to ensure consistent interoperable security properties. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, September 16, 2008 11:21 AM > To: Wes Hardaker > Cc: ISMS WG > Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals > > Hi, > > I have not seen any reaction to this message by Wes. Does this mean > everybody agrees to the proposed changes? > > /js > > PS: I personally very much like the figures - I think they are > helpful. Does it make sense to include them in the SSH TM > specifications? > > On Tue, Sep 02, 2008 at 04:55:33PM -0700, Wes Hardaker wrote: > > > > Starting note: this discussion assumes 1:1 mappings and prefixes > > turned off (ie, the default). The text below is divided into two > > sections: a long winded reason for text I'm suggesting followed by > > additional related discussion information. > > > > > > * Section 5.2.2, "transport principal": > > > > The one major think I needs to be worded a bit better is section > > 5.2.2. In particular, it discusses the "transport principal". The > > problem is that what we're using as a transport principal > is different > > depending on who is opening the connection. We keep coming back to > > this, so I'm trying again to point out the problem again but with a > > different set of ugly pictures. > > > > Let's take the case of a CG talking to a CR: > > > > SNMPv3 SSH SNMPv3 > > Protocol > > +-----------+ > +---------------------------------------+ > > |CG | |CR > | > > | +----+ | I'm foo | +----+ +-----+ > +------+ | > > | | TM | |--------------->| | TM | --> | TSM | --> > | VACM | | > > | +----+ | | +----+ +-----+ > +------+ | > > | |<---------------| > . | > > +-----------+ I'm x.y.com > +------------------------------o--------+ > > O > > O > > > +----------------+ > > > |I'll let "foo" | > > |in > today I guess| > > > +----------------+ > > > > In the above, the transport principal (and via propagation the > > tmSecurityNanme and the securityName) is "foo" right? It's what the > > CR makes the decision by. The VACM is saying yea or nay > based on it. > > It's what the CG presents to the CR in the form of a SSH > user name (in > > this TM example). But, the CG MUST also verify that it's talking to > > the right CR as well and it does this by verifying that x.y.com is > > presenting the hostname it expects and that the public key it's > > presented matched the expected value and that the entity on > the remote > > side can prove they have the private half of the key. > > > > The point is that there are two identities here: "foo", and > > "x.y.com". The current text is really only talking about > "foo" but it > > doesn't clearly say that. > > > > And, to make matters more confusing... When the NG/NR process steps > > in then it gets more confusing: > > > > > > SNMPv3 SSH SNMPv3 > > Protocol > > > > +---------------------------------------+ > +-----------+ > > |NG | I'm foo > |CR | > > | +------+ +-----+ +----+ > |--------------->| +----+ | > > | | VACM |--->| TSM |----->| TM | | > | | TM | | > > | +------+ +-----+ +----+ > |<---------------| +----+ | > > | . | I'm x.y.com > | | > > +-------o-------------------------------+ > +-----------+ > > O > > O > > +--------------------+ > > |I'll let "foo" | > > |see my notifications| > > |today ... | > > +--------------------+ > > > > > > (Note: The NG should still be configured to realize that x.y.com is > > presenting the expected and authenticated SSH credentials) > > > > > > This is where the problem lies. In this case, we're still > using a SSH > > user name to identify *ourselves* and that is the outgoing > > securityName which is passed to tmSecurityNanme which becomes the > > principal identity. > > > > The problem is that the name being used by the VACM (and potentially > > other places) is always the one that the client side uses to > > authenticate itself. That needs to be made clear in the text, IMHO. > > I think the current text leads to confusion about this. This is the > > text in the last copy: > > > > transport principal: the transport-authenticated identity, on > > whose behalf the secure transport connection was (or should be) > > established. This value is transport-, mechanism- and > > implementation- specific, and is only used within a given > > transport model. > > > > The only reason I know the correct authenticated identity to use is > > because I've been thinking about it for 3 years along with > the rest of > > the group. I don't think most of the rest of the first-time-readers > > will be able to pull out the proper value. This was an incredibly > > long winded way of proposing a replacement paragraph: > > > > transport principal: the authenticated identity that will > be used to > > identify the authoritative principal for the SNMPv3 messages being > > sent. For asymmetric protocols which may be presenting different > > identity names for each side of the connection the transport > > principal will be the locally offered identity name for outgoing > > connections and the remotely authenticated name for incoming > > connections. This value is transport-, mechanism- and > > implementation- specific, and is only used within a given > transport > > model. > > > > For SSH, the text assures that "foo" is always what is used within > > both the NG and the CR. For DTLS, it always uses the > certificate that > > was used to open the connection. > > > > > > > > Aside reminder: (with my "bar@" secshell specification patch, it > > actually allows for the authentication to take place using "bar" > > according to the SSH server side even though we still refer to it > > locally as "foo" within a NG for doing authorization checks) > > > > -- end of proposal text -- > > > > -- start of extra discussion about reversing connections -- > > > > The security paranoid people should now be asking > > themselves > > > > 1) ok, but what happens if the NG is sent a command from a > > CG? What happens then? (ie, a call-home situation where the > > client is a NG/CR). > > > > The answer is that the NG application, if it was also a command > > responder (CR), would accept the request and believe it came from > > securityName "foo". *If* the VACM was configured to allow the > > "foo" user to access the CR then it would be allowed. > Even though > > it hadn't presented the "foo" user name itself. This is probably > > worth noting in the Security Considerations as well. > > > > 2) ok, but what happens if the CR is sent a notification from a NG? > > What happens then? (ie, the client is a CG/NR). > > > > The answer, again, is that the securityName must be > "foo" *and* if > > the application had registered itself as both a CG and a CR using > > the registerContextEngineID() ASI from section 4.1.5 of RFC3411 > > then it would accept the notification and do "something" with it. > > There is no (standardized) authorization process for > notifications > > received, so it would simply be accepted. > > > > -- > > Wes Hardaker > > Sparta, Inc. > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > -- > 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 > -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 17 09:13:37 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92123A6C6A; Wed, 17 Sep 2008 09:13:37 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068EB3A6C31 for ; Wed, 17 Sep 2008 09:13:37 -0700 (PDT) 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.430, 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 IuIEAB3Kqpkl for ; Wed, 17 Sep 2008 09:13:36 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 0D24E28C2C2 for ; Wed, 17 Sep 2008 09:13:35 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA09.westchester.pa.mail.comcast.net with comcast id Fs9g1a00D0bG4ec59sDo0H; Wed, 17 Sep 2008 16:13:48 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.westchester.pa.mail.comcast.net with comcast id FsDk1a00a4HwxpC3PsDkSH; Wed, 17 Sep 2008 16:13:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=pOGhRdg9VgcA:10 a=NYneYwrJ79wA:10 a=yZD-QsmmItUUUcPhgNcA:9 a=uVV_9cgQ2eszGUkdBjBRmTuyChkA:4 a=86L1PGDMzkIA:10 a=zeshHG33Dl4A:10 a=77UB_OrJ-6MA:10 From: "David Harrington" To: "'Wes Hardaker'" References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de><055401c918da$66bded30$0600a8c0@china.huawei.com> Date: Wed, 17 Sep 2008 12:13:44 -0400 Message-ID: <055b01c918e0$5c470930$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AckY2wBgo7IPvNIHTY+maroJfWPmZAABQ1qA Cc: 'ISMS WG' Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I understand why you didn't do an architecturally accurate diagram. I support the current diagrams, but just want to make sure they are labelled as being non-rfc3411-modular if we use them. You didn't comment on the stuff following the "--" line in my email; I hope you didn't think that was the end of the post. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Wednesday, September 17, 2008 11:35 AM > To: David Harrington > Cc: j.schoenwaelder@jacobs-university.de; 'Wes Hardaker'; 'ISMS WG' > Subject: Re: tmsm-13 section 5.2.2: transport principals > > > DH> So if we include pictures similar to this, then we need > to be sure to > DH> label them as being inaccurate representations of RFC3411 > modularity, > DH> but as guides to understanding the issue. > > They were indented to be helpful to real-world implementation and > discussion around what is happening and weren't intended to be used > within the documents... If you want an architecturally > labeled diagram, > one could easily be created. > > (The reason I didn't do a complete diagram was I was trying for > simplicity for understanding the situation; eg, the engine > blocks don't > really exist in the CR in an architecture, but everyone does implement > the engine directly in the CR application in the real world) _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 17 09:27:42 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9583A68B2; Wed, 17 Sep 2008 09:27:42 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16493A68B2 for ; Wed, 17 Sep 2008 09:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=0.652, 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 xZZTZSsEKrbP for ; Wed, 17 Sep 2008 09:27:40 -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 742923A6824 for ; Wed, 17 Sep 2008 09:27:39 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 5F8C3399B49; Wed, 17 Sep 2008 09:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=KTurIA/m4zHEdTPnBb0R55ZKL3Y=; b=BkmU Ip+3T0hdQA3A4En8SuSFrl0n3FHYaroO/tUpwY/B0u4FEk1k1zTjyOixUempO1tt JMX19HWgjRUaYjgr8f1rJ9iieNPY976J6mxlwnMQRDR6xDP8fP7qKJVP9Wncz6z2 hyH0G2b7fHLuUOroCf2yt+HopU2tE2/P9c5amEw= Received: by wes.hardakers.net (Postfix, from userid 274) id 39B4E2D38AE; Wed, 17 Sep 2008 09:27:50 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> <055401c918da$66bded30$0600a8c0@china.huawei.com> <055b01c918e0$5c470930$0600a8c0@china.huawei.com> Date: Wed, 17 Sep 2008 09:27:49 -0700 In-Reply-To: <055b01c918e0$5c470930$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 17 Sep 2008 12:13:44 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: 'ISMS WG' Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 17 Sep 2008 12:13:44 -0400, "David Harrington" said: DH> You didn't comment on the stuff following the "--" line in my email; I DH> hope you didn't think that was the end of the post. Whoops; I didn't see it. I'll respond to it separately. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 17 13:06:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328CC3A6814; Wed, 17 Sep 2008 13:06:06 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E167A3A683D for ; Wed, 17 Sep 2008 13:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 V9LZPjjUUJs1 for ; Wed, 17 Sep 2008 13:06:03 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id B6DDB3A680B for ; Wed, 17 Sep 2008 13:06:03 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m8HK6B3i005831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2008 16:06:12 -0400 (EDT) Date: Wed, 17 Sep 2008 16:06:11 -0400 From: Jeffrey Hutzelman To: David Harrington , j.schoenwaelder@jacobs-university.de, "'Wes Hardaker'" Message-ID: In-Reply-To: <200809171531.m8HFVLmf027481@raisinbran.srv.cs.cmu.edu> References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> <200809171531.m8HFVLmf027481@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Cc: 'ISMS WG' , jhutz@cmu.edu Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, September 17, 2008 11:31:05 AM -0400 David Harrington wrote: > With SSH, the asymetric security introduces two principals - the > client and the server, but once the user is authenticated using > user-auth, both sides have the same SSH user name associated with the > session because the authenticated user name is in the > SSH_MSG_USERAUTH_SUCCESS message (except possibly for GSSAPI - gee > thank guys ;-), Huh? No. Inside SSH, the authenticated username is the one that was used in an SSH_MSG_USERAUTH_REQUEST message that resulted in successful authentication, as indicated by an SSH_MSG_USERAUTH_SUCCESS message (which itself does not contain any data). However, you are not inside SSH; you are outside SSH and so don't get to peek inside its messages; that would violate the abstraction. As far as SNMP is concerned, the authenticated username is the one SSH gave it. > I know the SNMPv3 WG wanted these two identities to be bound together > because I wrote a proposal to allow them to be different by sending > one identity in the security parameters and another in the PDU, and it > was totally rejected because there was no binding - the ACM was > supposed to be applied to the authenticated principal (even if authz > was done before authn). So this change to use "user@x.y.com" seems to > be a definite override of an SNMPv3 WG consensus. Unfortunately, the SNMPv3 security name design was shortsighted, limited by USM being the only model anyone had in mind and by frequently ignoring the abstraction boundary. As a result, it has been a real pain to figure out what the architecture is supposed to be, because there isn't one! The shortsighted design is _wrong_. It makes the assumption that an NO can successfully authenticate and deliver a notification by telling the NR the _NO's name for the NR_. The NO does not actually identify itself to the NR in any way; instead, it depends on USM's assumption that the NR's name for the NO will be the same as the NO's name for the NR, because USM names do not name principals; they name pairwise associations between principals. This model _does not work_ in systems where the names apply to principals rather than to principal pairs. There is no non-pairwise system in which I can authenticate to you by telling you only your name; I must tell you my name. Of course, I need to _know_ your name, so I know who I'm talking to. This is another difference between USM and non-pairwise systems -- everyone needs to know _two_ names, their own and that of their peer. The difficulty I think you are getting at here is that SSH throws an additional complexity into the mix, which is that an entity acting in the role of an SSH server might not have the same name as the same entity acting in the role of an SSH client. In fact, this issue is sufficiently complex that SSH client implementations typically provide a mechanism for storing information about arbitrarily-named servers, and a set of conventions for deriving the server's name and its transport address (or at least, its network address) from the same user input. So, we have two major problems... (1) Recording the name an NO must use for itself when talking to an NR (2) Recording the name an NO must use for the NR it is talking to, and correlating that name to the securityName used by VACM. We have agreed, I think, to resolve (1) by extending the SSH transport address format to record the ssh username to use on an outgoing connection, in a syntax that will be familiar to users of SSH. So far, we have handled (2) somewhat poorly. Particularly, we seem to be determining the NR's name by deriving it from the "hostname" in its transport address, in much the same way that SSH clients normally do. However, as you point out, this provides no binding to the securityName, which is a problem. Effectively, the only binding is the operator's assertion that using a particular transport address (and authenticating the SSH server in the usual way) will reach an entity that corresponds to the configured securityName. One solution might be to require on outgoing connections that the securityName be used as the SSH client's name for the remote SSH server, rather than deriving that from the transport address, and that the transport address be used _only_ to identify the remote IP address, port, and outgoing SSH username. This could make configuration somewhat more complex, as it would require maintaining in the SSH client's database a mapping between securityName and host key or other credentials, rather than the usual mapping involving a hostname. However, this should not be too difficult for any SSH implementation general enough to be used in ISMS. One potential disadvantage to binding an NR's SSH server credentials to its securityName rather than to its transport address is that an NG will expect any given securityName to use the same credentials regardless of its transport address, and in practice that may not be feasible -- a user who uses any of several different management stations will always have the same username (authenticated by central infrastructure, we hope), but each management station will likely have its own SSH host key pair (hopefully distinct from key pairs used by that station for other users), and requiring users to keep "their" SSH host key in sync between management stations would make the system unusable. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 17 13:49:09 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2DBA3A694D; Wed, 17 Sep 2008 13:49:09 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326A43A694D for ; Wed, 17 Sep 2008 13:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, WEIRD_PORT=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 SODki-NgrN+2 for ; Wed, 17 Sep 2008 13:49:07 -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 58A963A6814 for ; Wed, 17 Sep 2008 13:49:05 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D957D399B4A; Wed, 17 Sep 2008 13:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=MJIckQkCKF3jIc8+FDMj7sJtG8o=; b=NGDJ dKKLLegODBAEX1L8wuIGzG0gd7gJjZ2Sy6byE6dZsl+nVy7YSfMmu4z0p1ppMpS1 2z3ECMEE2oFlcXyMBlA82UROu5X6k8b2vfPDjgTAuKroCGWB4e6pGRPPxUPTDOXi nbXvYrVQ/QOw0I3YqIdb/P8OBF2+fDXCWu1qLHU= Received: by wes.hardakers.net (Postfix, from userid 274) id 448EE399B4B; Wed, 17 Sep 2008 13:49:18 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> <200809171531.m8HFVLmf027481@raisinbran.srv.cs.cmu.edu> Date: Wed, 17 Sep 2008 13:49:16 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Wed, 17 Sep 2008 16:06:11 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: 'ISMS WG' Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 17 Sep 2008 16:06:11 -0400, Jeffrey Hutzelman said: [thanks Jeff for writing first, since you significantly shortened my reply since I agree with most of what you said!] >> With SSH, the asymetric security introduces two principals - the >> client and the server, but once the user is authenticated using >> user-auth, both sides have the same SSH user name associated with the >> session because the authenticated user name is in the >> SSH_MSG_USERAUTH_SUCCESS message (except possibly for GSSAPI - gee >> thank guys ;-), JH> Huh? No. I agree with Jeff here completely... Just because you used a user name to authenticate with, it does *not* suddenly change the name both sides of the connection use to "name" it. A client will still name the remote side foo.example.com, and the server will still name the person connecting "dbh". Never in that transaction does the client suddenly say "I'm talking to 'dbh' on the other system" because it's gotten past the authentication stage. JH> So, we have two major problems... JH> (1) Recording the name an NO must use for itself when talking to an NR JH> (2) Recording the name an NO must use for the NR it is talking to, and JH> correlating that name to the securityName used by VACM. Up until this point, you and I are in agreement. However, starting with the above text you're making some statements that are invalid about the way SNMPv3 handles processing notifications. JH> We have agreed, I think, to resolve (1) by extending the SSH transport JH> address format to record the ssh username to use on an outgoing JH> connection, in a syntax that will be familiar to users of SSH. Yep. We agree on this point. JH> So far, we have handled (2) somewhat poorly. Particularly, we seem to JH> be determining the NR's name by deriving it from the "hostname" in its JH> transport address, in much the same way that SSH clients normally JH> do. However, as you point out, this provides no binding to the JH> securityName, which is a problem. Effectively, the only binding is JH> the operator's assertion that using a particular transport address JH> (and authenticating the SSH server in the usual way) will reach an JH> entity that corresponds to the configured securityName. This, unfortunately, is wrong. And I say unfortunately because the situation is actually worse, not better. The problem is that the VACM processing handles way too early in the desire to send a notification. The typical (snmp-instrumented) agent which needs to act as a NO in order to send a "sky is falling" notification goes through these steps: 1) panics. (realizes it's in trouble and needs to send a notification). [yes, Virginia, there are good notifications too] 2) creates the notification to be sent, including varbinds 3) looks up it's notification destinations in the NOTIFICATION-MIB and the TARGET-MIB (or other proprietary configuration) 4) Finds (for example): domain: SSH address: manager.example.com:9876 securityName: foo securityModel: TSM 5) Decides whether user 'foo' using 'TSM' is allowed to see the notification that needs to be sent. 6) If the VACM says it's ok, then at this point, 'foo' using TSM is authorized to see it. We've only checked authorization against the assigned name "foo" without actually proving the remote side can prove that they're manager.example.com successfully. 7) lots of internal, security-irrelevant stuff happens between 6 and 8 8) The TSM gets the request to send an outgoing notification and doesn't have a security cache for it then TSM (outgoing step 3) sets the outgoing tmSecurityName to 'foo'. 9) lots more stuff 10) the SSH TM is either opened here, using only the address above and possibly the securityName (or "someone@" if present in the address) to connect to manager.example.com. *Because* we've decide that it's implementation specific as to how an implementation verifies that the credentials (eg RSA cert) presented by manager.example.com legitimately belongs to manager.example.com, that's all swept under the rug as "implementation dependent". The really really important thing to take away from all of the above, is that the VACM makes it's decision on whether a notification can be sent to some one *long before* the transport is opened. There is at no point in any of this that the securityName is derived from the NRs address. It comes straight out of the mapping table from the configuration in the TARGET-MIB. The VACM operator *only* on the security name assigned to the "target" by the operator. This makes the SNMP protocol very very unique. It's authorizing something long before it's even begun to talk to the other side. Now... does this matter? I don't think so. It's just a name. As long as there is all the complete mapping pieces, it doesn't matter what we locally (to the NO) name this "connection". As long as I verify the remote credentials and they match what I expect, the name is supplementary to the cryptography. Somewhere, though, there has to exist a table mapping manager.example.com to the expected presented cert. In openssh this is in ~/.ssh/known_hosts. But right now there is no interoperable way to set up this file (as it's been declared, for good reasons, out of scope). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 17 15:12:59 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901DD3A6966; Wed, 17 Sep 2008 15:12:59 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C333A699C for ; Wed, 17 Sep 2008 15:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=0.941, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 8umHydBjOgXN for ; Wed, 17 Sep 2008 15:12:57 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id E56BE3A68D3 for ; Wed, 17 Sep 2008 15:12:56 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m8HMD5wC010788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2008 18:13:06 -0400 (EDT) Date: Wed, 17 Sep 2008 18:13:05 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: <4CB0DDF80465F2D76EE7A5C4@sirius.fac.cs.cmu.edu> In-Reply-To: References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> <200809171531.m8HFVLmf027481@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Cc: 'ISMS WG' , jhutz@cmu.edu Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, September 17, 2008 01:49:16 PM -0700 Wes Hardaker wrote: > 4) Finds (for example): > domain: SSH > address: manager.example.com:9876 > securityName: foo > securityModel: TSM I think we're more in agreement than you think. I understand the unusual authorization-before-authentication model that gets used here, and I don't think it makes a difference. Under our current model, the above record carries with it the implicit assertion that the SSH server at manager.example.com:9876, however you eventually end up authenticating that, is equivalent to the securityName "foo" under TSM. So when you eventually set up a connection to that host and it successfully authenticates, you know it is safe to send that host any notifications that "foo" is authorized to receive. > 10) the SSH TM is either opened here, using only the address above and > possibly the securityName (or "someone@" if present in the address) > to connect to manager.example.com. I think there's a disconnect here that we may choose to fix. Currently, the SSH connection is opened to a particular server running on a specified transport address. We expect that server to prove its identity based on credentials (a host key) that we associate with that transport address in an implementation-specified way. We then authenticate to it using an SSH username that is derived from the "someone@" in the address, or from the securityName. Unfortunately, this depends on the assertion I described above to insure that the SSH server we reach represents an agent authorized to receive notifications that "foo" is authorized to receive. What if, instead of associating host credentials with a transport address in an implementation-specific way, we associated them with a securityName, or possibly with a (transport address, securityName) tuple? Would that resolve the issue? -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 17 15:53:43 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD4E3A68FD; Wed, 17 Sep 2008 15:53:43 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AAA3A682A for ; Wed, 17 Sep 2008 15:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, WEIRD_PORT=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 kZngx4FJcv6l for ; Wed, 17 Sep 2008 15:53:41 -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 77CA63A68FD for ; Wed, 17 Sep 2008 15:53:41 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 964D7399B4A; Wed, 17 Sep 2008 15:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=rE9Ce7fJvCMYRkHmjLvH788c+PY=; b=TZ8U Po0wmhlxWzFGGxFMQ26CTRwn/po9nJTZStLQ9cUIrokkp01aKPGhvU1wHhWmLR2+ gEGjYZZ8kgjVGTRSwz289rHgQWhYRgxqk6mJON1CFgm4xP0YERhbsZNaAHw1+yd1 zznPF09ZzGEPypZLpFLGiNb9pAsrVMBBwNUi8ZA= Received: by wes.hardakers.net (Postfix, from userid 274) id 69C242D38AE; Wed, 17 Sep 2008 15:53:48 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> <200809171531.m8HFVLmf027481@raisinbran.srv.cs.cmu.edu> <4CB0DDF80465F2D76EE7A5C4@sirius.fac.cs.cmu.edu> Date: Wed, 17 Sep 2008 15:53:47 -0700 In-Reply-To: <4CB0DDF80465F2D76EE7A5C4@sirius.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 17 Sep 2008 18:13:05 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: 'ISMS WG' Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 17 Sep 2008 18:13:05 -0400, Jeffrey Hutzelman said: >> 4) Finds (for example): >> domain: SSH >> address: manager.example.com:9876 >> securityName: foo >> securityModel: TSM JH> Under our current model, the above record carries with it the implicit JH> assertion that the SSH server at manager.example.com:9876, however you JH> eventually end up authenticating that, is equivalent to the JH> securityName "foo" under TSM. Agreed. That's not, admittedly, what I thought you were implying though so I'm certainly happier that we're on the same page and actually always have been :-) [...snip...] JH> We then authenticate to it using an SSH username that is derived JH> from the "someone@" in the address, or from the securityName. JH> Unfortunately, this depends on the assertion I described above to JH> insure that the SSH server we reach represents an agent authorized to JH> receive notifications that "foo" is authorized to receive. Good so far. JH> What if, instead of associating host credentials with a transport JH> address in an implementation-specific way, we associated them with a JH> securityName, or possibly with a (transport address, securityName) JH> tuple? Would that resolve the issue? That would be one way of adding that last bit of needed configuration. In reality it would be an augmentation to the snmpTargetAddrTable that would contain rows that only apply when snmpTargetAddrTDomain was of type snmpSSHDomain. It could contain 1-2 indexes of the above, and the final column would be what though? This is where we got stuck before because it was declared out of scope for ISMS to identify keying material expected from the remote side because it violated the separation layer. The options are (assuming 2 indexes here): 1) indexes=securityName,TAddress columns=pubkeytype,pubkeyvalue We'd need to publish the list of current key types (eg, RSA, DSA, ...) and have IANA publish a MIB every time SSH adds another one. pubkeyvalue would then be a binary blob. Caveats though: - this violates the abstraction (which I don't care about because it increases usability, but I thought you were against SSH config) - (will the mib still be good when SSH/X.509 comes around?) - pubkeyvalue sizes would run into tricky SNMP configuration over non-fragmenting UDP (you'd have to implement trickle-in configuration or other oddities to take care of it). 2) indexes=securityName,TAddress columns=pubkeytype,hash(pubkeyvalue) Similar but would authorize based on a hash of the key Caveats though: - still violates abstraction layer - gets around the sizing issues - massively different security implications and this alone makes it not likely to be an acceptable candidate. I only offer it because someone would ;-) 3) indexes=securityName,TAddress columns=keyname Where keyname would be a unique index to local configuration store pointing to a particular key Caveats: - doesn't buy us anything really. still requires an implementation dependent keyname -> key lookup which is really no different than what we have today: TAddress->key 4) Don't standardize a MIB configuration structure, but just standardize that implementations SHOULD/MUST have a configuration mechanism that provides securityName,TAddress mapping pairs to key names. Caveats: - still requires implementation dependent configuration mechanism - the only real gain is a particular "index" mapping requirement 5) Don't standardize any expectation system Caveats: - That's where we're at today anyway. I'm very much interested in the results of this discussion, because I have the same issues with the DTLS draft but involving expected X.509 certs. I thought about adding a very similar table there for offered key expectations (but in that case, there is also CA certs to consider). It would be nice if the SSH and eventual DTLS drafts used a similar expectation architecture since they're both pub/priv based transports. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Sep 17 16:27:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2663A69C0; Wed, 17 Sep 2008 16:27:25 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E3E3A69C0 for ; Wed, 17 Sep 2008 16:27:24 -0700 (PDT) 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 N2YrCNg7VRG9 for ; Wed, 17 Sep 2008 16:27:18 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id BFF0E3A68D3 for ; Wed, 17 Sep 2008 16:27:18 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m8HNRSwV014056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2008 19:27:28 -0400 (EDT) Date: Wed, 17 Sep 2008 19:27:28 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: In-Reply-To: <200809172253.m8HMrxWB001051@grapenut.srv.cs.cmu.edu> References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de> <200809171531.m8HFVLmf027481@raisinbran.srv.cs.cmu.edu> <4CB0DDF80465F2D76EE7A5C4@sirius.fac.cs.cmu.edu> <200809172253.m8HMrxWB001051@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Cc: 'ISMS WG' , jhutz@cmu.edu Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, September 17, 2008 03:53:47 PM -0700 Wes Hardaker wrote: > I'm very much interested in the results of this discussion, because I > have the same issues with the DTLS draft but involving expected X.509 > certs. I thought about adding a very similar table there for offered > key expectations (but in that case, there is also CA certs to consider). > It would be nice if the SSH and eventual DTLS drafts used a similar > expectation architecture since they're both pub/priv based transports. SSH today has very little to say on this subject. Architecturally, there are two layers that are of interest here. SSH supports a number of key exchange algorithms, which authenticate the server based on some combination of its host keys and knowing what its name is supposed to be. It also supports a number of host key algorithms; a key exchange method may be used with any host key algorithm which supports the operations it needs. Some key exchange methods, such as the GSS-API based ones, don't require any host key operations. Note that knowing the key alone is _not sufficient_; in a GSS-API key exchange, the SSH server proves that it has a particular name but does not prove that it knows any particular host key. So, storing public key data in SNMP is not helpful, because it assumes that the public key is all you need to know. What most SSH implementations do is maintain a database of public key information indexed by hostname. So, you start with a hostname, and if you're using a key exchange method that requires a public key, you can look up the public key for that hostname in the database. Further, implementations such as OpenSSH allow one to independently specify the authentication "hostname" (-oHostKeyAlias) from the transport address (-oHostName). The name given on openssh's command line is actually neither of these, though it is used as a default value for both; in fact, it is the name of a configuration database entry which can specify nearly any options, including these as well as the authentication methods and algorithms to be used and even the remote username to be used. My first inclination is to use the transport address hostname as a key into this SSH configuration database, and also as the default transport address and authentication name. The difficulty in using it for the last purpose is that we really want that to be tied to the securityName, not the TAddress. So, my second inclination is to use the securityName as a key into that database, and also as the default for the authentication name. The TAddress would continue to be used to determine the transport address to connect to, and optionally the remote username to use (if this is not specified in the TAddress, it comes from the SSH config db, or defaults to the same as the securityName, useless as that probably is). The many caveat with this approach is that it assumes that practically everything that might be in that configuration database should be associated with the securityName rather than the TAddress or the combination. Your option 3 resolves that, by allowing us to use the combination of securityName and TAddress to look up some value, which could be treated either as a key into SSH's configuration database or as an authentication hostname (which also serves as a key into SSH's host key database, when appropriate). You can even make the question of which one implementation-dependent, by saying that the RHS is normally the hostname used by SSH for authentication, but that some SSH implementations may also use this name to find other configuration. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Sep 22 00:23:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A26C3A6CC5; Mon, 22 Sep 2008 00:23:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B9A3A6CC2 for ; Mon, 22 Sep 2008 00:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 uiat01zuonv0 for ; Mon, 22 Sep 2008 00:23:45 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4DDCF3A6780 for ; Mon, 22 Sep 2008 00:23:45 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m8M7LSfx011709; Mon, 22 Sep 2008 10:23:37 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 10:23:04 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 10:23:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Sep 2008 10:22:03 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201A87B73@vaebe104.NOE.Nokia.com> In-Reply-To: <4CB0DDF80465F2D76EE7A5C4@sirius.fac.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] tmsm-13 section 5.2.2: transport principals Thread-Index: AckZEpZMC9ADcseSQQaHttXhcM3AdADcEyOg References: <20080916152044.GB1447@elstar.iuhb02.iu-bremen.de><200809171531.m8HFVLmf027481@raisinbran.srv.cs.cmu.edu> <4CB0DDF80465F2D76EE7A5C4@sirius.fac.cs.cmu.edu> From: To: , X-OriginalArrivalTime: 22 Sep 2008 07:23:02.0564 (UTC) FILETIME=[0C5FDE40:01C91C84] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman wrote: > --On Wednesday, September 17, 2008 01:49:16 PM -0700 Wes Hardaker > wrote: > > > 4) Finds (for example): > > domain: SSH > > address: manager.example.com:9876 > > securityName: foo > > securityModel: TSM > > I think we're more in agreement than you think. I understand the > unusual authorization-before-authentication model that gets used > here, and I don't think it makes a difference. > > Under our current model, the above record carries with it the > implicit assertion that the SSH server at manager.example.com:9876, > however you eventually end up authenticating that, is equivalent to > the securityName "foo" under TSM. So when you eventually set up a > connection to that host and it successfully authenticates, you know > it is safe to send that host any notifications that "foo" is > authorized to receive. Well -- not exactly *equivalent*, but it does implicitly assert that once you've succesfully authenticated manager.example.com:9876, it's OK to send this information (which VACM says "foo" is allowed to see) there. (But it's not one-to-one equivalence; some other notifications with securityName "bar" could also have manager.example.com:9876 as transport address. But no, this doesn't really matter as long as we don't assume the implementation actually needs to find "foo" when given "manager.example.com:9876" -- and since we're doing the VACM steps long before the transport connection exists, we don't need this.) > > 10) the SSH TM is either opened here, using only the > > address above and possibly the securityName (or "someone@" > > if present in the address) to connect to manager.example.com. > > I think there's a disconnect here that we may choose to fix. > > Currently, the SSH connection is opened to a particular server > running on a specified transport address. We expect that server to > prove its identity based on credentials (a host key) that we > associate with that transport address in an implementation-specified > way. We then authenticate to it using an SSH username that is > derived from the "someone@" in the address, or from the > securityName. > > Unfortunately, this depends on the assertion I described above to > insure that the SSH server we reach represents an agent authorized > to receive notifications that "foo" is authorized to receive. > > What if, instead of associating host credentials with a transport > address in an implementation-specific way, we associated them with a > securityName, or possibly with a (transport address, securityName) > tuple? Would that resolve the issue? Using just "securityName" would probably complicate things on the command generator side (where securityName is "peer's name for us"). Associating host credentials with hostname+port is also more in line with how SSH usually works... Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms