From isms-bounces@ietf.org Mon Jan 5 13:48:38 2009 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 D83DB3A6A32; Mon, 5 Jan 2009 13:48:38 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AEB3A6A32 for ; Mon, 5 Jan 2009 13:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 2y446o50RHNb for ; Mon, 5 Jan 2009 13:48:37 -0800 (PST) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 320573A67A1 for ; Mon, 5 Jan 2009 13:48:37 -0800 (PST) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id zt0H1a00G16AWCUA2xoRjy; Mon, 05 Jan 2009 21:48:25 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id zxoQ1a00D0UQ6dC8SxoQvR; Mon, 05 Jan 2009 21:48:25 +0000 From: "David Harrington" To: Date: Mon, 5 Jan 2009 16:48:22 -0500 Message-ID: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: Aclvf1RsABwaQ2n4S+2Gijv7s81Acg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Isms] WGLC: radius-usage-04 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, A few comments. 1) in section 1.4, we probably should not be discussing the TSM security model. The radius support is in the transport model, and a radius-supported transport model should work with any security model. How a security model is selected and how it sets the securityName is specific to the security model, not to radius-usage. 2) In section 2, it state sthat service authroization [authorizes] SNMP over a specific Transport Model. I believe that has been changed in radius-mgmt-auth to be a specific transport protection. 3) In section 2.3, would it be simpler to introduce the attributes first so we can eliminate all the redundant "refre to ... from the perspective ..." notes? Would it be simpler to elimiate the "from the perspective ... th euser is requesting ..." and simply start each example with "To request ... set the attributes with the values ..." s/to to/to/ 4) do we really need section 2.4, that says "here is stuff we don't discuss here"? 5) section 5 s/module/model/g Paragraph 3 and 4 can be made more succinct: "If the SNMPv1 or SNMPv2c Security Model is used, then securityname comes from the community name, as per RFC3584. If the User-based Security Model is selected, then securityName is determined using USM. This may not be what is expected when using an SNMP secure Transport Model with an external authentication service, such as RADIUS. Combining a secure transport with RADIUS authentication/authorization, and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED. See the coexistence section of [TMSM]." s/in tandem with/to supplement/ s/for any reason// s/as defined in [rfc3579]/as defined in "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) [RFC3579]/ Is this Informative or Normative? To follow the advice given here, one would need to know rfc3579. Hope this helps, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 5 14:03:05 2009 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 02E4C3A6A25; Mon, 5 Jan 2009 14:03:05 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FBC83A6A32 for ; Mon, 5 Jan 2009 14:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=0.591, 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 j-g8MCF0u2tD for ; Mon, 5 Jan 2009 14:03:02 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 0A6DE3A67A1 for ; Mon, 5 Jan 2009 14:03:01 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n05M2jsA023699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 17:02:45 -0500 (EST) Date: Mon, 05 Jan 2009 17:02:45 -0500 From: Jeffrey Hutzelman To: David Harrington , isms@ietf.org Message-ID: <1AA88AA52A5DBD618BAEFEFA@minbar.fac.cs.cmu.edu> In-Reply-To: <200901052148.n05LmSnN008157@grapenut.srv.cs.cmu.edu> References: <200901052148.n05LmSnN008157@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.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] WGLC: radius-usage-04 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Monday, January 05, 2009 04:48:22 PM -0500 David Harrington wrote: > s/as defined in [rfc3579]/as defined in "RADIUS (Remote Authentication > Dial In User Service) Support For Extensible Authentication Protocol > (EAP) [RFC3579]/ Or even "The Message-Authenticator (80) attribute [RFC3579] SHOULD be used with RADIUS messages that are described in this memo." And similarly, %s/The SNMP architecture, as described in RFC 3411 [RFC3411],/The SNMP architecture [RFC3411]/g > Is this Informative or Normative? To follow the advice given here, one > would need to know rfc3579. Yes, I believe this reference is normative in nature. So is the reference to RFC5080. On the other hand, the references to RFC4252 and to isms-secshell are both informative in nature. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 5 14:14:18 2009 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 E4ED23A685D; Mon, 5 Jan 2009 14:14:18 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618963A685D for ; Mon, 5 Jan 2009 14:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOUhLVQlNKOj for ; Mon, 5 Jan 2009 14:14:17 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 9D84F3A6809 for ; Mon, 5 Jan 2009 14:14:17 -0800 (PST) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id ztau1a01b0b6N64A7yE6lR; Mon, 05 Jan 2009 22:14:06 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id zyE41a0040UQ6dC8PyE5hZ; Mon, 05 Jan 2009 22:14:06 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , References: <200901052148.n05LmSnN008157@grapenut.srv.cs.cmu.edu> <1AA88AA52A5DBD618BAEFEFA@minbar.fac.cs.cmu.edu> Date: Mon, 5 Jan 2009 17:14:02 -0500 Message-ID: <014f01c96f82$ebbeee40$6905a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AclvgVjqM3W4vsZuTzyqEJw/GdzflAAAOaGw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1AA88AA52A5DBD618BAEFEFA@minbar.fac.cs.cmu.edu> Subject: Re: [Isms] WGLC: radius-usage-04 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, Thanks Jeff, for making me notice this additional point ... s/The SNMP Architecture/The RFC3411 Architecture/ (RFC3411 defines "An Architecture", not "The Architecture" for Describing SNMP Frameworks. This was a deliberate choice per consensus of the SNMPv3 WG.) I notice that I missed the closing quote in my suggested change for /as defined in [RFC3579]/ dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Monday, January 05, 2009 5:03 PM > To: David Harrington; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] WGLC: radius-usage-04 > > --On Monday, January 05, 2009 04:48:22 PM -0500 David Harrington > wrote: > > > s/as defined in [rfc3579]/as defined in "RADIUS (Remote > Authentication > > Dial In User Service) Support For Extensible Authentication Protocol > > (EAP) [RFC3579]/ > > Or even > > "The Message-Authenticator (80) attribute [RFC3579] SHOULD be > used with > RADIUS messages that are described in this memo." > > And similarly, > > %s/The SNMP architecture, as described in RFC 3411 > [RFC3411],/The SNMP > architecture [RFC3411]/g > > > > > > Is this Informative or Normative? To follow the advice > given here, one > > would need to know rfc3579. > > Yes, I believe this reference is normative in nature. So is > the reference > to RFC5080. > > On the other hand, the references to RFC4252 and to > isms-secshell are both > informative in nature. > > -- Jeff > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 6 09:07:03 2009 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 5C4113A6807; Tue, 6 Jan 2009 09:07:03 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3B33A6807 for ; Tue, 6 Jan 2009 09:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v776aZCFS5Qr for ; Tue, 6 Jan 2009 09:07:01 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7F5413A63D2 for ; Tue, 6 Jan 2009 09:07:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,339,1228089600"; d="scan'208";a="126891425" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2009 17:06:48 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n06H6lHO021068; Tue, 6 Jan 2009 09:06:47 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n06H6kJu013602; Tue, 6 Jan 2009 17:06:47 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jan 2009 09:06:47 -0800 Received: from 10.21.119.134 ([10.21.119.134]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Tue, 6 Jan 2009 17:06:25 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 06 Jan 2009 09:05:51 -0800 From: kaushik To: David Harrington , Message-ID: Thread-Topic: [Isms] WGLC: radius-usage-04 Thread-Index: Aclvf1RsABwaQ2n4S+2Gijv7s81AcgAobKOi In-Reply-To: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> Mime-version: 1.0 X-OriginalArrivalTime: 06 Jan 2009 17:06:47.0163 (UTC) FILETIME=[28730CB0:01C97021] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3186; t=1231261607; x=1232125607; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Isms]=20WGLC=3A=20radius-usage-04 |Sender:=20; bh=RisUfI/He8DFwF5RZviFdxKZUdBT1SnqQfAdBvQbKvg=; b=m5RVD0Dh3tQoQfdgdqjoACmfEU9qLFPMZn5YSWvW40M3Duw69/zK7XPmAi wd+P3QsHmj3H/FHtX+kvPZ1gAWScU2JebXWagm//7KZWOnKpZf3bToHNbQwq FZf0km+fX3FBn73vkqPG59GR/B6NCZ77OLci/luJgwdbV2X5K2Njc=; Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Isms] WGLC: radius-usage-04 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 David, Thanks for your comments. Please find my reply inline. On 1/5/09 1:48 PM, "David Harrington" wrote: > Hi, > > A few comments. > > 1) in section 1.4, we probably should not be discussing the TSM > security model. The radius support is in the transport model, and a > radius-supported transport model should work with any security model. > How a security model is selected and how it sets the securityName is > specific to the security model, not to radius-usage. Section 1.4 is introductory text to provide the broad context for transport based security for SNMP, it references the existing work being done in the WG (transport subsystem, transport security model, ssh transport model). The securityName text was to indicate the flow of RADIUS userName attribute to & from the RADIUS layer up to the security model. > > 2) In section 2, it state sthat service authroization [authorizes] > SNMP over a specific Transport Model. I believe that has been changed > in radius-mgmt-auth to be a specific transport protection. You are right. That text needs to be updated. > > 3) In section 2.3, would it be simpler to introduce the attributes > first so we can eliminate all the redundant "refre to ... from the > perspective ..." notes? > > Would it be simpler to elimiate the "from the perspective ... th euser > is requesting ..." and simply start each example with "To request ... > set the attributes with the values ..." > > s/to to/to/ > > 4) do we really need section 2.4, that says "here is stuff we don't > discuss here"? I think it is useful to indicate that user authz is out of scope since the RADIUS mgmt authz has mechanisms that provide both service and user authz and this specification describes usage of service authorization. Regards, kaushik > > 5) section 5 > s/module/model/g > > Paragraph 3 and 4 can be made more succinct: > "If the SNMPv1 or SNMPv2c Security Model is used, then securityname > comes from the community name, as per RFC3584. If the User-based > Security Model is selected, then securityName is determined using USM. > This may not be what is expected when using an SNMP secure Transport > Model with an external authentication service, such as RADIUS. > > Combining a secure transport with RADIUS authentication/authorization, > and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED. > See the coexistence section of [TMSM]." > > s/in tandem with/to supplement/ > s/for any reason// > > s/as defined in [rfc3579]/as defined in "RADIUS (Remote Authentication > Dial In User Service) Support For Extensible Authentication Protocol > (EAP) [RFC3579]/ > Is this Informative or Normative? To follow the advice given here, one > would need to know rfc3579. > > Hope this helps, > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > 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 Jan 6 11:22:12 2009 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 476A43A6848; Tue, 6 Jan 2009 11:22:12 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA013A6848 for ; Tue, 6 Jan 2009 11:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.883, 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 4QhoQCLpikbt for ; Tue, 6 Jan 2009 11:22:09 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id E0BC83A67F3 for ; Tue, 6 Jan 2009 11:22:08 -0800 (PST) Received: (qmail 10120 invoked from network); 6 Jan 2009 14:21:51 -0500 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 6 Jan 2009 14:21:51 -0500 From: "David B. Nelson" To: References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> Date: Tue, 6 Jan 2009 14:21:36 -0500 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: Aclvf1RsABwaQ2n4S+2Gijv7s81AcgArql4g In-Reply-To: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> Subject: Re: [Isms] WGLC: radius-usage-04 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 Dave Harrington writes... > The radius support is in the transport model, and a > radius-supported transport model should work with any > security model. *Any* security model? Surely not the User-based Security Model (USM). I think it is reasonable to assert that RADIUS SHOULD work with the Transport Subsystem and the Transport Security Model. > How a security model is selected and how it sets the securityName > is specific to the security model, not to radius-usage. Yes, but as I indicated in another reply, the assumptions around mapping of authenticated user identities for the purpose of service authorization are of consequence to the RADIUS community. > 2) In section 2, it states that service authorization [authorizes] > SNMP over a specific Transport Model. I believe that has been changed > in radius-mgmt-auth to be a specific transport protection. So, we could change: Service authorization allows a RADIUS server to authorize an authenticated principal to use SNMP over a specific secure Transport Model. to read: Service authorization allows a RADIUS server to authorize an authenticated principal to use SNMP over a specific level of transport protection. > 3) In section 2.3, would it be simpler to introduce the attributes > first so we can eliminate all the redundant "refre to ... from the > perspective ..." notes? Well, Section 2.* is a general operational overview discussion. Editorially speaking, it's convenient to discuss the general concepts before the gory details. Having said that, I agree that the formal forward reference "Refer to [I-D.ietf-radext-management-authorization] for a detailed description of these attributes." could simply be eliminated. > Would it be simpler to eliminate the "from the perspective ... the user > is requesting ..." and simply start each example with "To request ... > set the attributes with the values ..." Yes, we could do something like that, with the caveat that there are request and response semantics that need to be listed separately. > s/to to/to/ I don't see this immediately, but I'll search for it. > 5) section 5 > s/module/model/g :-) > Paragraph 3 and 4 can be made more succinct: > "If the SNMPv1 or SNMPv2c Security Model is used, then securityname > comes from the community name, as per RFC3584. If the User-based > Security Model is selected, then securityName is determined using USM. > This may not be what is expected when using an SNMP secure Transport > Model with an external authentication service, such as RADIUS. OK. > Combining a secure transport with RADIUS authentication/authorization, > and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED. > See the coexistence section of [TMSM]." OK. > s/in tandem with/to supplement/ > s/for any reason// OK. > s/as defined in [rfc3579]/as defined in "RADIUS (Remote Authentication > Dial In User Service) Support For Extensible Authentication Protocol > (EAP) [RFC3579]/ Umm. This may be obviated by another comment from Jeff Hutzelman, but I've seen other RFCs that don't preface the reference designator {RFCnnnn] with the fully spelled out document name. Of course, this is a style issue, more in the domain of the RFC Editor. > Is this Informative or Normative? To follow the advice given here, one > would need to know rfc3579. We can follow the suggestions that Jeff offers on Normative vs. Informative. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 6 11:33:06 2009 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 18F603A690D; Tue, 6 Jan 2009 11:33:06 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6553A690D for ; Tue, 6 Jan 2009 11:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UVCslV+b0Br for ; Tue, 6 Jan 2009 11:33:04 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id DD92D3A6900 for ; Tue, 6 Jan 2009 11:33:03 -0800 (PST) Received: (qmail 8816 invoked from network); 6 Jan 2009 13:32:49 -0500 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 6 Jan 2009 13:32:49 -0500 From: "David B. Nelson" To: References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> Date: Tue, 6 Jan 2009 13:32:34 -0500 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: Aclvf1RsABwaQ2n4S+2Gijv7s81AcgAobKOiAAKoESA= In-Reply-To: Subject: Re: [Isms] WGLC: radius-usage-04 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 Kaushik writes... > The securityName text was to indicate the flow of RADIUS > username attribute to & from the RADIUS layer up to the > security model. Yes, there are certain expectations within the RADIUS community about how User-Name attributes are used in authentication, authorization and service provisioning. Generally speaking, session authorization is bound to the user's identity. This may or may not be the case with SNMP, because of the potential for mapping between the RADIUS User-Name and the SNMP securityName. I think it's important to call attention that feature. The authors assume that this document has two (possibly overlapping) audiences: the RADIUS community and the SNMP community. The reason for the introductory text is to expose each community to enough of the context commonly held by the other community so that understanding is universal. > I think it is useful to indicate that user authz is out of scope > since the RADIUS mgmt authz has mechanisms that provide both service > and user authz and this specification describes usage of service > authorization. This is another attempt at creating shared context. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 6 13:08:58 2009 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 D50EF3A6893; Tue, 6 Jan 2009 13:08:58 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68893A6893 for ; Tue, 6 Jan 2009 13:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.04 X-Spam-Level: X-Spam-Status: No, score=-7.04 tagged_above=-999 required=5 tests=[AWL=1.559, BAYES_00=-2.599, GB_I_LETTER=-2, 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 EJUgqUdSrRRo for ; Tue, 6 Jan 2009 13:08:56 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id BADB13A6452 for ; Tue, 6 Jan 2009 13:08:56 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n06L8emd021496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2009 16:08:41 -0500 (EST) Date: Tue, 06 Jan 2009 16:08:40 -0500 From: Jeffrey Hutzelman To: "David B. Nelson" , isms@ietf.org Message-ID: <814BDEDF75355A4C80242067@minbar.fac.cs.cmu.edu> In-Reply-To: <200901061922.n06JM2P1021251@toasties.srv.cs.cmu.edu> References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> <200901061922.n06JM2P1021251@toasties.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: jhutz@cmu.edu Subject: Re: [Isms] WGLC: radius-usage-04 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Tuesday, January 06, 2009 02:21:36 PM -0500 "David B. Nelson" wrote: > Dave Harrington writes... > >> The radius support is in the transport model, and a >> radius-supported transport model should work with any >> security model. > > *Any* security model? Surely not the User-based Security Model (USM). I > think it is reasonable to assert that RADIUS SHOULD work with the > Transport Subsystem and the Transport Security Model. Yes, _any_ security model. I should be able to use SSH transport with USM, and something reasonable should happen. Particularly, with respect to RADIUS, I think session authorization should happen in the transport regardless of what SNMP security model is used. >> s/as defined in [rfc3579]/as defined in "RADIUS (Remote Authentication >> Dial In User Service) Support For Extensible Authentication Protocol >> (EAP) [RFC3579]/ > > Umm. This may be obviated by another comment from Jeff Hutzelman, but > I've seen other RFCs that don't preface the reference designator > {RFCnnnn] with the fully spelled out document name. Of course, this is a > style issue, more in the domain of the RFC Editor. The style question here is one of whether reference designators are used as grammatical objects. In traditional print media, references are designated by a superscripted letter, number, or symbol, and are _never_ grammatical objects. Some people believe we should follow this rule in our documents, even though the designators are less unobtrusive; others believe it is fine to use them directly as grammatical objects. Personally I don't mind, as long as we are consistent. AFAIK the RFC-Editor doesn't have a preference for one style over the other; I've seen published documents using both. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 6 14:35:03 2009 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 BE5E53A69DF; Tue, 6 Jan 2009 14:35:03 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC45E3A69DF for ; Tue, 6 Jan 2009 14:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-1s5+vKqSKF for ; Tue, 6 Jan 2009 14:35:02 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id ADF1A3A69D2 for ; Tue, 6 Jan 2009 14:35:01 -0800 (PST) Received: (qmail 12704 invoked from network); 6 Jan 2009 16:34:47 -0500 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 6 Jan 2009 16:34:47 -0500 From: "David B. Nelson" To: "'Jeffrey Hutzelman'" References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> <200901061922.n06JM2P1021251@toasties.srv.cs.cmu.edu> <814BDEDF75355A4C80242067@minbar.fac.cs.cmu.edu> Date: Tue, 6 Jan 2009 16:34:32 -0500 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: AclwQvSPUOEglYp/Tpa/xagpGrlz7QAAcwvg In-Reply-To: <814BDEDF75355A4C80242067@minbar.fac.cs.cmu.edu> Cc: isms@ietf.org Subject: Re: [Isms] WGLC: radius-usage-04 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 > Yes, _any_ security model. I should be able to use SSH transport > with USM, and something reasonable should happen. Particularly, > with respect to RADIUS, I think session authorization should happen > in the transport regardless of what SNMP security model is used. Well, Jeff, unfortunately your "should" seems to me an expression of desired behavior as opposed to an expression of technical feasibility (as in my retirement nest egg "should" support me in my golden years). :-) In point of fact, I see no reasonable way to use RADIUS with USM, based on the architecture that we've agreed to in ISMS. Of course, all things are possible in software, so with a different architecture something might work out. The specific issues with USM are that it has inherent dependencies on the credentials being stored in the local configuration data-store and it conflates authentication with confidentiality in a way that RADIUS would be hard pressed to support. If you see a way clear of these impediments, I'd be curious to hear of it. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 6 14:53:18 2009 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 CB5FA3A681D; Tue, 6 Jan 2009 14:53:18 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094653A681D for ; Tue, 6 Jan 2009 14:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 jn6odIMt4KDM for ; Tue, 6 Jan 2009 14:53:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D7DBD3A67AD for ; Tue, 6 Jan 2009 14:53:11 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 514E7C002D; Tue, 6 Jan 2009 23:52:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mHQm3Pcnjddn; Tue, 6 Jan 2009 23:52:48 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9B00C0028; Tue, 6 Jan 2009 23:52:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5B6268DF598; Tue, 6 Jan 2009 23:52:47 +0100 (CET) Date: Tue, 6 Jan 2009 23:52:47 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20090106225247.GA9442@elstar.local> Mail-Followup-To: "David B. Nelson" , 'Jeffrey Hutzelman' , isms@ietf.org References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> <200901061922.n06JM2P1021251@toasties.srv.cs.cmu.edu> <814BDEDF75355A4C80242067@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] WGLC: radius-usage-04 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, Jan 06, 2009 at 04:34:32PM -0500, David B. Nelson wrote: > > Yes, _any_ security model. I should be able to use SSH transport > > with USM, and something reasonable should happen. Particularly, > > with respect to RADIUS, I think session authorization should happen > > in the transport regardless of what SNMP security model is used. > > Well, Jeff, unfortunately your "should" seems to me an expression of desired > behavior as opposed to an expression of technical feasibility (as in my > retirement nest egg "should" support me in my golden years). :-) > > In point of fact, I see no reasonable way to use RADIUS with USM, based on > the architecture that we've agreed to in ISMS. Of course, all things are > possible in software, so with a different architecture something might work > out. The specific issues with USM are that it has inherent dependencies on > the credentials being stored in the local configuration data-store and it > conflates authentication with confidentiality in a way that RADIUS would be > hard pressed to support. I believe Jeff is talking about the scenario USM over SSH where RADIUS would do the SSH session authentication and not really care about any of the USM specifics. /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 Jan 6 19:03:03 2009 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 EF3B33A6988; Tue, 6 Jan 2009 19:03:02 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639B33A694C for ; Tue, 6 Jan 2009 19:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=1.146, 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 2LTQO8KvmhzH for ; Tue, 6 Jan 2009 19:03:01 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 7A7D83A6988 for ; Tue, 6 Jan 2009 19:03:01 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 0Jkk1b00a0vyq2s54T2pWG; Wed, 07 Jan 2009 03:02:49 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA05.westchester.pa.mail.comcast.net with comcast id 0T2A1b00T4H2mdz3RT2Bth; Wed, 07 Jan 2009 03:02:12 +0000 From: "Dave Nelson" To: References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com><200901061922.n06JM2P1021251@toasties.srv.cs.cmu.edu><814BDEDF75355A4C80242067@minbar.fac.cs.cmu.edu> <20090106225247.GA9442@elstar.local> Date: Tue, 6 Jan 2009 22:02:51 -0500 Message-ID: <444BE200AF6D43499FCF4882B9B59277@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclwUYrLUx8T+7IbSeuYXxQuO/KjXAAIQgCw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20090106225247.GA9442@elstar.local> Subject: Re: [Isms] WGLC: radius-usage-04 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 Juergen Schoenwaelder writes... > I believe Jeff is talking about the scenario USM over SSH where > RADIUS would do the SSH session authentication and not really > care about any of the USM specifics. I'd have to think a bit about what this means. In the case of the USM, the packet-by-packet authentication is performed in the Security Model using pre-shared keys, tied to a locally stored username. In the case of TM with TSM, the SSHTM provides the authentication of the packet stream, because it's a protected transport session. We have specified a way associate the identity known to the TM and the TSM by mapping and caching. If we use SSH with USM, there is certainly a protected transport session, but it's in no way tied to the Security Model (USM), and there is certainly no tie in to any Access Control Model that might be in use. I'm having difficulty understanding now the totally unrelated identities, the one tied to the SSH session and the one tied to the USM, provided a reasonable and secure solution. Perhaps I simply haven't thought about in enough, but I just don't get it. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 6 23:49:53 2009 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 746A03A69F1; Tue, 6 Jan 2009 23:49:53 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31553A69F1 for ; Tue, 6 Jan 2009 23:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 UigFoO8JxGNC for ; Tue, 6 Jan 2009 23:49:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ED50A3A63EB for ; Tue, 6 Jan 2009 23:49:50 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E5D3C0021; Wed, 7 Jan 2009 08:49:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HSwxfjuuRU6t; Wed, 7 Jan 2009 08:49:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD84FC0019; Wed, 7 Jan 2009 08:49:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 23A6A8DF82A; Wed, 7 Jan 2009 08:49:31 +0100 (CET) Date: Wed, 7 Jan 2009 08:49:31 +0100 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090107074931.GA9700@elstar.local> Mail-Followup-To: Dave Nelson , isms@ietf.org References: <20090106225247.GA9442@elstar.local> <444BE200AF6D43499FCF4882B9B59277@NEWTON603> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <444BE200AF6D43499FCF4882B9B59277@NEWTON603> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] WGLC: radius-usage-04 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, Jan 06, 2009 at 10:02:51PM -0500, Dave Nelson wrote: > Juergen Schoenwaelder writes... > > > I believe Jeff is talking about the scenario USM over SSH where > > RADIUS would do the SSH session authentication and not really > > care about any of the USM specifics. > > I'd have to think a bit about what this means. > > In the case of the USM, the packet-by-packet authentication is performed in > the Security Model using pre-shared keys, tied to a locally stored username. > > In the case of TM with TSM, the SSHTM provides the authentication of the > packet stream, because it's a protected transport session. We have > specified a way associate the identity known to the TM and the TSM by > mapping and caching. > > If we use SSH with USM, there is certainly a protected transport session, > but it's in no way tied to the Security Model (USM), and there is certainly > no tie in to any Access Control Model that might be in use. I'm having > difficulty understanding now the totally unrelated identities, the one tied > to the SSH session and the one tied to the USM, provided a reasonable and > secure solution. Perhaps I simply haven't thought about in enough, but I > just don't get it. I am not discussing here to what extend this is reasonable/desirable, I understand Jeff's comment from an architectural point of view. This combination is more like an SSH tunnel and RADIUS in this case is used to determine whether the tunnel can be established. I think we already agreed that RADIUS for now does not tie into SNMP access control since doing so is outside of our charter. SNMP's access control decision is based on identity determined by the SNMP security model used to handle the message. /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 Jan 7 05:42:14 2009 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 7B6F828C0DE; Wed, 7 Jan 2009 05:42:14 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55E228C0DE for ; Wed, 7 Jan 2009 05:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=1.105, 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 dem0divX2A4a for ; Wed, 7 Jan 2009 05:42:11 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id A0F8E3A68D4 for ; Wed, 7 Jan 2009 05:42:11 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 0beq1b0060ldTLk58dhzPY; Wed, 07 Jan 2009 13:41:59 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA04.westchester.pa.mail.comcast.net with comcast id 0dhz1b0024H2mdz3QdhzeH; Wed, 07 Jan 2009 13:41:59 +0000 From: "Dave Nelson" To: References: <20090106225247.GA9442@elstar.local> <444BE200AF6D43499FCF4882B9B59277@NEWTON603> <20090107074931.GA9700@elstar.local> Date: Wed, 7 Jan 2009 08:42:02 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclwnH64dxlqFqjJSgqnuMA3V+AWkwALmqUw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20090107074931.GA9700@elstar.local> Subject: Re: [Isms] WGLC: radius-usage-04 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 Juergen Schoenwaelder writes... > I am not discussing here to what extend this is reasonable/desirable... Well, OK. I guess I won't waste very much time discussing desirable but unreasonable things. :-) > I understand Jeff's comment from an architectural point of view. As do I. From an architectural point of view what Jeff suggests ought to be capable of working, in a reasonable and secure fashion. I think perhaps we disagree on what constitutes reasonable and secure, and whether the architecture we've devised here in ISMS works (well) in that particular configuration. > This combination is more like an SSH tunnel and RADIUS in this case > is used to determine whether the tunnel can be established. Yes. I agree with that. Does that automatically imply that the user at the end of the tunnel is authorized to use SNMP? Maybe. If the SNMP engine is bound so tightly to SSH that the tunnel is the only way to access SNMP, you might accomplish that goal. Otherwise, there are "two sets of books" used for authentication -- one in the RADIUS server and a second one in USM's local configuration data-store. They could be different, or they could appear to be similar, e.g. "dave" in RADIUS might be a different persona than "dave" in USM. In addition to that, you need to account for the provisioning of the shared keys, unless you are using noAuth noPriv, in which case you are using the "null security" of USM, and it's a degenerate, non-interesting case. > I think we already agreed that RADIUS for now does not tie into SNMP > access control since doing so is outside of our charter. We did agree to that. Some of us strongly argued that it was a silly thing to agree to, but were told that it was necessary to focus on one thing at a time, and that we would likely cycle back to that work via a re-charter once the base workload was completed. I have always said, and repeat here, that authentication and confidentiality are not much good without (granular) authorization, i.e. access control. While it's formally out of scope, the problem hasn't gone away. > SNMP's access control decision is based on identity determined by > the SNMP security model used to handle the message. Yes, and if the identity determined by the security models is completely dissociated from the identity authenticated by the RADIUS server, it's a very broken architecture, IMO. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 06:13:50 2009 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 3D4C328C16D; Wed, 7 Jan 2009 06:13:50 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3413528C179 for ; Wed, 7 Jan 2009 06:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGpzZy2rEdP6 for ; Wed, 7 Jan 2009 06:13:47 -0800 (PST) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 40EBB28C10C for ; Wed, 7 Jan 2009 06:13:47 -0800 (PST) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 0bRJ1b00A0x6nqcA2eDbLh; Wed, 07 Jan 2009 14:13:35 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id 0eDY1b00H0UQ6dC8YeDZan; Wed, 07 Jan 2009 14:13:34 +0000 From: "David Harrington" To: , "'Dave Nelson'" References: <20090106225247.GA9442@elstar.local><444BE200AF6D43499FCF4882B9B59277@NEWTON603> <20090107074931.GA9700@elstar.local> Date: Wed, 7 Jan 2009 09:13:31 -0500 Message-ID: <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AclwnIGzsZMJLgqjSPODkJxsFWQXoAAK+MWA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20090107074931.GA9700@elstar.local> Cc: isms@ietf.org Subject: Re: [Isms] WGLC: radius-usage-04 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, > > If we use SSH with USM, there is certainly a protected > transport session, > > but it's in no way tied to the Security Model (USM), and > there is certainly > > no tie in to any Access Control Model that might be in use. That is correct, architecturally. There are two different situations requiring authn and authz. > > I am not discussing here to what extend this is reasonable/desirable, > I understand Jeff's comment from an architectural point of view. This > combination is more like an SSH tunnel and RADIUS in this case is used > to determine whether the tunnel can be established. The first situation is authz for craeting a asecure transport session, e.g., instantiating an SSH "snmp" subsystem. SSH can use RADIUS to perform this, if desired. Or SSH can use some other mechanism to perform authentication, and some other method to determine whether the authenticated user is authorized to instantiate the "snmp" subsystem. I think this is comparable to SSH using AAA to determine whether to instantiate a shell. The second situation of authn/z is SNMP-specific. An SNMP security model performs the authentication and creates a securityName that is then used for SNMP access control. This is comparable to a UNIX system determining which files a user can read/write/execute. These two cases of authn/z might use totally different mechanisms: If an SNMPv1 message is delivered over SSH, the SNMPv1 message processing model will select the SNMPv1 security model, and set securityName based on the community. For SNMPv2c messages, the SNMPv2c security model will be chosen. If an SNMPv3 message is delivered over SSH to the SNMPv3 message processing model, and the SNMPv3 security parameters in the message said SecurityModel=USM, then USM would be called to authenticate based on the credentials that are stored locally. USM would set a securityName accordingly. That all should work just fine. So, even if RADIUS provides the authn/z services for SSH, the determination of the security model is handled by the message processing model. The two cases might be integrated: If an SNMPv3 message is delivered over SSH to the SNMPv3 message processing model, and the SNMPv3 security parameters in the message said SecurityModel=TSM, then TSM would be called. TSM would set a securityName based on the values of tmStateReference. If the Transport Model has set the values in tmStateReference based on values received from SSH, that happen to be based on RADIUS authn/z, that should work just fine as well. -- The point is that the Transport Model does not get to make the decision about which security model is called. Period. The determination of which security model to use is the job of the message processing model. A transport model should be able to transport any version of SNMP message (including versions not yet defined, and proprietary message formats) and deliver that message to the dispatcher (which will send it to the corresponding message processing model). The Coexistence section of TMSM discusses the fact that you should not make assumptions that securityName will be based on the identity used by the transport security protocol. The RADIUS server CAN make assumptions about the authn/z used for initiating the subsystem (case 1). The RADIUS server should make no such assumptions about the SNMP-internal authn/authz used for application access control purposes (case 2). > > I think we already agreed that RADIUS for now does not tie into SNMP > access control since doing so is outside of our charter. SNMP's access > control decision is based on identity determined by the SNMP security > model used to handle the message. > I think the "for now" is important here. Our task to this point has been to define how RADIUS can be used for case 1 - how can RADIUS be used to create a secure transport session for SNMP when using transport security, such as SSH. (RADIUS Usage for SNMP Transport Models) Once we complete that work, we can start to work on defining how RADIUS can be used to provide authn/z services for case 2. (RADIUS Usage for SNMP Access Control). dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 07:30:07 2009 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 B030D3A69CA; Wed, 7 Jan 2009 07:30:07 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986083A69CA for ; Wed, 7 Jan 2009 07:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=1.067, 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 yyfy6Ha3ll28 for ; Wed, 7 Jan 2009 07:30:05 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 7C3C33A694D for ; Wed, 7 Jan 2009 07:30:05 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 0dCL1b0040Fqzac53fVt9C; Wed, 07 Jan 2009 15:29:53 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 0fVq1b00N4H2mdz3UfVqKl; Wed, 07 Jan 2009 15:29:50 +0000 From: "Dave Nelson" To: References: <20090106225247.GA9442@elstar.local><444BE200AF6D43499FCF4882B9B59277@NEWTON603> <20090107074931.GA9700@elstar.local> <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> Date: Wed, 7 Jan 2009 10:29:56 -0500 Message-ID: <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclwnIGzsZMJLgqjSPODkJxsFWQXoAAK+MWAAAQB+pA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> Subject: Re: [Isms] WGLC: radius-usage-04 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 David Harrington writes... > The first situation is authz for craeting a asecure transport session, > e.g., instantiating an SSH "snmp" subsystem. Yes. > The second situation of authn/z is SNMP-specific. An SNMP security > model performs the authentication and creates a securityName that > is then used for SNMP access control. This is comparable to a UNIX > system determining which files a user can read/write/execute. Well, somewhat comparable. UNIX also has authentication (login) and uses the results of that to make access control decisions. There is an inherent binding of the authentication to the subsequent authorization(s). SSH might pass a username to the UNIX shell, but the shell still needs to perform its own authentication (login) according to locally configured policy. The shell *might* trust that the username passed by SSH is the same persona as that same name found in the local (or remote) authentication database, if it is so configured. > So, even if RADIUS provides the authn/z services for SSH, the > determination of the security model is handled by the message > processing model. Umm, yes... but let's try to remember why we are doing this. The reason operators use AAA is that maintaining disparate user databases across multiple devices is fraught with difficulty. We need to assume that if RADIUS is "in play" in a given deployment, that the operator has decided that the benefits of centralized AAA are valuable, and thus we should not be introducing use cases in which AAA needs to be supplemented with auxiliary user identity databases. That's counterproductive to the effort. Another way of saying this is that we can ask three questions about any architectural scenario: (1) Would it work? (2) Would any operator be likely to want to use it? (3) Would it be secure? I'm attempting to answer Questions (2) and (3). > The point is that the Transport Model does not get to make the > decision about which security model is called. Period. The > determination of which security model to use is the job of the > message processing model. Yes, and this gives rise to combinations that pass Question (1) but not Question (2) and maybe not Question (3). > The Coexistence section of TMSM discusses the fact that you should > not make assumptions that securityName will be based on the identity > used by the transport security protocol. Which, IMO, is equivalent to saying you shouldn't assume that the system will be secure. :-) I admit that I'm taking a very AAA-centric view here, but I think that's perfectly reasonable in discussing the RADIUS Usage draft. > The RADIUS server CAN make assumptions about the authn/z used for > initiating the subsystem (case 1). The RADIUS server should make no > such assumptions about the SNMP-internal authn/authz used for > application access control purposes (case 2). Right. That's an issue, however, it's a bit off the point of this particular thread. My original post objected to the notion that RADIUS and SNMP transport-based security (TM/TSM/SSHTM) could be reasonably used in conjunction with USM. If I understand you correctly, you are suggesting that SNMP secure transports (TM/SSHTM) can be used independent of SNMP transport-based security (TSM). That's probably correct. OTOH, we've never spent time discussing such usages, and I'm still uncomfortable that the may be some unpleasant surprises in store. > Our task to this point has been to define how RADIUS can be used > for case 1 - how can RADIUS be used to create a secure transport > session for SNMP when using transport security, such as SSH. > (RADIUS Usage for SNMP Transport Models) When using transport security, but maybe not using the transport security model? When you say transport security, you really mean secure transport? > Once we complete that work, we can start to work on defining how > RADIUS can be used to provide authn/z services for case 2. (RADIUS > Usage for SNMP Access Control). OK, fair enough. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 10:30:13 2009 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 2A38828C129; Wed, 7 Jan 2009 10:30:13 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB5528C119 for ; Wed, 7 Jan 2009 10:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=0.102, 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 TVMJtfaYBgSv for ; Wed, 7 Jan 2009 10:30:11 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 337B928C116 for ; Wed, 7 Jan 2009 10:30:11 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA07.westchester.pa.mail.comcast.net with comcast id 0gsH1b00h17dt5G57iVynK; Wed, 07 Jan 2009 18:29:58 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 0iVx1b00M4H2mdz3ZiVxJg; Wed, 07 Jan 2009 18:29:57 +0000 From: "Dave Nelson" To: References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> Date: Wed, 7 Jan 2009 13:30:01 -0500 Message-ID: <6E823295705D46C08DD4FE529E6F69A1@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aclvf1RsABwaQ2n4S+2Gijv7s81AcgBdilAA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> Subject: Re: [Isms] WGLC: radius-usage-04 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 David Harrington writes... > 4) do we really need section 2.4, that says "here is stuff we don't > discuss here"? Well, I guess this represents a lingering level of distrust (at least on the part of this author) that the WG will eventually get around to addressing this important issue. With the caveat that ISMS anticipates a re-charter discussion that would bring this issue into scope and that we would expect to see a companion "RADIUS Usage for SNMP Access Control Models" document, yes, this section can be removed. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 11:00:10 2009 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 49B523A6932; Wed, 7 Jan 2009 11:00:10 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C5328C116 for ; Wed, 7 Jan 2009 11:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=1.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw3Mc+qXKIZL for ; Wed, 7 Jan 2009 11:00:07 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 114493A684A for ; Wed, 7 Jan 2009 11:00:06 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 0bCA1b0030Fqzac53izuRX; Wed, 07 Jan 2009 18:59:54 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 0izo1b00N4H2mdz3Uizp7e; Wed, 07 Jan 2009 18:59:49 +0000 From: "Dave Nelson" To: References: <20090106225247.GA9442@elstar.local><444BE200AF6D43499FCF4882B9B59277@NEWTON603><20090107074931.GA9700@elstar.local><02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> Date: Wed, 7 Jan 2009 13:59:55 -0500 Message-ID: <2B473E36C58C4A6CAB8B0830D3446398@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclwnIGzsZMJLgqjSPODkJxsFWQXoAAK+MWAAAQB+pAABiTPsA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> Subject: Re: [Isms] WGLC: radius-usage-04 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 Based on the discussion so far, I'd like to propose the following revisions to the draft: Old: 2. RADIUS Usage for SNMP Transport Models There are three ways in which RADIUS may be used by SNMP Transport Models. These include (a) user authentication, (b) service authorization and (c) access control authorization. The first two items are discussed in detail in this memo, while the third item is a topic of current research, and beyond the scope of this document. This document describes the way in which RADIUS attributes and messages are applied to the specific application area of SNMP Transport Models. New: 2. RADIUS Usage for SNMP Transport Models There are three ways in which RADIUS may be used by SNMP. These include (a) user authentication, (b) service authorization and (c) access control authorization. User authentication and service authorization via RADIUS are undertaken by the Transport Model, and are discussed in detail in this memo. Access control would be undertaken by the Message Processing Model and an Access Control Model, is a topic of current research, and is beyond the scope of this document. This document describes the way in which RADIUS attributes and messages are applied to the specific application area of SNMP Transport Models. Also in Section 2: Old: Service authorization allows a RADIUS server to authorize an authenticated principal to use SNMP over a specific secure Transport Model. This memo describes mechanisms by which such information can be requested from a RADIUS server and enforced within the NAS. The SNMP architecture, as described in RFC 3411 [RFC3411], does not make a distinction between user authentication and service authorization. In the case of existing, deployed security models, such as the User- based Security Model (USM), this distinction is not significant. For the SNMP Transport Models and the SNMP Transport Security Model (TSM), this distinction is relevant and important. New: Service authorization allows a RADIUS server to authorize an authenticated principal to use SNMP over a specific secure Transport Model. This memo describes mechanisms by which such information can be requested from a RADIUS server and enforced within the NAS. The SNMP architecture, as described in RFC 3411 [RFC3411], does not make a distinction between user authentication and service authorization. In the case of existing, deployed security models, such as the User- based Security Model (USM), this distinction is not significant. For SNMP Transport Models, this distinction is relevant and important. Remove the following paragraph: Data object access control authorization in SNMP is handled by the Access Control Subsystem (ACS), instantiated as various Access Control Models. The SNMP architecture, as described in RFC 3411 [RFC3411], explicitly mandates the separation of authentication and authorization operations in order to retain modularity of the SNMP system. The Abstract Service Interface (ASI) of the ACS uses method- independent parameters, including securityName, to determine access control rights. A detailed description of how an Access Control Model (ACM) might utilize the services of a RADIUS client to obtain access control policy information is a topic of current research, and beyond the scope of this document. In Section 2.2: Old: A NAS that is compliant to this specification, MUST treat any RADIUS Access-Accept message that provisions a transport protocol (e.g. SSH) that cannot be provided, and/or application service (e.g. SNMP) that cannot be provided over that transport, as if an Access-Reject message had been received instead. The RADIUS Service-Type attribute is the primary indicator of the service being provisioned, although other attributes may also convey service provisioning information. Specific attributes for use with SNMP Transport Models are recommended in this document. New: A NAS that is compliant to this specification, MUST treat any RADIUS Access-Accept message that provisions a level of transport protection (e.g. SSH) that cannot be provided, and/or application service (e.g. SNMP) that cannot be provided over that transport, as if an Access- Reject message had been received instead. The RADIUS Service-Type Attribute is the primary indicator of the service being provisioned, although other attributes may also convey service provisioning information. In Section 2.3: Old: RADIUS servers compliant to this specification SHOULD use RADIUS service provisioning attributes, as described herein, to specify SNMP access over a secure transport protocol. Such RADIUS servers MAY use RADIUS hint attributes included in the Access-Request message, as described herein, in determining what, if any, service to provision. New: RADIUS servers compliant to this specification SHOULD use RADIUS service provisioning attributes, as described herein, to specify SNMP access over a secure transport. Such RADIUS servers MAY use RADIUS hint attributes included in the Access-Request message, as described herein, in determining what, if any, service to provision. Old: The following RADIUS attributes SHOULD be used, as hint attributes included in the Access-Request message to signal use of SNMP over a secure transport (i.e. authPriv) to the RADIUS server: 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of Integrity- Confidentiality-Protection. Refer to [I-D.ietf-radext-management-authorization] for a detailed description of these attributes. From the perspective of the RADIUS Server, these attribute and value pairs indicate that the user is requesting to use SNMP over an SNMP secure Transport Model. New: The following RADIUS attributes SHOULD be used, as hint attributes included in the Access-Request message to signal use of SNMP over a secure transport (i.e. authPriv) to the RADIUS server: 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of Integrity- Confidentiality-Protection. Old: The following RADIUS attributes are used in an Access-Accept message to provision SNMP over a secure transport (i.e. authPriv): 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of Integrity- Confidentiality-Protection. Old: The following RADIUS attributes MAY be optionally used, to authorize use of SNMP without protection (i.e. authNoPriv): 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of No-Protection. Refer to [I-D.ietf-radext-management-authorization] for a detailed description of this attribute. From the perspective of the NAS, this attribute and value pair indicates that the user is authorized to use SNMP without a protected transport. New: The following RADIUS attributes MAY be optionally used, to authorize use of SNMP without protection (i.e. authNoPriv): 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of No-Protection. Old: The following RADIUS attributes are used to limit the extent of a secure transport session carrying SNMP traffic, in conjunction with an SNMP Transport Model: 1. Session-Timeout 2. Inactivity-Timeout. Refer to [RFC2865] for a detailed description of these attributes. From the perspective of the NAS, these attributes indicate session timeouts to be applied to the secure transport sessions. The Session-Timeout Attribute indicates the maximum number of seconds that a session may exist before it is unconditionally disconnected. The Inactivity-Timeout Attribute indicates the maximum number of seconds that a transport session may exist without any protocol activity (messages sent or received) before the session is disconnected. These timeouts are enforced by the NAS. New: The following RADIUS attributes are used to limit the extent of a secure transport session carrying SNMP traffic, in conjunction with an SNMP Transport Model: 1. Session-Timeout 2. Inactivity-Timeout. Refer to [RFC2865] for a detailed description of these attributes. The Session-Timeout Attribute indicates the maximum number of seconds that a session may exist before it is unconditionally disconnected. The Inactivity-Timeout Attribute indicates the maximum number of seconds that a transport session may exist without any protocol activity (messages sent or received) before the session is disconnected. These timeouts are enforced by the NAS. Remove the following section: 2.4. SNMP Access Control Authorization [I-D.ietf-radext-management-authorization] describes a RADIUS attribute that can be used for SNMP access control authorization, however, the details of how an SNMP Access Control Model, such as the View-based Access Control Model (VACM) [RFC3415], might utilize RADIUS authorization are a topic of current research, and beyond the scope of this document. In Section 5: Old: If the SNMP Message Processing Module selects the SNMPv1 or SNMPv2c Security Model as the security model to use (because the message is SNMPv1 or SNMPv2), then securityName comes from the community name, as per RFC3584. This may not be what is expected when using an SNMP secure Transport Model. It is NOT RECOMMENDED that a combination of a secure transport, RADIUS authentication/authorization, and the SNMPv1 and/or SNMPv2c community models be used together, as it necessitates the opening of an insecure access path within the Access Control Subsystem. If the SNMP User-based Security Model is selected (because the SNMPv3 message contains a msgSecurityModel=USM), then securityName is determined using USM (after performing USM authentication). This may not be what is expected when using an SNMP secure Transport Model with an external authentication service, such as RADIUS. USM entries for noAuthNoPriv access would allow messages utilizing USM to bypass the secure transport. New: If the SNMPv1 or SNMPv2c Security Model is used, then securityname comes from the community name, as per RFC3584. If the User-based Security Model is selected, then securityName is determined using USM. This may not be what is expected when using an SNMP secure Transport Model with an external authentication service, such as RADIUS. Combining a secure transport with RADIUS authentication/authorization, and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED. See the coexistence section of [TMSM]." (A specific section number reference would be nice here, too.) Old: There are good reasons to provision USM access in tandem with AAA- based access, however. New: There are good reasons to provision USM access to supplement AAA- based access, however. Old: The Message-Authenticator (80) attribute SHOULD be used with RADIUS messages that are described in this memo, as defined in [RFC3579]. New: The Message-Authenticator (80) attribute [RFC3579] SHOULD be used with RADIUS messages that are described in this memo." In Section 7: Move the following references from Section 7.1 Normative References to Section 7.2 Informative References: [I-D.ietf-isms-secshell] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for SNMP", draft-ietf-isms-secshell-12 (work in progress), October 2008. [I-D.ietf-isms-transport-security-model] Harrington, D. and W. Hardaker, "Transport Security Model for SNMP", draft-ietf-isms-transport-security-model-09 (work in progress), October 2008. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. Move the following references from Section 7.2 Informative References to Section 7.1 Normative References: [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 11:04:02 2009 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 A12A43A6A86; Wed, 7 Jan 2009 11:04:02 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB53E3A6A86 for ; Wed, 7 Jan 2009 11:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 yx1EA+7C+9S2 for ; Wed, 7 Jan 2009 11:04:00 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by core3.amsl.com (Postfix) with ESMTP id B16CA3A6843 for ; Wed, 7 Jan 2009 11:03:59 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so4151545mue.9 for ; Wed, 07 Jan 2009 11:03:45 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=S12aJMQYHc23aSBYzuQdDB0dv9n2593nIymoHpEaoyc=; b=K4sTCOtEC6jADuyYhBVOSxdk7nQd1LyK96H62EjN3vxOfFmGsMsfLcLci4TKBGBsRL JpWMT9/GGo+XMXr5mrd+O90Dw38NMhHAaJ++8qkkZADle7Jzo/FB0EkDAhjoVstOckgn GOWttRAhZfoQEDVmQagsqxgcF8zPs2kbQTj84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SA9SmZgKmeTvpUhrSc46LdWIH8PGOwKZO6gJfHKz2jQEdbhzsgbrbmEOxnkWV1I0V4 M8EL3Fn6pHjyQjIN3nN3MGbu+YkG0cxgMIEhI4bkBB+lLZL0jX0XNU2f1UYWiXRWD4xH U/Ft4QIZq9L83r4z02n68qEoXovjQWEFrR/Xg= Received: by 10.103.160.10 with SMTP id m10mr8409994muo.50.1231355025041; Wed, 07 Jan 2009 11:03:45 -0800 (PST) Received: by 10.103.52.1 with HTTP; Wed, 7 Jan 2009 11:03:44 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2009 14:03:44 -0500 From: "Ira McDonald" To: "Dave Nelson" , "Ira McDonald" In-Reply-To: <6E823295705D46C08DD4FE529E6F69A1@NEWTON603> MIME-Version: 1.0 Content-Disposition: inline References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> <6E823295705D46C08DD4FE529E6F69A1@NEWTON603> Cc: isms@ietf.org Subject: Re: [Isms] WGLC: radius-usage-04 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, With all due to respect to you SNMP expert folks. The "I" in "ISMS" stands for "Integrated". From my onlooker's perspective, Dave Nelson seems to be saying that there are some "miraculous security happens here" loose ends. Others seems to be saying "that's OK - because we could recharter ISMS". Not very comforting to operators who are all pragmatists at heart. While writing this, I just saw Dave's proposed changes to the draft - which all seem good to me. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music/High North Inc email: blueroofmusic@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Jan 7, 2009 at 1:30 PM, Dave Nelson wrote: > David Harrington writes... > >> 4) do we really need section 2.4, that says "here is stuff we don't >> discuss here"? > > Well, I guess this represents a lingering level of distrust (at least on the > part of this author) that the WG will eventually get around to addressing > this important issue. With the caveat that ISMS anticipates a re-charter > discussion that would bring this issue into scope and that we would expect > to see a companion "RADIUS Usage for SNMP Access Control Models" document, > yes, this section can be removed. > > > _______________________________________________ > 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 Jan 7 11:10:59 2009 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 E4FD03A68FE; Wed, 7 Jan 2009 11:10:59 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46253A68FE for ; Wed, 7 Jan 2009 11:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=0.996, 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 JqCMdGCv9g4c for ; Wed, 7 Jan 2009 11:10:58 -0800 (PST) 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 E6E3D3A6843 for ; Wed, 7 Jan 2009 11:10:57 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 0hgx1b01X0SCNGk52jAkgz; Wed, 07 Jan 2009 19:10:44 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 0jAh1b00T4H2mdz3VjAiU0; Wed, 07 Jan 2009 19:10:42 +0000 From: "Dave Nelson" To: References: <20090106225247.GA9442@elstar.local><444BE200AF6D43499FCF4882B9B59277@NEWTON603><20090107074931.GA9700@elstar.local><02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com><8992A2C542E14B50B6B969A054F75AB7@NEWTON603> <2B473E36C58C4A6CAB8B0830D3446398@NEWTON603> Date: Wed, 7 Jan 2009 14:10:45 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclwnIGzsZMJLgqjSPODkJxsFWQXoAAK+MWAAAQB+pAABiTPsAACgMtQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <2B473E36C58C4A6CAB8B0830D3446398@NEWTON603> Subject: Re: [Isms] WGLC: radius-usage-04 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 Ooops... two more nits: > Also in Section 2: > > Old: > > Service authorization allows a RADIUS server to authorize an > authenticated principal to use SNMP over a specific secure Transport > Model. This memo describes mechanisms by which such information can > be requested from a RADIUS server and enforced within the NAS. The > SNMP architecture, as described in RFC 3411 [RFC3411], does not make > a distinction between user authentication and service authorization. > In the case of existing, deployed security models, such as the User- > based Security Model (USM), this distinction is not significant. For > the SNMP Transport Models and the SNMP Transport Security Model > (TSM), this distinction is relevant and important. > > New: > > Service authorization allows a RADIUS server to authorize an > authenticated principal to use SNMP over a specific secure Transport In the line above s/specific secure Transport/secure Transport/ . > Model. This memo describes mechanisms by which such information can > be requested from a RADIUS server and enforced within the NAS. The > SNMP architecture, as described in RFC 3411 [RFC3411], does not make In the line above s/SNMP architecture, as described in RFC 3411 [RFC3411]/ SNMP architecture [RFC3411]/ . > a distinction between user authentication and service authorization. > In the case of existing, deployed security models, such as the User- > based Security Model (USM), this distinction is not significant. For > SNMP Transport Models, this distinction is relevant and important. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 11:55:31 2009 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 8A4CC3A689D; Wed, 7 Jan 2009 11:55:31 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88BE3A6996 for ; Wed, 7 Jan 2009 11:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F5wNAPwrDGX for ; Wed, 7 Jan 2009 11:55:30 -0800 (PST) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 207343A689D for ; Wed, 7 Jan 2009 11:55:30 -0800 (PST) Received: from 68-246-165-160.pools.spcsdns.net (68-246-165-160.pools.spcsdns.net [68.246.165.160]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n07JtAeg025855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 14:55:12 -0500 (EST) Date: Wed, 07 Jan 2009 14:55:10 -0500 From: Jeffrey Hutzelman To: Dave Nelson , isms@ietf.org Message-ID: <1FCEC84104FB08F4DD94C6BC@atlantis.pc.cs.cmu.edu> In-Reply-To: <200901071900.n07J00vT002822@raisinbran.srv.cs.cmu.edu> References: <20090106225247.GA9442@elstar.local> <444BE200AF6D43499FCF4882B9B59277@NEWTON603> <20090107074931.GA9700@elstar.local> <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> <200901071900.n07J00vT002822@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: jhutz@cmu.edu Subject: Re: [Isms] WGLC: radius-usage-04 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, January 07, 2009 01:59:55 PM -0500 Dave Nelson wrote: > Based on the discussion so far, I'd like to propose the following > revisions to the draft: All of these look good to me, with a couple of exceptions.... You message doesn't include the corresponding "New" for this: > Old: > > The following RADIUS attributes are used in an Access-Accept message > to provision SNMP over a secure transport (i.e. authPriv): > > 1. Service-Type with a value of Framed-Management. > 2. Framed-Management-Protocol with a value of SNMP. > 3. Management-Transport-Protection with a value of Integrity- > Confidentiality-Protection. I have no objection to this: > Combining a secure transport with RADIUS authentication/authorization, > and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED. > See the coexistence section of [TMSM]." But then I question whether we want to keep this: > There are good reasons to provision USM access to supplement AAA- > based access, however. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 12:14:04 2009 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 1BF523A6843; Wed, 7 Jan 2009 12:14:04 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B803A689D for ; Wed, 7 Jan 2009 12:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.966, 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 G7LE6-r5FNv1 for ; Wed, 7 Jan 2009 12:14:02 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 223963A677D for ; Wed, 7 Jan 2009 12:14:02 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 0eMW1b02F0SCNGk59kDpGp; Wed, 07 Jan 2009 20:13:49 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 0kDp1b0074H2mdz3VkDpCS; Wed, 07 Jan 2009 20:13:49 +0000 From: "Dave Nelson" To: References: <20090106225247.GA9442@elstar.local> <444BE200AF6D43499FCF4882B9B59277@NEWTON603> <20090107074931.GA9700@elstar.local> <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> <200901071900.n07J00vT002822@raisinbran.srv.cs.cmu.edu> <1FCEC84104FB08F4DD94C6BC@atlantis.pc.cs.cmu.edu> Date: Wed, 7 Jan 2009 15:13:53 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclxAdzLPMsEcg6nSKeT3Im8fABkKAAAMaDg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <1FCEC84104FB08F4DD94C6BC@atlantis.pc.cs.cmu.edu> Subject: Re: [Isms] WGLC: radius-usage-04 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 writes... > You message doesn't include the corresponding "New" for this: > >> Old: >> >> The following RADIUS attributes are used in an Access-Accept message >> to provision SNMP over a secure transport (i.e. authPriv): >> >> 1. Service-Type with a value of Framed-Management. >> 2. Framed-Management-Protocol with a value of SNMP. >> 3. Management-Transport-Protection with a value of Integrity- >> Confidentiality-Protection. Yeah, something is out of sequence. Let's try that again, shall we? Old: The following RADIUS attributes are used in an Access-Accept message to provision SNMP over a secure transport (i.e. authPriv): 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of Integrity- Confidentiality-Protection. Refer to [I-D.ietf-radext-management-authorization] for a detailed description of these attributes. From the perspective of the NAS, these attribute and value pairs indicate that the user is authorized to use SNMP using an SNMP secure Transport Model. New: The following RADIUS attributes are used in an Access-Accept message to provision SNMP over a secure transport (i.e. authPriv): 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMP. 3. Management-Transport-Protection with a value of Integrity- Confidentiality-Protection. The Old was actually the New, and the "real" Old had been omitted. Sorry. > I have no objection to this: > >> Combining a secure transport with RADIUS authentication/authorization, >> and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED. >> See the coexistence section of [TMSM]." > > But then I question whether we want to keep this: > >> There are good reasons to provision USM access to supplement AAA- >> based access, however. Yes, I think we do. This addresses a different issue. Combining a secure transport model with a non-TSM security model is indeed NOT RECOMMENDED. The text you question is a recommendation for operators to provision a non-AAA method of SNMP access. This is the analog of maintaining a local /etc/passwd file as a back-up to NIS, for situations when the remote authentication server is unreachable. This text recommends configuration of "pre-ISMS" mechanisms as a fall-back, in the case that an AAA server becomes unreachable for any period of time. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 13:31:18 2009 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 EF5AE3A689D; Wed, 7 Jan 2009 13:31:18 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1C13A689D for ; Wed, 7 Jan 2009 13:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, 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 04opNqtpNJVE for ; Wed, 7 Jan 2009 13:31:16 -0800 (PST) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 57E8E3A687C for ; Wed, 7 Jan 2009 13:31:16 -0800 (PST) Received: from 68-246-165-160.pools.spcsdns.net (68-246-165-160.pools.spcsdns.net [68.246.165.160]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n07LUvQh028930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 16:30:58 -0500 (EST) Date: Wed, 07 Jan 2009 16:30:56 -0500 From: Jeffrey Hutzelman To: Dave Nelson , isms@ietf.org Message-ID: <0B7929B2A179038D2D580765@atlantis.pc.cs.cmu.edu> In-Reply-To: <200901072013.n07KDraT019946@grapenut.srv.cs.cmu.edu> References: <20090106225247.GA9442@elstar.local> <444BE200AF6D43499FCF4882B9B59277@NEWTON603> <20090107074931.GA9700@elstar.local> <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> <200901071900.n07J00vT002822@raisinbran.srv.cs.cmu.edu> <1FCEC84104FB08F4DD94C6BC@atlantis.pc.cs.cmu.edu> <200901072013.n07KDraT019946@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: jhutz@cmu.edu Subject: Re: [Isms] WGLC: radius-usage-04 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, January 07, 2009 03:13:53 PM -0500 Dave Nelson wrote: > Jeffrey Hutzelman writes... > >> You message doesn't include the corresponding "New" for this: >> >>> Old: >>> >>> The following RADIUS attributes are used in an Access-Accept message >>> to provision SNMP over a secure transport (i.e. authPriv): >>> >>> 1. Service-Type with a value of Framed-Management. >>> 2. Framed-Management-Protocol with a value of SNMP. >>> 3. Management-Transport-Protection with a value of Integrity- >>> Confidentiality-Protection. > > Yeah, something is out of sequence. Let's try that again, shall we? > > Old: > > The following RADIUS attributes are used in an Access-Accept message > to provision SNMP over a secure transport (i.e. authPriv): > > 1. Service-Type with a value of Framed-Management. > 2. Framed-Management-Protocol with a value of SNMP. > 3. Management-Transport-Protection with a value of Integrity- > Confidentiality-Protection. > > Refer to [I-D.ietf-radext-management-authorization] for a detailed > description of these attributes. From the perspective of the NAS, > these attribute and value pairs indicate that the user is authorized > to use SNMP using an SNMP secure Transport Model. > > New: > > The following RADIUS attributes are used in an Access-Accept message > to provision SNMP over a secure transport (i.e. authPriv): > > 1. Service-Type with a value of Framed-Management. > 2. Framed-Management-Protocol with a value of SNMP. > 3. Management-Transport-Protection with a value of Integrity- > Confidentiality-Protection. > > The Old was actually the New, and the "real" Old had been omitted. Sorry. > >> I have no objection to this: >> >>> Combining a secure transport with RADIUS >>> authentication/authorization, and the SNMPv1 or SNMPv2c or USM >>> security models is NOT RECOMMENDED. See the coexistence section of >>> [TMSM]." >> >> But then I question whether we want to keep this: >> >>> There are good reasons to provision USM access to supplement AAA- >>> based access, however. > > Yes, I think we do. This addresses a different issue. Combining a secure > transport model with a non-TSM security model is indeed NOT RECOMMENDED. I read the text quoted to specifically NOT RECOMMEND combining a _RADIUS-using_ transport model with a non-TSM security model. While I'm pretty sure we recommend elsewhere against combining secure transports in general with non-TSM security, that's out of the narrow scope of this document. > The text you question is a recommendation for operators to provision a > non-AAA method of SNMP access. This is the analog of maintaining a local > /etc/passwd file as a back-up to NIS, for situations when the remote > authentication server is unreachable. Oh, I see. You're not talking about using USM with a secure transport, but rather about provisioning both secure-transport+RADIUS+TSM _and_ USM separately. That's a good recommendation, and I don't object to having it in this document, but I think it perhaps also belongs in the TMSM or TSM documents, since it really is not specific to RADIUS. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 13:46:31 2009 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 70FD83A69AB; Wed, 7 Jan 2009 13:46:31 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7913A68FE for ; Wed, 7 Jan 2009 13:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, J_CHICKENPOX_63=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 Q+gbnFHFhuXE for ; Wed, 7 Jan 2009 13:46:29 -0800 (PST) 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 4D0F33A684C for ; Wed, 7 Jan 2009 13:46:29 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 0hgx1b03n0vyq2s52lmGTa; Wed, 07 Jan 2009 21:46:16 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA05.westchester.pa.mail.comcast.net with comcast id 0lmF1b0074H2mdz3RlmF1V; Wed, 07 Jan 2009 21:46:15 +0000 From: "Dave Nelson" To: References: <20090106225247.GA9442@elstar.local> <444BE200AF6D43499FCF4882B9B59277@NEWTON603> <20090107074931.GA9700@elstar.local> <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> <200901071900.n07J00vT002822@raisinbran.srv.cs.cmu.edu> <1FCEC84104FB08F4DD94C6BC@atlantis.pc.cs.cmu.edu> <200901072013.n07KDraT019946@grapenut.srv.cs.cmu.edu> <0B7929B2A179038D2D580765@atlantis.pc.cs.cmu.edu> Date: Wed, 7 Jan 2009 16:46:20 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclxDz5G8KeVAojST0e1Bi5VLWFWyQAANV6g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <0B7929B2A179038D2D580765@atlantis.pc.cs.cmu.edu> Subject: Re: [Isms] WGLC: radius-usage-04 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 writes... >> Yes, I think we do. This addresses a different issue. Combining >> a secure transport model with a non-TSM security model is indeed >> NOT RECOMMENDED. > > I read the text quoted to specifically NOT RECOMMEND combining a > _RADIUS-using_ transport model with a non-TSM security model. While > I'm pretty sure we recommend elsewhere against combining secure > transports in general with non-TSM security, that's out of the > narrow scope of this document. Well, as long as the text that Dave Harrington provided says the right thing, you can simply ignore my imprecise paraphrasing. :-) Are we OK on that? > Oh, I see. You're not talking about using USM with a secure > transport, but rather about provisioning both secure-transport+ > RADIUS+TSM _and_ USM separately. Yeah. I'll take another look at the wording any try to make that more clear in the -05 version. > That's a good recommendation, and I don't object to having it in > this document, but I think it perhaps also belongs in the TMSM or TSM > documents, since it really is not specific to RADIUS. Umm... OK. We'll leave it in this draft. The TMSM and TSM documents are not my fish to fry, but I'll observe that they are not in any way AAA-specific, so this recommendation may not really fit there, either. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 13:53:07 2009 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 920CE3A682B; Wed, 7 Jan 2009 13:53:07 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66CAB3A682B for ; Wed, 7 Jan 2009 13:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 42kqbrvhTPcw for ; Wed, 7 Jan 2009 13:53:05 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 53AB33A6813 for ; Wed, 7 Jan 2009 13:53:05 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 0eMW1b0220cZkys59lstfg; Wed, 07 Jan 2009 21:52:53 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id 0lss1b00k0UQ6dC3WlstWN; Wed, 07 Jan 2009 21:52:53 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <20090106225247.GA9442@elstar.local><444BE200AF6D43499FCF4882B9B59277@NEWTON603><20090107074931.GA9700@elstar.local><02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com><8992A2C542E14B50B6B969A054F75AB7@NEWTON603><200901071900.n07J00vT002822@raisinbran.srv.cs.cmu.edu><1FCEC84104FB08F4DD94C6BC@atlantis.pc.cs.cmu.edu><200901072013.n07KDraT019946@grapenut.srv.cs.cmu.edu><0B7929B2A179038D2D580765@atlantis.pc.cs.cmu.edu> Date: Wed, 7 Jan 2009 16:52:51 -0500 Message-ID: <02f001c97112$49f6a260$6905a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AclxDz5G8KeVAojST0e1Bi5VLWFWyQAANV6gAABsReA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [Isms] WGLC: radius-usage-04 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, > > That's a good recommendation, and I don't object to having it in > > this document, but I think it perhaps also belongs in the > TMSM or TSM > > documents, since it really is not specific to RADIUS. > > Umm... OK. We'll leave it in this draft. The TMSM and TSM > documents are > not my fish to fry, but I'll observe that they are not in any way > AAA-specific, so this recommendation may not really fit there, either. Well, the non-reachability issue probably applies to CAs and Kerberos servers, as well as AAA servers so I'll add somethng generic about having a fallback authentication mechanism to either the TMSM or the TSM doc. dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 14:02:13 2009 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 A06F53A682B; Wed, 7 Jan 2009 14:02:13 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4DD3A682B for ; Wed, 7 Jan 2009 14:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 lWRF7fqgwNVU for ; Wed, 7 Jan 2009 14:02:10 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 932B03A67FB for ; Wed, 7 Jan 2009 14:02:09 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 0giU1b00N0bG4ec55m1xZW; Wed, 07 Jan 2009 22:01:57 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id 0m1w1b00C0UQ6dC3Pm1wFB; Wed, 07 Jan 2009 22:01:57 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <20090106225247.GA9442@elstar.local><444BE200AF6D43499FCF4882B9B59277@NEWTON603><20090107074931.GA9700@elstar.local><02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com><8992A2C542E14B50B6B969A054F75AB7@NEWTON603> <2B473E36C58C4A6CAB8B0830D3446398@NEWTON603> Date: Wed, 7 Jan 2009 17:01:55 -0500 Message-ID: <02f101c97113$8e431c90$6905a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AclwnIGzsZMJLgqjSPODkJxsFWQXoAAK+MWAAAQB+pAABiTPsAAIXIcw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <2B473E36C58C4A6CAB8B0830D3446398@NEWTON603> Subject: Re: [Isms] WGLC: radius-usage-04 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 think you would be better to describe the two use cases, which each have authn and authz aspects, and to describe that the scope of the current document is ONLY the service authn/authz use case. In the RADIUS for SNMP Access Control document, we can discuss how a single-sign-on approach might be used, reusing the service authn identity as the access control authn identity. I think this discussion does not belong in the RADIUS for Transport Models document, since we are not addressing any access control aspects. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Wednesday, January 07, 2009 2:00 PM > To: isms@ietf.org > Subject: Re: [Isms] WGLC: radius-usage-04 > > Based on the discussion so far, I'd like to propose the > following revisions > to the draft: > > Old: > > 2. RADIUS Usage for SNMP Transport Models > > There are three ways in which RADIUS may be used by SNMP Transport > Models. These include (a) user authentication, (b) service > authorization and (c) access control authorization. The first two > items are discussed in detail in this memo, while the > third item is a > topic of current research, and beyond the scope of this document. > This document describes the way in which RADIUS attributes and > messages are applied to the specific application area of SNMP > Transport Models. > > New: > > 2. RADIUS Usage for SNMP Transport Models > > There are three ways in which RADIUS may be used by SNMP. These > include (a) user authentication, (b) service authorization and > (c) access control authorization. User authentication and service > authorization via RADIUS are undertaken by the Transport Model, > and are discussed in detail in this memo. Access control would > be undertaken by the Message Processing Model and an Access Control > Model, is a topic of current research, and is beyond the scope of > this document. This document describes the way in which RADIUS > attributes and messages are applied to the specific application > area of SNMP Transport Models. > > Also in Section 2: > > Old: > > Service authorization allows a RADIUS server to authorize an > authenticated principal to use SNMP over a specific secure > Transport > Model. This memo describes mechanisms by which such > information can > be requested from a RADIUS server and enforced within the NAS. The > SNMP architecture, as described in RFC 3411 [RFC3411], > does not make > a distinction between user authentication and service > authorization. > In the case of existing, deployed security models, such as > the User- > based Security Model (USM), this distinction is not > significant. For > the SNMP Transport Models and the SNMP Transport Security Model > (TSM), this distinction is relevant and important. > > New: > > Service authorization allows a RADIUS server to authorize an > authenticated principal to use SNMP over a specific secure > Transport > Model. This memo describes mechanisms by which such > information can > be requested from a RADIUS server and enforced within the NAS. The > SNMP architecture, as described in RFC 3411 [RFC3411], > does not make > a distinction between user authentication and service > authorization. > In the case of existing, deployed security models, such as > the User- > based Security Model (USM), this distinction is not > significant. For > SNMP Transport Models, this distinction is relevant and important. > > Remove the following paragraph: > > Data object access control authorization in SNMP is handled by the > Access Control Subsystem (ACS), instantiated as various Access > Control Models. The SNMP architecture, as described in RFC 3411 > [RFC3411], explicitly mandates the separation of authentication and > authorization operations in order to retain modularity of the SNMP > system. The Abstract Service Interface (ASI) of the ACS > uses method- > independent parameters, including securityName, to determine access > control rights. A detailed description of how an Access Control > Model (ACM) might utilize the services of a RADIUS client to obtain > access control policy information is a topic of current > research, and > beyond the scope of this document. > > In Section 2.2: > > Old: > > A NAS that is compliant to this specification, MUST treat > any RADIUS > Access-Accept message that provisions a transport protocol (e.g. > SSH) that cannot be provided, and/or application service > (e.g. SNMP) > that cannot be provided over that transport, as if an Access-Reject > message had been received instead. The RADIUS > Service-Type attribute > is the primary indicator of the service being provisioned, although > other attributes may also convey service provisioning information. > Specific attributes for use with SNMP Transport Models are > recommended in this document. > > New: > > A NAS that is compliant to this specification, MUST treat > any RADIUS > Access-Accept message that provisions a level of transport > protection > (e.g. SSH) that cannot be provided, and/or application > service (e.g. > SNMP) that cannot be provided over that transport, as if an Access- > Reject message had been received instead. The RADIUS Service-Type > Attribute is the primary indicator of the service being > provisioned, > although other attributes may also convey service provisioning > information. > > In Section 2.3: > > Old: > > RADIUS servers compliant to this specification SHOULD use RADIUS > service provisioning attributes, as described herein, to > specify SNMP > access over a secure transport protocol. Such RADIUS > servers MAY use > RADIUS hint attributes included in the Access-Request message, as > described herein, in determining what, if any, service to > provision. > > New: > > RADIUS servers compliant to this specification SHOULD use RADIUS > service provisioning attributes, as described herein, to > specify SNMP > access over a secure transport. Such RADIUS servers MAY use RADIUS > hint attributes included in the Access-Request message, as > described > herein, in determining what, if any, service to provision. > > Old: > > The following RADIUS attributes SHOULD be used, as hint attributes > included in the Access-Request message to signal use of SNMP over a > secure transport (i.e. authPriv) to the RADIUS server: > > 1. Service-Type with a value of Framed-Management. > 2. Framed-Management-Protocol with a value of SNMP. > 3. Management-Transport-Protection with a value of Integrity- > Confidentiality-Protection. > > Refer to [I-D.ietf-radext-management-authorization] for a detailed > description of these attributes. From the perspective of > the RADIUS > Server, these attribute and value pairs indicate that the user is > requesting to use SNMP over an SNMP secure Transport Model. > > New: > > The following RADIUS attributes SHOULD be used, as hint attributes > included in the Access-Request message to signal use of SNMP over a > secure transport (i.e. authPriv) to the RADIUS server: > > 1. Service-Type with a value of Framed-Management. > 2. Framed-Management-Protocol with a value of SNMP. > 3. Management-Transport-Protection with a value of Integrity- > Confidentiality-Protection. > > Old: > > The following RADIUS attributes are used in an > Access-Accept message > to provision SNMP over a secure transport (i.e. authPriv): > > 1. Service-Type with a value of Framed-Management. > 2. Framed-Management-Protocol with a value of SNMP. > 3. Management-Transport-Protection with a value of Integrity- > Confidentiality-Protection. > > > Old: > > The following RADIUS attributes MAY be optionally used, to > authorize > use of SNMP without protection (i.e. authNoPriv): > > 1. Service-Type with a value of Framed-Management. > 2. Framed-Management-Protocol with a value of SNMP. > 3. Management-Transport-Protection with a value of No-Protection. > > Refer to [I-D.ietf-radext-management-authorization] for a detailed > description of this attribute. From the perspective of > the NAS, this > attribute and value pair indicates that the user is > authorized to use > SNMP without a protected transport. > > New: > > The following RADIUS attributes MAY be optionally used, to > authorize > use of SNMP without protection (i.e. authNoPriv): > > 1. Service-Type with a value of Framed-Management. > 2. Framed-Management-Protocol with a value of SNMP. > 3. Management-Transport-Protection with a value of No-Protection. > > > Old: > > The following RADIUS attributes are used to limit the extent of a > secure transport session carrying SNMP traffic, in conjunction with > an SNMP Transport Model: > > 1. Session-Timeout > 2. Inactivity-Timeout. > > Refer to [RFC2865] for a detailed description of these attributes. > From the perspective of the NAS, these attributes indicate session > timeouts to be applied to the secure transport sessions. The > Session-Timeout Attribute indicates the maximum number of seconds > that a session may exist before it is unconditionally disconnected. > The Inactivity-Timeout Attribute indicates the maximum number of > seconds that a transport session may exist without any protocol > activity (messages sent or received) before the session is > disconnected. These timeouts are enforced by the NAS. > > New: > > The following RADIUS attributes are used to limit the extent of a > secure transport session carrying SNMP traffic, in conjunction with > an SNMP Transport Model: > > 1. Session-Timeout > 2. Inactivity-Timeout. > > Refer to [RFC2865] for a detailed description of these attributes. > The Session-Timeout Attribute indicates the maximum number > of seconds > that a session may exist before it is unconditionally disconnected. > The Inactivity-Timeout Attribute indicates the maximum number of > seconds that a transport session may exist without any protocol > activity (messages sent or received) before the session is > disconnected. These timeouts are enforced by the NAS. > > Remove the following section: > > 2.4. SNMP Access Control Authorization > > [I-D.ietf-radext-management-authorization] describes a RADIUS > attribute that can be used for SNMP access control authorization, > however, the details of how an SNMP Access Control Model, > such as the > View-based Access Control Model (VACM) [RFC3415], might utilize > RADIUS authorization are a topic of current research, and > beyond the > scope of this document. > > In Section 5: > > Old: > > If the SNMP Message Processing Module selects the SNMPv1 or SNMPv2c > Security Model as the security model to use (because the message is > SNMPv1 or SNMPv2), then securityName comes from the community name, > as per RFC3584. This may not be what is expected when > using an SNMP > secure Transport Model. It is NOT RECOMMENDED that a > combination of > a secure transport, RADIUS authentication/authorization, and the > SNMPv1 and/or SNMPv2c community models be used together, as it > necessitates the opening of an insecure access path within > the Access > Control Subsystem. > > If the SNMP User-based Security Model is selected (because > the SNMPv3 > message contains a msgSecurityModel=USM), then securityName is > determined using USM (after performing USM > authentication). This may > not be what is expected when using an SNMP secure Transport Model > with an external authentication service, such as RADIUS. > USM entries > for noAuthNoPriv access would allow messages utilizing USM > to bypass > the secure transport. > > New: > > If the SNMPv1 or SNMPv2c Security Model is used, then securityname > comes from the community name, as per RFC3584. If the User-based > Security Model is selected, then securityName is determined using > USM. This may not be what is expected when using an SNMP secure > Transport Model with an external authentication service, such as > RADIUS. > > Combining a secure transport with RADIUS > authentication/authorization, > and the SNMPv1 or SNMPv2c or USM security models is NOT > RECOMMENDED. > See the coexistence section of [TMSM]." > > (A specific section number reference would be nice here, too.) > > Old: > > There are good reasons to provision USM access in tandem with AAA- > based access, however. > > New: > > There are good reasons to provision USM access to supplement AAA- > based access, however. > > Old: > > The Message-Authenticator (80) attribute SHOULD be used with RADIUS > messages that are described in this memo, as defined in [RFC3579]. > > New: > > The Message-Authenticator (80) attribute [RFC3579] SHOULD be used > with RADIUS messages that are described in this memo." > > In Section 7: > > Move the following references from Section 7.1 Normative References to > Section 7.2 Informative References: > > [I-D.ietf-isms-secshell] > Harrington, D., Salowey, J., and W. Hardaker, "Secure > Shell Transport Model for SNMP", > draft-ietf-isms-secshell-12 (work in progress), > October 2008. > > [I-D.ietf-isms-transport-security-model] > Harrington, D. and W. Hardaker, "Transport > Security Model > for SNMP", draft-ietf-isms-transport-security-model-09 > (work in progress), October 2008. > > [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) > Authentication Protocol", RFC 4252, January 2006. > > Move the following references from Section 7.2 Informative > References to > Section 7.1 Normative References: > > > [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication > Dial In User Service) Support For Extensible > Authentication Protocol (EAP)", RFC 3579, > September 2003. > > [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication > Dial In User Service (RADIUS) Implementation Issues and > Suggested Fixes", RFC 5080, December 2007. > > > _______________________________________________ > 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 Jan 7 14:09:55 2009 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 0DF913A682D; Wed, 7 Jan 2009 14:09:55 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B0D3A682D for ; Wed, 7 Jan 2009 14:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 E+x8AHPwcg2I for ; Wed, 7 Jan 2009 14:09:53 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 943A53A682B for ; Wed, 7 Jan 2009 14:09:53 -0800 (PST) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA10.westchester.pa.mail.comcast.net with comcast id 0dAj1b00816LCl05Am9hhg; Wed, 07 Jan 2009 22:09:41 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id 0m9Y1b00i0UQ6dC3Sm9ZVB; Wed, 07 Jan 2009 22:09:33 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> <6E823295705D46C08DD4FE529E6F69A1@NEWTON603> Date: Wed, 7 Jan 2009 17:09:40 -0500 Message-ID: <02f201c97114$a2f1f3e0$6905a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: Aclvf1RsABwaQ2n4S+2Gijv7s81AcgBdilAAAAeV/1A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <6E823295705D46C08DD4FE529E6F69A1@NEWTON603> Subject: Re: [Isms] WGLC: radius-usage-04 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, If you are that concerned about the discussion happening, I suggest you publish a "RADIUS Usage for SNMP Access Control Models" as an individual draft, so it provides a lingering reminder that the WG is supposed to work on such a thing. Personally, I think it is an important thing to work on. I think publishing an individual internet draft would be better than continually conflating the two use cases by adding references to SNMP access control in the RADIUS Usage for Transport Models document. my $.02 dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Wednesday, January 07, 2009 1:30 PM > To: isms@ietf.org > Subject: Re: [Isms] WGLC: radius-usage-04 > > David Harrington writes... > > > 4) do we really need section 2.4, that says "here is stuff we don't > > discuss here"? > > Well, I guess this represents a lingering level of distrust > (at least on the > part of this author) that the WG will eventually get around > to addressing > this important issue. With the caveat that ISMS anticipates > a re-charter > discussion that would bring this issue into scope and that we > would expect > to see a companion "RADIUS Usage for SNMP Access Control > Models" document, > yes, this section can be removed. > > > _______________________________________________ > 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 Jan 7 14:24:44 2009 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 AC05A3A69B9; Wed, 7 Jan 2009 14:24:44 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C4E3A69B9 for ; Wed, 7 Jan 2009 14:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.919, 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 FlXWnrWR89E4 for ; Wed, 7 Jan 2009 14:24:42 -0800 (PST) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 3D9E03A698E for ; Wed, 7 Jan 2009 14:24:42 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 0hs11b02Z0EZKEL56mQWtz; Wed, 07 Jan 2009 22:24:30 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 0mQV1b00h4H2mdz3MmQVzx; Wed, 07 Jan 2009 22:24:30 +0000 From: "Dave Nelson" To: References: <20090106225247.GA9442@elstar.local><444BE200AF6D43499FCF4882B9B59277@NEWTON603><20090107074931.GA9700@elstar.local><02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com><8992A2C542E14B50B6B969A054F75AB7@NEWTON603> <2B473E36C58C4A6CAB8B0830D3446398@NEWTON603> <02f101c97113$8e431c90$6905a8c0@china.huawei.com> Date: Wed, 7 Jan 2009 17:24:33 -0500 Message-ID: <338B5B8E0706466A89FA273B674538A6@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclwnIGzsZMJLgqjSPODkJxsFWQXoAAK+MWAAAQB+pAABiTPsAAIXIcwAADSc7A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <02f101c97113$8e431c90$6905a8c0@china.huawei.com> Subject: Re: [Isms] WGLC: radius-usage-04 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 David Harrington writes... > I think you would be better to describe the two use cases, which > each have authn and authz aspects, and to describe that the scope > of the current document is ONLY the service authn/authz use case. I've never thought of this as two separate use cases. I've always thought of it as two halves of a single problem, arbitrarily divided by WG processes and by the SNMP architecture. However, let me ponder this for a while. It wouldn't be the first time I've adjusted my viewpoint in grappling with the RADIUS-related issue of SNMP. :-) Perhaps I can propose some better text that divides the problem into separate use cases, instead of simply first-half and second-half. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 14:58:32 2009 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 A2E5D3A682D; Wed, 7 Jan 2009 14:58:32 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDFA3A682D for ; Wed, 7 Jan 2009 14:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuKSUhq786Bs for ; Wed, 7 Jan 2009 14:58:31 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 141723A67FB for ; Wed, 7 Jan 2009 14:58:30 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 0b8n1b0060vyq2s54myJFi; Wed, 07 Jan 2009 22:58:18 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA05.westchester.pa.mail.comcast.net with comcast id 0myG1b0044H2mdz3RmyGro; Wed, 07 Jan 2009 22:58:16 +0000 From: "Dave Nelson" To: References: <014501c96f7f$55941e70$6905a8c0@china.huawei.com> <6E823295705D46C08DD4FE529E6F69A1@NEWTON603> <02f201c97114$a2f1f3e0$6905a8c0@china.huawei.com> Date: Wed, 7 Jan 2009 17:58:21 -0500 Message-ID: <643BE16696894514A2C1461749F49FA3@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aclvf1RsABwaQ2n4S+2Gijv7s81AcgBdilAAAAeV/1AAASMqIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <02f201c97114$a2f1f3e0$6905a8c0@china.huawei.com> Subject: Re: [Isms] WGLC: radius-usage-04 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 David Harrington writes... > ...I suggest you publish a "RADIUS Usage for SNMP Access Control > Models" as an individual draft, so it provides a lingering reminder > that the WG is supposed to work on such a thing. Ah. The old "write an I-D or be quiet" comeback, eh? :-) Well, maybe I can find some time to do that prior to IETF-74. We'll see. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 15:03:59 2009 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 1CDA13A6A8F; Wed, 7 Jan 2009 15:03:59 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A9D3A6A0D for ; Wed, 7 Jan 2009 15:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 9AWTmjApWZWv for ; Wed, 7 Jan 2009 15:03:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ED4C23A6A8F for ; Wed, 7 Jan 2009 15:03:56 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 481CEC0005; Thu, 8 Jan 2009 00:03:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U6sMgX-mQprt; Thu, 8 Jan 2009 00:03:38 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04215C0007; Thu, 8 Jan 2009 00:03:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4AB478E0767; Thu, 8 Jan 2009 00:03:32 +0100 (CET) Date: Thu, 8 Jan 2009 00:03:32 +0100 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090107230332.GA10526@elstar.local> Mail-Followup-To: Dave Nelson , isms@ietf.org References: <20090107074931.GA9700@elstar.local> <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] WGLC: radius-usage-04 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, Jan 07, 2009 at 10:29:56AM -0500, Dave Nelson wrote: > SSH might pass a username to the UNIX shell, but the shell still needs to > perform its own authentication (login) according to locally configured > policy. The shell *might* trust that the username passed by SSH is the same > persona as that same name found in the local (or remote) authentication > database, if it is so configured. Strictly speaking, a UNIX shell never authenticates someone; a shell is forked (either by login or by sshd or ...) once authentication has been completed and the proper user and group ids have been setup and the proper process environment has been established. In other words, the identity authenticated by SSH never really leaves the SSH daemon in the form of a username that must be trusted by the shell; the shell itself has no choice about its users. This might not be relevant but I thought a clarification how things actually work won't hurt either. /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 Jan 7 15:24:01 2009 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 1DF3428C0CF; Wed, 7 Jan 2009 15:24:01 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E3228C0CF for ; Wed, 7 Jan 2009 15:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.890, 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 NhvP1APetEG0 for ; Wed, 7 Jan 2009 15:23:59 -0800 (PST) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id BE59C3A6AA1 for ; Wed, 7 Jan 2009 15:23:58 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 0hs11b02y0cZkys56nPmQn; Wed, 07 Jan 2009 23:23:46 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA10.westchester.pa.mail.comcast.net with comcast id 0nPm1b00D4H2mdz3WnPmk4; Wed, 07 Jan 2009 23:23:46 +0000 From: "Dave Nelson" To: References: <20090107074931.GA9700@elstar.local> <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> <20090107230332.GA10526@elstar.local> Date: Wed, 7 Jan 2009 18:23:50 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclxHDPeIjHqMXz5TtqcJzMJiwFPIQAAFthQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20090107230332.GA10526@elstar.local> Subject: Re: [Isms] WGLC: radius-usage-04 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 Juergen Schoenwaelder writes... > Strictly speaking, a UNIX shell never authenticates someone; > a shell is forked (either by login or by sshd or ...) once > authentication has been completed and the proper user and group > ids have been setup and the proper process environment has been > established. OK, you're right. It's typically the login process, not the shell. > In other words, the identity authenticated by SSH never really > leaves the SSH daemon in the form of a username that must be > trusted by the shell; the shell itself has no choice about its > users. Am I mistaken that SSH can pass the username to login so that login only prompts for password, and not username? Can SSH be configured so that the password check is bypassed, or am I thinking of rlogin? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 7 15:57:28 2009 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 B4ACD3A6A9B; Wed, 7 Jan 2009 15:57:28 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861DB3A6A9B for ; Wed, 7 Jan 2009 15:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 4Or1Ck05H6cn for ; Wed, 7 Jan 2009 15:57:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4F3773A68B4 for ; Wed, 7 Jan 2009 15:57:26 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DACA2C0005; Thu, 8 Jan 2009 00:57:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g-HHXL+s+9KU; Thu, 8 Jan 2009 00:57:07 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2801EC0029; Thu, 8 Jan 2009 00:57:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7709B8E08DE; Thu, 8 Jan 2009 00:57:06 +0100 (CET) Date: Thu, 8 Jan 2009 00:57:06 +0100 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090107235706.GB10641@elstar.local> Mail-Followup-To: Dave Nelson , isms@ietf.org References: <20090107074931.GA9700@elstar.local> <02ab01c970d2$1fcc1000$6905a8c0@china.huawei.com> <8992A2C542E14B50B6B969A054F75AB7@NEWTON603> <20090107230332.GA10526@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] WGLC: radius-usage-04 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, Jan 07, 2009 at 06:23:50PM -0500, Dave Nelson wrote: > Am I mistaken that SSH can pass the username to login so that login only > prompts for password, and not username? > > Can SSH be configured so that the password check is bypassed, or am I > thinking of rlogin? If the SSH daemon figures out that it has to authenticate using a password or using keyboard interactive, on most systems it will simply call into the pluggable authentication modules (PAM) library. And the PAM mechanism usually distinguishes between: - account verification - is the account still allowed to be used? - user authentication - is the user the one he claims to be? - password change authorization - is the user allowed to change a password? - session management - what needs to be done before and at the end of a user's session? PAM was created as an effort to factor these things out of an increasing number of daemons that need to authenticate users and establish sessions (login, telnetd, ftpd, sshd, ...). By simply writing new PAM library modules or configuring existing PAM modules, you can realize almost any policy without touching the source of any daemons. If you want, you can configure PAM to accept any password. (On many systems, you can find the details of what really happens in /etc/pam.d.) Anyway, if you ssh into a box and you get prompted for the password, then you are still talking to the ssh daemon and once the daemon declares (potentially by calling PAM) that it likes your password, it will setup the process environment and fork a shell (or whatever service you requested) for you. The login program is not involved in all of this; the central cornerstone on most systems is the PAM library, not the login program (which is at the end just a wrapper around PAM). /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 Thu Jan 15 00:53:28 2009 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 2912728C130; Thu, 15 Jan 2009 00:53:28 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D2028C130 for ; Thu, 15 Jan 2009 00:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.107, 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 3yeBA6fuqe9V for ; Thu, 15 Jan 2009 00:53:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BBE313A6AC1 for ; Thu, 15 Jan 2009 00:53:25 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8683C000A for ; Thu, 15 Jan 2009 09:53:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EBg8tiQANbTr; Thu, 15 Jan 2009 09:53:05 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32683C00F5; Thu, 15 Jan 2009 09:53:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 23FFC8F4100; Thu, 15 Jan 2009 09:53:03 +0100 (CET) Date: Thu, 15 Jan 2009 09:53:03 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090115085302.GD7331@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] RFC 5378 issue and ISMS next steps 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 The WG Chairs have been asked to make their WG aware of this issue. This is a complicated subject, but the executive summary is that if you have an Internet-draft that quotes substantially from one or more older RFCs (ones with a publication date pre-November 11, 2008), and you did not write this earlier work yourself (or you wrote it while with another company), you need to be aware of the likely difficulty of obtaining RFC5378 clearances for your new work, and also to be aware that a work-around is on the way. The work-around should be in place to allow submissions to the San Francisco IETF well before the normal deadlines. A more detailed summary of the issue can be found at the URL below. For more information, see the discussion on the general IETF discussion list. http://trustee.ietf.org/docs/Background-to-Draft-Update-to-IETF-Trust-Legal-Provisions.txt With a chair hat on, I am not going to allow a general discussion about RFC 5378 on this list (as it is off topic). Please take such comments to the main IETF discussion list. Questions about specific WG drafts are of course on topic. Note that this issue with RFC5378 should not stop the WG from resolving the WG last call issues on the mailing list. David Harrington is working on the edits and he will post messages concerning the resolution of the last call issues raised and where he is not sure what the necessary edits are to resolve issues. /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 Jan 21 08:19:36 2009 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 43DE828C1F8; Wed, 21 Jan 2009 08:19:36 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AA0028C1ED for ; Wed, 21 Jan 2009 08:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=-1.240, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaSiXwFPJ2PC for ; Wed, 21 Jan 2009 08:19:34 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 3606E3A6BD1 for ; Wed, 21 Jan 2009 08:19:34 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 6Bsn1b0030xGWP858GKJBQ; Wed, 21 Jan 2009 16:19:18 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id 6GKH1b00h0UQ6dC3YGKHeX; Wed, 21 Jan 2009 16:19:18 +0000 From: "David Harrington" To: Date: Wed, 21 Jan 2009 11:19:16 -0500 Message-ID: <0b9501c97be4$024201d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl74lDCywjq/DtGQdSulJ7LDaBJpQ== Subject: [Isms] ssh authn X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org In the following paragraph, is this all about server authn, or is client and server authn mixed into this paragraph? Using tmTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, authenticate the server, and exchange keys for message integrity and encryption. The tmTransportAddress field may contain a user-name followed by an '@' character (ASCII 0x40) that will indicate a specific user-name string that should be presented to the ssh server as the "user name" for authentication purposes. This MAY be different than the passed tmSecurityName value that will be used in the remaining steps below. If there is no specified user-name in the tmTransportAddress then the tmSecurityName should be used as the user-name. The other parameters of the transport connection and the credentials used to authenticate the server are provided in an implementation-dependent manner. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 21 08:19:36 2009 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 6604628C206; Wed, 21 Jan 2009 08:19:36 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5D53A6BD1 for ; Wed, 21 Jan 2009 08:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPfPE2tmENC6 for ; Wed, 21 Jan 2009 08:19:35 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id C78C73A699F for ; Wed, 21 Jan 2009 08:19:34 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 6F3F1b02W0xGWP858GKKBY; Wed, 21 Jan 2009 16:19:19 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id 6GKH1b00h0UQ6dC3YGKJet; Wed, 21 Jan 2009 16:19:19 +0000 From: "David Harrington" To: Date: Wed, 21 Jan 2009 11:19:16 -0500 Message-ID: <0b9601c97be4$02a15fe0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl74N3iPdq5MwYjSSOkvS8hG2ShVg== Subject: [Isms] snmp subsystems 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 If a notification originator opens a subsystem called "snmp" and a command generator opens a subsystem called "snmp", will that be confusing to SSH? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 21 09:14:22 2009 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 3EFCD28C177; Wed, 21 Jan 2009 09:14:22 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EC428C177 for ; Wed, 21 Jan 2009 09:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 Nyq+QEqb9ot1 for ; Wed, 21 Jan 2009 09:14:20 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 4F8FE28C132 for ; Wed, 21 Jan 2009 09:14:20 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA10.westchester.pa.mail.comcast.net with comcast id 6Dm21b00J0Fqzac5AHE5kw; Wed, 21 Jan 2009 17:14:05 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 6HDr1b0060UQ6dC3UHDrz8; Wed, 21 Jan 2009 17:13:52 +0000 From: "David Harrington" To: Date: Wed, 21 Jan 2009 12:14:02 -0500 Message-ID: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl766YcFjrQ4+oVSp21/TDJIlBzMg== Subject: [Isms] SNMP SSH ports 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 sshtm> "The SSH Transport Model defines two well-known default ports, one for request/response traffic, and one port that listens for notifications." Pasi> - Secton 8, "two well-known ports" -- hmm, rest of the document seems to assume a single port? (including IANA considerations and several other places) I think I should eliminate the sentence in section 8. PLease correct me if I'm wrong. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 21 11:50:37 2009 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 BAE143A6A7C; Wed, 21 Jan 2009 11:50:37 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E433A6A7C for ; Wed, 21 Jan 2009 11:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.340, 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 AOJFUQqmeAOI for ; Wed, 21 Jan 2009 11:50:36 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 5AA133A6A68 for ; Wed, 21 Jan 2009 11:50:36 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id EF56E39A111; Wed, 21 Jan 2009 11:50:19 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> Date: Wed, 21 Jan 2009 11:50:19 -0800 In-Reply-To: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 21 Jan 2009 12:14:02 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] IsmsSNMP SSH ports 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, 21 Jan 2009 12:14:02 -0500, "David Harrington" said: DH> I think I should eliminate the sentence in section 8. PLease correct DH> me if I'm wrong. Well, we can either do one well known port with two different service names or two well known ports each with the same service name. Anything with embedded ssh, though, wouldn't want to do two different service names if they had both a NR and a CR on the same box that wasn't the same process. There has to be some way, however, of distinguishing whether you're trying to get to a NR or CR entity. Yes, you could do it via the SNMPv3 pdu handler registration process but in reality most software isn't architected that way. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 21 11:53:36 2009 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 F09413A6A5C; Wed, 21 Jan 2009 11:53:35 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674333A68CD for ; Wed, 21 Jan 2009 11:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.311, 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 ooAi3u80f01q for ; Wed, 21 Jan 2009 11:53:34 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id B295028C0FB for ; Wed, 21 Jan 2009 11:53:34 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id A12EB39A111; Wed, 21 Jan 2009 11:53:18 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <0b9601c97be4$02a15fe0$0600a8c0@china.huawei.com> Date: Wed, 21 Jan 2009 11:53:18 -0800 In-Reply-To: <0b9601c97be4$02a15fe0$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 21 Jan 2009 11:19:16 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Ismssnmp subsystems 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, 21 Jan 2009 11:19:16 -0500, "David Harrington" said: DH> If a notification originator opens a subsystem called "snmp" and a DH> command generator opens a subsystem called "snmp", will that be DH> confusing to SSH? Not to SSH, no. Unless you need to route them to two different slave processes (in which case you have a problem). See my other note... -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 21 12:12:24 2009 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 530743A695F; Wed, 21 Jan 2009 12:12:24 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08533A695F for ; Wed, 21 Jan 2009 12:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOqqu9MrRq1l for ; Wed, 21 Jan 2009 12:12:22 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 090933A6881 for ; Wed, 21 Jan 2009 12:12:21 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (72-61-227-62.pools.spcsdns.net [72.61.227.62]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0LKBrMt017640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 15:11:55 -0500 (EST) Date: Wed, 21 Jan 2009 15:11:52 -0500 From: Jeffrey Hutzelman To: Wes Hardaker , David Harrington Message-ID: <404AAA776ADF7CBE6A456DDA@atlantis.pc.cs.cmu.edu> In-Reply-To: <200901211950.n0LJoOxn000655@raisinbran.srv.cs.cmu.edu> References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> <200901211950.n0LJoOxn000655@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@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] IsmsSNMP SSH ports 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, January 21, 2009 11:50:19 AM -0800 Wes Hardaker wrote: >>>>>> On Wed, 21 Jan 2009 12:14:02 -0500, "David Harrington" >>>>>> said: > > DH> I think I should eliminate the sentence in section 8. PLease correct > DH> me if I'm wrong. > > Well, we can either do one well known port with two different service > names or two well known ports each with the same service name. What do you mean by "service name" here? An SSH subsystem name? It seems to me that the right answer here is to define distinct ports, not distinct subsystem names. Subsystem names are not intended as a mechanism for multiplexing multiple instances of the same subsystem. We also need to recognize that many NR's will run on nonstandard ports; an interactive management app is certainly going to want to use a port dynamically allocated by its OS. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 21 12:12:57 2009 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 69CCE3A68DB; Wed, 21 Jan 2009 12:12:57 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154003A68DB for ; Wed, 21 Jan 2009 12:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IX8Rx0z6Vtq for ; Wed, 21 Jan 2009 12:12:56 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 3D4A23A6881 for ; Wed, 21 Jan 2009 12:12:56 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (72-61-227-62.pools.spcsdns.net [72.61.227.62]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0LKCWUW017683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 15:12:33 -0500 (EST) Date: Wed, 21 Jan 2009 15:12:32 -0500 From: Jeffrey Hutzelman To: Wes Hardaker , David Harrington Message-ID: <6A0B86D9AA16BAAC4569A5A8@atlantis.pc.cs.cmu.edu> In-Reply-To: <200901211953.n0LJrLAP001504@raisinbran.srv.cs.cmu.edu> References: <0b9601c97be4$02a15fe0$0600a8c0@china.huawei.com> <200901211953.n0LJrLAP001504@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@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] Ismssnmp subsystems 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, January 21, 2009 11:53:18 AM -0800 Wes Hardaker wrote: >>>>>> On Wed, 21 Jan 2009 11:19:16 -0500, "David Harrington" >>>>>> said: > > DH> If a notification originator opens a subsystem called "snmp" and a > DH> command generator opens a subsystem called "snmp", will that be > DH> confusing to SSH? > > Not to SSH, no. Unless you need to route them to two different > slave processes (in which case you have a problem). See my other > note... And in that case, I think you should be using different ports, not different subsystem names. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 21 12:22:24 2009 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 AF2043A69E9; Wed, 21 Jan 2009 12:22:24 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCD63A69E9 for ; Wed, 21 Jan 2009 12:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 6mOQyfAJVuZu for ; Wed, 21 Jan 2009 12:22:22 -0800 (PST) Received: from mail-ew0-f20.google.com (mail-ew0-f20.google.com [209.85.219.20]) by core3.amsl.com (Postfix) with ESMTP id BA12E3A68FF for ; Wed, 21 Jan 2009 12:22:21 -0800 (PST) Received: by ewy13 with SMTP id 13so1845557ewy.13 for ; Wed, 21 Jan 2009 12:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+uNyAnYu2btd5Ylad4vDPyhr+e4Y5XQeFOF3CsbguUk=; b=EXfogujsBG8Pfxxs+LerQxA3M1ogHKw25Kga+MSLoYJEY+AgGmWrRyie5oD1YGfEjF 1tp8PUUUBfewhWDehehF+2kM74wlX6+9gIQwl4GNXuVyyQct++EOfU2o1tChSHLs/Lx4 NQIsC6mGqq5SRJDsd8wBYTfhMeW6UB8seIpCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PNCgh/Bn1suQrJYs+fgvXQb04yPmBJtYj2359N0NC2bLXW+buS9Yo1CLZJgdQQp+Mn hxfYMG1qPTFtvUCpl1R3L7RM7hblHc9Erz9BXaQSWBYOvD27qecy60uB7+R7mSXWN9e0 VYDMWbPc6tS737f3leYPOI2Va6BkLsjVBs8PI= MIME-Version: 1.0 Received: by 10.103.92.8 with SMTP id u8mr267139mul.34.1232569323293; Wed, 21 Jan 2009 12:22:03 -0800 (PST) In-Reply-To: <6A0B86D9AA16BAAC4569A5A8@atlantis.pc.cs.cmu.edu> References: <0b9601c97be4$02a15fe0$0600a8c0@china.huawei.com> <200901211953.n0LJrLAP001504@raisinbran.srv.cs.cmu.edu> <6A0B86D9AA16BAAC4569A5A8@atlantis.pc.cs.cmu.edu> Date: Wed, 21 Jan 2009 15:22:03 -0500 Message-ID: From: Ira McDonald To: Jeffrey Hutzelman , Ira McDonald Cc: isms@ietf.org Subject: Re: [Isms] Ismssnmp subsystems 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 agree with Jeffrey below. In this case two different well-known ports makes just as much sense as it did in SNMPv1 and in all subsequent SNMP versions over UDP transports. Also, administrators setting up firewalls and router policies are going to like two different ports better I believe (finer-grained). Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music/High North Inc email: blueroofmusic@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Jan 21, 2009 at 3:12 PM, Jeffrey Hutzelman wrote: > --On Wednesday, January 21, 2009 11:53:18 AM -0800 Wes Hardaker > wrote: > >>>>>>> On Wed, 21 Jan 2009 11:19:16 -0500, "David Harrington" >>>>>>> said: >> >> DH> If a notification originator opens a subsystem called "snmp" and a >> DH> command generator opens a subsystem called "snmp", will that be >> DH> confusing to SSH? >> >> Not to SSH, no. Unless you need to route them to two different >> slave processes (in which case you have a problem). See my other >> note... > > And in that case, I think you should be using different ports, not different > subsystem names. > _______________________________________________ > 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 Jan 21 12:35:12 2009 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 2E67D3A6937; Wed, 21 Jan 2009 12:35:12 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879E23A6937 for ; Wed, 21 Jan 2009 12:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 757X3vO642q3 for ; Wed, 21 Jan 2009 12:35:09 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BB6833A6908 for ; Wed, 21 Jan 2009 12:35:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,302,1231113600"; d="scan'208";a="234134824" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2009 20:34:53 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0LKYrAV031411; Wed, 21 Jan 2009 12:34:53 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n0LKYo3J011201; Wed, 21 Jan 2009 20:34:53 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 12:34:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 12:34:48 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] IsmsSNMP SSH ports Thread-Index: Acl8AYGEG6UHB/qnT3ay0NLD5TSDawABeXWg References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> From: "Joseph Salowey (jsalowey)" To: "Wes Hardaker" , "David Harrington" X-OriginalArrivalTime: 21 Jan 2009 20:34:49.0884 (UTC) FILETIME=[B4ED5DC0:01C97C07] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1348; t=1232570093; x=1233434093; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Isms]=20IsmsSNMP=20SSH=20ports |Sender:=20; bh=BbQv5/IXacqIXbEsqseqEp2hUrJvxkTqQPOlCJkEZGo=; b=JFqqMRuBwa8ozlqmsq02xRT4QbIDzLmQD7oZ22WLNUT1XmOnlqfa6EI1Ak YYxIAFaoJ3HLbx6vwWwrgkH+dPrtezHOOc3Ks0MuCTSYBNGhgp/ji/UDYlaG ecs4YJeRva; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: isms@ietf.org Subject: Re: [Isms] IsmsSNMP SSH ports 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 Why do we need port numbers in the range 1..1023? The is bound to cause a DISCUSS from the IESG. > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Wednesday, January 21, 2009 11:50 AM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] IsmsSNMP SSH ports > > >>>>> On Wed, 21 Jan 2009 12:14:02 -0500, "David Harrington" > said: > > DH> I think I should eliminate the sentence in section 8. > PLease correct > DH> me if I'm wrong. > > Well, we can either do one well known port with two different > service names or two well known ports each with the same service name. > > Anything with embedded ssh, though, wouldn't want to do two > different service names if they had both a NR and a CR on the > same box that wasn't the same process. > > There has to be some way, however, of distinguishing whether > you're trying to get to a NR or CR entity. Yes, you could do > it via the SNMPv3 pdu handler registration process but in > reality most software isn't architected that way. > -- > 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 Wed Jan 21 13:55:05 2009 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 BBE683A6970; Wed, 21 Jan 2009 13:55:05 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A700C3A6970 for ; Wed, 21 Jan 2009 13:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 p2A21vQBpWCr for ; Wed, 21 Jan 2009 13:55:04 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id BE3C63A6778 for ; Wed, 21 Jan 2009 13:55:03 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 6BZC1b0060SCNGk55MuoU6; Wed, 21 Jan 2009 21:54:48 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 6Mun1b00n0UQ6dC3VMuor9; Wed, 21 Jan 2009 21:54:48 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Wes Hardaker'" References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> <200901211950.n0LJoOxn000655@raisinbran.srv.cs.cmu.edu> <404AAA776ADF7CBE6A456DDA@atlantis.pc.cs.cmu.edu> Date: Wed, 21 Jan 2009 16:54:46 -0500 Message-ID: <0bc201c97c12$e059b200$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <404AAA776ADF7CBE6A456DDA@atlantis.pc.cs.cmu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl8BIYznWyMX6+HQ4+YS2Ct02cIaQADVgWQ Cc: isms@ietf.org Subject: Re: [Isms] IsmsSNMP SSH ports 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, > We also need to > recognize that many NR's will run on nonstandard ports; an > interactive > management app is certainly going to want to use a port dynamically > allocated by its OS. > If the notification receiver listens on nonstandard ports, how will the notification originator know where to send notifications? SNMP usually uses standard ports 161 (where an agent listens for requests) and 162 (where a manager listens for notifications). An SNMP entity can act as both agent and manager. The port used to send is often dynamically allocated (and that defines the port to which to send responses). dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 21 14:13:51 2009 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 2869428C10A; Wed, 21 Jan 2009 14:13:51 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC95C28C0EF for ; Wed, 21 Jan 2009 14:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 tIw6u4VPtgAf for ; Wed, 21 Jan 2009 14:13:49 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id E7A4528C0FB for ; Wed, 21 Jan 2009 14:13:48 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 6Bus1b0040mv7h055NDZHZ; Wed, 21 Jan 2009 22:13:33 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id 6NDY1b00F0UQ6dC3XNDYVg; Wed, 21 Jan 2009 22:13:33 +0000 From: "David Harrington" To: "'Joseph Salowey \(jsalowey\)'" , "'Wes Hardaker'" References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> Date: Wed, 21 Jan 2009 17:13:31 -0500 Message-ID: <0bc301c97c15$7eabb730$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl8AYGEG6UHB/qnT3ay0NLD5TSDawABeXWgAAN+gkA= Cc: isms@ietf.org Subject: Re: [Isms] IsmsSNMP SSH ports 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 think all we need is two fixed well-known ports (or one that can multiplex as needed) dbh > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Wednesday, January 21, 2009 3:35 PM > To: Wes Hardaker; David Harrington > Cc: isms@ietf.org > Subject: RE: [Isms] IsmsSNMP SSH ports > > Why do we need port numbers in the range 1..1023? The is > bound to cause > a DISCUSS from the IESG. > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of Wes Hardaker > > Sent: Wednesday, January 21, 2009 11:50 AM > > To: David Harrington > > Cc: isms@ietf.org > > Subject: Re: [Isms] IsmsSNMP SSH ports > > > > >>>>> On Wed, 21 Jan 2009 12:14:02 -0500, "David Harrington" > > said: > > > > DH> I think I should eliminate the sentence in section 8. > > PLease correct > > DH> me if I'm wrong. > > > > Well, we can either do one well known port with two different > > service names or two well known ports each with the same > service name. > > > > Anything with embedded ssh, though, wouldn't want to do two > > different service names if they had both a NR and a CR on the > > same box that wasn't the same process. > > > > There has to be some way, however, of distinguishing whether > > you're trying to get to a NR or CR entity. Yes, you could do > > it via the SNMPv3 pdu handler registration process but in > > reality most software isn't architected that way. > > -- > > 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 Wed Jan 21 14:22:18 2009 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 DD6723A67EF; Wed, 21 Jan 2009 14:22:18 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3778028C0E1 for ; Wed, 21 Jan 2009 14:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 mW0O9C1miZWG for ; Wed, 21 Jan 2009 14:22:16 -0800 (PST) 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 1E37B3A6778 for ; Wed, 21 Jan 2009 14:22:16 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 6K5h1b00J0SCNGk52NN0bm; Wed, 21 Jan 2009 22:22:00 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 6NN01b00X0UQ6dC3VNN0Yd; Wed, 21 Jan 2009 22:22:00 +0000 From: "David Harrington" To: "'David Harrington'" , "'Joseph Salowey \(jsalowey\)'" , "'Wes Hardaker'" References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> <0bc301c97c15$7eabb730$0600a8c0@china.huawei.com> Date: Wed, 21 Jan 2009 17:21:59 -0500 Message-ID: <0bca01c97c16$ad4dc690$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0bc301c97c15$7eabb730$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl8AYGEG6UHB/qnT3ay0NLD5TSDawABeXWgAAN+gkAAAEZDAA== Cc: isms@ietf.org Subject: Re: [Isms] IsmsSNMP SSH ports 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 whoops, tripping over terminology. I think we need two *registered* ports, and I recommend requesting 5161 and 5162. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David Harrington > Sent: Wednesday, January 21, 2009 5:14 PM > To: 'Joseph Salowey (jsalowey)'; 'Wes Hardaker' > Cc: isms@ietf.org > Subject: Re: [Isms] IsmsSNMP SSH ports > > I think all we need is two fixed well-known ports (or one that can > multiplex as needed) > > dbh > > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Wednesday, January 21, 2009 3:35 PM > > To: Wes Hardaker; David Harrington > > Cc: isms@ietf.org > > Subject: RE: [Isms] IsmsSNMP SSH ports > > > > Why do we need port numbers in the range 1..1023? The is > > bound to cause > > a DISCUSS from the IESG. > > > > > -----Original Message----- > > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > > Behalf Of Wes Hardaker > > > Sent: Wednesday, January 21, 2009 11:50 AM > > > To: David Harrington > > > Cc: isms@ietf.org > > > Subject: Re: [Isms] IsmsSNMP SSH ports > > > > > > >>>>> On Wed, 21 Jan 2009 12:14:02 -0500, "David Harrington" > > > said: > > > > > > DH> I think I should eliminate the sentence in section 8. > > > PLease correct > > > DH> me if I'm wrong. > > > > > > Well, we can either do one well known port with two different > > > service names or two well known ports each with the same > > service name. > > > > > > Anything with embedded ssh, though, wouldn't want to do two > > > different service names if they had both a NR and a CR on the > > > same box that wasn't the same process. > > > > > > There has to be some way, however, of distinguishing whether > > > you're trying to get to a NR or CR entity. Yes, you could do > > > it via the SNMPv3 pdu handler registration process but in > > > reality most software isn't architected that way. > > > -- > > > 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 > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 21 14:22:54 2009 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 101223A6998; Wed, 21 Jan 2009 14:22:54 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37BF828C0E1 for ; Wed, 21 Jan 2009 14:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 vRxrf-3KlXxo for ; Wed, 21 Jan 2009 14:22:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6BCC63A6778 for ; Wed, 21 Jan 2009 14:22:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,303,1231113600"; d="scan'208";a="234195370" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2009 22:22:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0LMMZU6019125; Wed, 21 Jan 2009 14:22:35 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0LMMZf4005060; Wed, 21 Jan 2009 22:22:35 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 14:22:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 14:22:34 -0800 Message-ID: In-Reply-To: <0bc301c97c15$7eabb730$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] IsmsSNMP SSH ports Thread-Index: Acl8AYGEG6UHB/qnT3ay0NLD5TSDawABeXWgAAN+gkAAABhdIA== References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> <0bc301c97c15$7eabb730$0600a8c0@china.huawei.com> From: "Joseph Salowey (jsalowey)" To: "David Harrington" , "Wes Hardaker" X-OriginalArrivalTime: 21 Jan 2009 22:22:35.0088 (UTC) FILETIME=[C27D3500:01C97C16] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2319; t=1232576555; x=1233440555; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Isms]=20IsmsSNMP=20SSH=20ports |Sender:=20; bh=hfcMCVpQ2fn5subRj9yzDcAknlCjdZ2Uo0NsRxVYiIs=; b=AFBbZtzMkjeI2CSMKjch+zSejF35skAO3GxiQB138S23Z7LNX4FwU1yUeS BOPFstDJYIGpmGgcdj5NCvdwyZai1qJ73jy45csrZKSYm1Twuf/cMk5q/T6W jfJinNmgt1; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: isms@ietf.org Subject: Re: [Isms] IsmsSNMP SSH ports 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 Why wouldn't two fixed registered ports (range 1024 through 49151) be sufficient instead of fixed well-known ports (range 1 through 1023)? > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, January 21, 2009 2:14 PM > To: Joseph Salowey (jsalowey); 'Wes Hardaker' > Cc: isms@ietf.org > Subject: RE: [Isms] IsmsSNMP SSH ports > > I think all we need is two fixed well-known ports (or one > that can multiplex as needed) > > dbh > > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Wednesday, January 21, 2009 3:35 PM > > To: Wes Hardaker; David Harrington > > Cc: isms@ietf.org > > Subject: RE: [Isms] IsmsSNMP SSH ports > > > > Why do we need port numbers in the range 1..1023? The is bound to > > cause a DISCUSS from the IESG. > > > > > -----Original Message----- > > > From: isms-bounces@ietf.org > [mailto:isms-bounces@ietf.org] On Behalf > > > Of Wes Hardaker > > > Sent: Wednesday, January 21, 2009 11:50 AM > > > To: David Harrington > > > Cc: isms@ietf.org > > > Subject: Re: [Isms] IsmsSNMP SSH ports > > > > > > >>>>> On Wed, 21 Jan 2009 12:14:02 -0500, "David Harrington" > > > said: > > > > > > DH> I think I should eliminate the sentence in section 8. > > > PLease correct > > > DH> me if I'm wrong. > > > > > > Well, we can either do one well known port with two different > > > service names or two well known ports each with the same > > service name. > > > > > > Anything with embedded ssh, though, wouldn't want to do two > > > different service names if they had both a NR and a CR on > the same > > > box that wasn't the same process. > > > > > > There has to be some way, however, of distinguishing > whether you're > > > trying to get to a NR or CR entity. Yes, you could do it via the > > > SNMPv3 pdu handler registration process but in reality > most software > > > isn't architected that way. > > > -- > > > Wes Hardaker > > > Sparta, Inc. > > > _______________________________________________ > > > Isms mailing list > > > Isms@ietf.org > > > https://www.ietf.org/mailman/listinfo/isms > > > > > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jan 22 00:01:48 2009 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 55DD73A69EB; Thu, 22 Jan 2009 00:01:48 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22B03A69EB for ; Thu, 22 Jan 2009 00:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 bR76IBktW40b for ; Thu, 22 Jan 2009 00:01:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B48153A69E7 for ; Thu, 22 Jan 2009 00:01:46 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C541C0022; Thu, 22 Jan 2009 09:01:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eWZ4Jepl5WhY; Thu, 22 Jan 2009 09:01:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40870C001A; Thu, 22 Jan 2009 09:01:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1936E900CD1; Thu, 22 Jan 2009 09:01:18 +0100 (CET) Date: Thu, 22 Jan 2009 09:01:18 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090122080118.GA929@elstar.local> Mail-Followup-To: David Harrington , "'Joseph Salowey (jsalowey)'" , 'Wes Hardaker' , isms@ietf.org References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> <0bc301c97c15$7eabb730$0600a8c0@china.huawei.com> <0bca01c97c16$ad4dc690$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0bca01c97c16$ad4dc690$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] IsmsSNMP SSH ports 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, Jan 21, 2009 at 05:21:59PM -0500, David Harrington wrote: > I think we need two *registered* ports, and I recommend requesting > 5161 and 5162. This sounds like a good concensus position. WG members should speak up now if they disagree with this resolution. /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 Thu Jan 22 00:04:53 2009 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 6F4A53A69E7; Thu, 22 Jan 2009 00:04:53 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD413A67B2 for ; Thu, 22 Jan 2009 00:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.092, 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 7IWm9y++d8na for ; Thu, 22 Jan 2009 00:04:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9E58D3A69E7 for ; Thu, 22 Jan 2009 00:04:51 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE352C0022; Thu, 22 Jan 2009 09:04:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SYMHAa9ethhn; Thu, 22 Jan 2009 09:04:29 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36124C0027; Thu, 22 Jan 2009 09:04:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3DAAC900D62; Thu, 22 Jan 2009 09:04:25 +0100 (CET) Date: Thu, 22 Jan 2009 09:04:25 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090122080425.GA966@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <0b9601c97be4$02a15fe0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0b9601c97be4$02a15fe0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] snmp subsystems 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, Jan 21, 2009 at 11:19:16AM -0500, David Harrington wrote: > If a notification originator opens a subsystem called "snmp" and a > command generator opens a subsystem called "snmp", will that be > confusing to SSH? Since there is developing concensus to use different ports, it seems there is no issue here. So I consider this closed. /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 Thu Jan 22 09:03:38 2009 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 1478128C22F; Thu, 22 Jan 2009 09:03:38 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F61128C22F for ; Thu, 22 Jan 2009 09:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.287, 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 KWROPcuHSiUw for ; Thu, 22 Jan 2009 09:03:36 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 6E0CF28C102 for ; Thu, 22 Jan 2009 09:03:36 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id AD49139A111; Thu, 22 Jan 2009 09:03:19 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com> <200901211950.n0LJoOxn000655@raisinbran.srv.cs.cmu.edu> <404AAA776ADF7CBE6A456DDA@atlantis.pc.cs.cmu.edu> Date: Thu, 22 Jan 2009 09:03:19 -0800 In-Reply-To: <404AAA776ADF7CBE6A456DDA@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 21 Jan 2009 15:11:52 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] IsmsSNMP SSH ports 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, 21 Jan 2009 15:11:52 -0500, Jeffrey Hutzelman said: >> Well, we can either do one well known port with two different service >> names or two well known ports each with the same service name. JH> What do you mean by "service name" here? An SSH subsystem name? Yep. JH> It seems to me that the right answer here is to define distinct JH> ports, I agree. I was laying out the options, but I do agree that using different ports would be better. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jan 22 11:47:51 2009 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 542563A6B5E; Thu, 22 Jan 2009 11:47:51 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2D73A6B78 for ; Thu, 22 Jan 2009 11:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.089, 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 zcAhvpDXzMe0 for ; Thu, 22 Jan 2009 11:47:50 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BBCB33A69E2 for ; Thu, 22 Jan 2009 11:47:49 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F256BC00D4; Thu, 22 Jan 2009 20:47:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id y6DpH-E0JNpX; Thu, 22 Jan 2009 20:47:27 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3CB8C0084; Thu, 22 Jan 2009 20:47:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E92C591756D; Thu, 22 Jan 2009 20:47:22 +0100 (CET) Date: Thu, 22 Jan 2009 20:47:22 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090122194722.GB7322@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <0b9501c97be4$024201d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0b9501c97be4$024201d0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] ssh authn 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, Jan 21, 2009 at 11:19:16AM -0500, David Harrington wrote: > In the following paragraph, is this all about server authn, or is > client and server authn mixed into this paragraph? > > Using tmTransportAddress, the client will establish an > SSH transport connection using the SSH transport protocol, > authenticate the server, and exchange keys for message > integrity and encryption. The tmTransportAddress field may > contain a user-name followed by an '@' character (ASCII 0x40) > that will indicate a specific user-name string that should be > presented to the ssh server as the "user name" for > authentication purposes. This MAY be different than the passed > tmSecurityName value that will be used in the remaining steps > below. If there is no specified user-name in the > tmTransportAddress then the tmSecurityName should be used > as the user-name. The other parameters of the transport > connection and the credentials used to authenticate the > server are provided in an implementation-dependent manner. I am not sure where your question is supposed to leads to. The text tells me that the user-name portion of the tmTransportAddress if present is used as the ssh user name instead of tmSecurityName. The user name is relevant for SSH client authentication, not for SSH server authentication. That said, I am still wondering what the reason behind your question is... /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 Thu Jan 22 12:42:53 2009 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 AF38228C1FA; Thu, 22 Jan 2009 12:42:53 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F4D28C1FA for ; Thu, 22 Jan 2009 12:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=-2.157, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, MANGLED_TOOL=2.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHFkhawNvnbD for ; Thu, 22 Jan 2009 12:42:41 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 20C2828C140 for ; Thu, 22 Jan 2009 12:42:41 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 6bTZ1b00A1GhbT851ki2ZB; Thu, 22 Jan 2009 20:42:02 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id 6kiP1b00i0UQ6dC3TkiQE0; Thu, 22 Jan 2009 20:42:25 +0000 From: "David Harrington" To: Date: Thu, 22 Jan 2009 15:42:22 -0500 Message-ID: <0ca901c97cd1$ed7310c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0CAA_01C97CA8.049D08C0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl80ey9fptxQYwDTI+AwzUnnFQpqA== Subject: [Isms] secshell-pre14 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0CAA_01C97CA8.049D08C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is an updated draft for secshell. We still need work on 1) the processes for client versus server 2) two ports otherwise I think I have covered all the WGLC comments David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0CAA_01C97CA8.049D08C0 Content-Type: text/plain; name="draft-ietf-isms-secshell-pre14.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-secshell-pre14.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Standards Track J. Salowey=0A= Expires: July 26, 2009 Cisco Systems=0A= W. Hardaker=0A= Sparta, Inc.=0A= January 22, 2009=0A= =0A= =0A= Secure Shell Transport Model for SNMP=0A= draft-ietf-isms-secshell-14=0A= =0A= Status of This Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on July 26, 2009.=0A= =0A= Abstract=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 1]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 3=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 6=0A= 3. How SSHTM Fits into the Transport Subsystem . . . . . . . . . 7=0A= 3.1. Security Capabilities of this Model . . . . . . . . . . . 8=0A= 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 3.1.2. Message Authentication . . . . . . . . . . . . . . . . 9=0A= 3.1.3. Authentication Protocol Support . . . . . . . . . . . 10=0A= 3.1.4. SSH Subsystem . . . . . . . . . . . . . . . . . . . . 10=0A= 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 11=0A= 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 11=0A= 4. Cached Information and References . . . . . . . . . . . . . . 12=0A= 4.1. Secure Shell Transport Model Cached Information . . . . . 12=0A= 4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . . . 12=0A= 4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . . . 13=0A= 4.1.3. Session State . . . . . . . . . . . . . . . . . . . . 13=0A= 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 13=0A= 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 14=0A= 5.2. Procedures for sending an Outgoing Message . . . . . . . . 15=0A= 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 16=0A= 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 17=0A= 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 18=0A= 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 18=0A= 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 18=0A= 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 18=0A= 6.3.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 19=0A= 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 19=0A= 8. Operational Considerations . . . . . . . . . . . . . . . . . . 25=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26=0A= 9.1. Skipping Public Key Verification . . . . . . . . . . . . . 27=0A= 9.2. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 27=0A= 9.3. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 27=0A= 9.4. MIB Module Security . . . . . . . . . . . . . . . . . . . 28=0A= 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28=0A= 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29=0A= 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29=0A= 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29=0A= 12.2. Informative References . . . . . . . . . . . . . . . . . . 32=0A= Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 2]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH) [RFC4251]=0A= within a transport subsystem [I-D.ietf-isms-tmsm]. The transport=0A= model specified in this memo is referred to as the Secure Shell=0A= Transport Model (SSHTM).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= It is important to understand the SNMP architecture [RFC3411] and the=0A= terminology of the architecture to understand where the Transport=0A= Model described in this memo fits into the architecture and interacts=0A= with other subsystems within the architecture.=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications. This is=0A= consistent with the IESG decision to not require the SNMPv3=0A= terminology be modified to match the usage of other non-SNMP=0A= specifications when SNMPv3 was advanced to Full Standard.=0A= =0A= Authentication in this document typically refers to the English=0A= meaning of "serving to prove the authenticity of" the message, not=0A= data source authentication or peer identity authentication.=0A= =0A= The terms "manager" and "agent" are not used in this document,=0A= because in the RFC 3411 architecture [RFC3411], all SNMP entities=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 3]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= have the capability of acting in either manager or agent or in both=0A= roles depending on the SNMP application types supported in the=0A= implementation. Where distinction is required, the application names=0A= of Command Generator, Command Responder, Notification Originator,=0A= Notification Receiver, and Proxy Forwarder are used. See "SNMP=0A= Applications" [RFC3413] for further information.=0A= =0A= Throughout this document, the terms "client" and "server" are used to=0A= refer to the two ends of the SSH transport connection. The client=0A= actively opens the SSH connection, and the server passively listens=0A= for the incoming SSH connection. Either SNMP entity may act as=0A= client or as server, as discussed further below.=0A= =0A= The User-Based Security Model (USM) [RFC3414] is a mandatory-to-=0A= implement Security Model in STD 62. While SSH and USM frequently=0A= refer to a user, the terminology preferred in RFC3411 [RFC3411] and=0A= in this memo is "principal". A principal is the "who" on whose=0A= behalf services are provided or processing takes place. A principal=0A= can be, among other things, an individual acting in a particular=0A= role; a set of individuals, with each acting in a particular role; an=0A= application or a set of applications, or a combination of these=0A= within an administrative domain.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= Sections requiring further editing are identified by [todo] markers=0A= in the text. Points requiring further WG research and discussion are=0A= identified by [discuss] markers in the text.=0A= =0A= Note to RFC Editor - if the previous paragraph and this note have not=0A= been removed, please send the document back to the editor to remove=0A= this.=0A= =0A= 1.3. Modularity=0A= =0A= The reader is expected to have read and understood the description of=0A= the SNMP architecture, as defined in [RFC3411], and the Transport=0A= Subsystem architecture extension specified in "Transport Subsystem=0A= for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm].=0A= =0A= This memo describes the Secure Shell Transport Model for SNMP, a=0A= specific SNMP transport model to be used within the SNMP transport=0A= subsystem to provide authentication, encryption, and integrity=0A= checking of SNMP messages.=0A= =0A= In keeping with the RFC 3411 design decision to use self-contained=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 4]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= documents, this document defines the elements of procedure and=0A= associated MIB module objects which are needed for processing the=0A= Secure Shell Transport Model for SNMP.=0A= =0A= This modularity of specification is not meant to be interpreted as=0A= imposing any specific requirements on implementation.=0A= =0A= 1.4. Motivation=0A= =0A= Version 3 of the Simple Network Management Protocol (SNMPv3) added=0A= security to the protocol. The User-based Security Model (USM)=0A= [RFC3414] was designed to be independent of other existing security=0A= infrastructures, to ensure it could function when third party=0A= authentication services were not available, such as in a broken=0A= network. As a result, USM utilizes a separate user and key=0A= management infrastructure. Operators have reported that deploying=0A= another user and key management infrastructure in order to use SNMPv3=0A= is a reason for not deploying SNMPv3.=0A= =0A= This memo describes a transport model that will make use of the=0A= existing and commonly deployed Secure Shell security infrastructure.=0A= This transport model is designed to meet the security and operational=0A= needs of network administrators, maximize usability in operational=0A= environments to achieve high deployment success and at the same time=0A= minimize implementation and deployment costs to minimize deployment=0A= time.=0A= =0A= This document addresses the requirement for the SSH client to=0A= authenticate the SSH server, for the SSH server to authenticate the=0A= SSH client, and describes how SNMP can make use of the authenticated=0A= identities in authorization policies for data access, in a manner=0A= that is independent of any specific access control model.=0A= =0A= This document addresses the requirement to utilize client=0A= authentication and key exchange methods which support different=0A= security infrastructures and provide different security properties.=0A= This document describes how to use client authentication as described=0A= in "SSH Authentication Protocol" [RFC4252]. The SSH Transport Model=0A= should work with any of the ssh-userauth methods including the=0A= "publickey", "password", "hostbased", "none", "keyboard-interactive",=0A= "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx"=0A= (see http://www.iana.org/assignments/ssh-parameters). The use of the=0A= "none" authentication method is NOT RECOMMENDED, as described in=0A= Security Considerations. Local accounts may be supported through the=0A= use of the publickey, hostbased or password methods. The password=0A= method allows for integration with deployed password infrastructure=0A= such as AAA servers using the RADIUS protocol [RFC2865]. The SSH=0A= Transport Model SHOULD be able to take advantage of future defined=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 5]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= ssh-userauth methods, such as those that might make use of X.509=0A= certificate credentials.=0A= =0A= It is desirable to use mechanisms that could unify the approach for=0A= administrative security for SNMPv3 and Command Line interfaces (CLI)=0A= and other management interfaces. The use of security services=0A= provided by Secure Shell is the approach commonly used for the CLI,=0A= and is the approach being adopted for use with NETCONF [RFC4742].=0A= This memo describes a method for invoking and running the SNMP=0A= protocol within a Secure Shell (SSH) session as an SSH subsystem.=0A= =0A= This memo describes how SNMP can be used within a Secure Shell (SSH)=0A= session, using the SSH connection protocol [RFC4254] over the SSH=0A= transport protocol, using SSH user-auth [RFC4252] for authentication.=0A= =0A= There are a number of challenges to be addressed to map Secure Shell=0A= authentication method parameters into the SNMP architecture so that=0A= SNMP continues to work without any surprises. These are discussed in=0A= detail below.=0A= =0A= 1.5. Constraints=0A= =0A= The design of this SNMP Transport Model is influenced by the=0A= following constraints:=0A= =0A= 1. In times of network stress, the transport protocol and its=0A= underlying security mechanisms SHOULD NOT depend upon the ready=0A= availability of other network services (e.g., Network Time=0A= Protocol (NTP) or AAA protocols).=0A= =0A= 2. When the network is not under stress, the transport model and its=0A= underlying security mechanisms MAY depend upon the ready=0A= availability of other network services.=0A= =0A= 3. It may not be possible for the transport model to determine when=0A= the network is under stress.=0A= =0A= 4. A transport model should require no changes to the SNMP=0A= architecture.=0A= =0A= 5. A transport model should require no changes to the underlying=0A= protocol.=0A= =0A= 2. The Secure Shell Protocol=0A= =0A= SSH is a protocol for secure remote login and other secure network=0A= services over an insecure network. It consists of three major=0A= protocol components, and add-on methods for user authentication:=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 6]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= o The Transport Layer Protocol [RFC4253] provides server=0A= authentication, and message confidentiality and integrity. It may=0A= optionally also provide compression. The transport layer will=0A= typically be run over a TCP/IP connection, but might also be used=0A= on top of any other reliable data stream.=0A= =0A= o The User Authentication Protocol [RFC4252] authenticates the=0A= client-side principal to the server. It runs over the transport=0A= layer protocol.=0A= =0A= o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel=0A= into several logical channels. It runs over the transport after=0A= successfully authenticating the principal.=0A= =0A= o Generic Message Exchange Authentication [RFC4256] is a general=0A= purpose authentication method for the SSH protocol, suitable for=0A= interactive authentications where the authentication data should=0A= be entered via a keyboard=0A= =0A= o Generic Security Service Application Program Interface (GSS-API)=0A= Authentication and Key Exchange for the Secure Shell (SSH)=0A= Protocol [RFC4462] describes methods for using the GSS-API for=0A= authentication and key exchange in SSH. It defines an SSH user=0A= authentication method that uses a specified GSS-API mechanism to=0A= authenticate a user, and a family of SSH key exchange methods that=0A= use GSS-API to authenticate a Diffie-Hellman key exchange.=0A= =0A= The client sends a service request once a secure transport layer=0A= connection has been established. A second service request is sent=0A= after client authentication is complete. This allows new protocols=0A= to be defined and coexist with the protocols listed above.=0A= =0A= The connection protocol provides channels that can be used for a wide=0A= range of purposes. Standard methods are provided for setting up=0A= secure interactive shell sessions and for forwarding ("tunneling")=0A= arbitrary TCP/IP ports and X11 connections.=0A= =0A= 3. How SSHTM Fits into the Transport Subsystem=0A= =0A= A transport model is a component of the Transport Subsystem=0A= [I-D.ietf-isms-tmsm] within the SNMP architecture. The SSH Transport=0A= Model thus fits between the underlying SSH transport layer and the=0A= message dispatcher [RFC3411].=0A= =0A= The SSH Transport Model will establish a channel between itself and=0A= the SSH Transport Model of another SNMP engine. The sending=0A= transport model passes unencrypted messages from the dispatcher to=0A= SSH to be encrypted, and the receiving transport model accepts=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 7]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= decrypted incoming messages from SSH and passes them to the=0A= dispatcher.=0A= =0A= After an SSH Transport model channel is established, then SNMP=0A= messages can conceptually be sent through the channel from one SNMP=0A= message dispatcher to another SNMP message dispatcher. Multiple SNMP=0A= messages MAY be passed through the same channel.=0A= =0A= The SSH Transport Model of an SNMP engine will perform the=0A= translation between SSH-specific security parameters and SNMP-=0A= specific, model-independent parameters.=0A= =0A= 3.1. Security Capabilities of this Model=0A= =0A= 3.1.1. Threats=0A= =0A= The Secure Shell Transport Model provides protection against the=0A= threats identified by the RFC 3411 architecture [RFC3411]:=0A= =0A= 1. Modification of Information - SSH provides for verification that=0A= the contents of each message has not been modified during its=0A= transmission through the network, by digitally signing each SSH=0A= packet.=0A= =0A= 2. Masquerade - SSH provides for verification of the identity of the=0A= SSH server and the identity of the SSH client.=0A= =0A= SSH provides for verification of the identity of the SSH server=0A= through the SSH Transport Protocol server authentication=0A= ([RFC4253]). This allows an operator or management station to=0A= ensure the authenticity of the SNMP engine that provides MIB=0A= data.=0A= =0A= SSH provides a number of mechanisms for verification of the=0A= identity of the SSH client-side principal, using the Secure Shell=0A= Authentication Protocol ([RFC4252]). These include public key,=0A= password and host-based mechanisms. This allows the SNMP access=0A= control subsystem to ensure that only authorized principals have=0A= access to potentially sensitive data.=0A= =0A= Verification of client's principal identity is important for use=0A= with the SNMP access control subsystem, to ensure that only=0A= authorized principals have access to potentially sensitive data.=0A= The SSH user identity is provided to the transport model, so it=0A= can be used to map to an SNMP model-independent securityName for=0A= use with SNMP access control and notification configuration.=0A= (The identity may undergo various transforms before it maps to=0A= the securityName.)=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 8]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= 3. Message Stream Modification - SSH protects against malicious re-=0A= ordering or replaying of messages within a single SSH session by=0A= using sequence numbers and integrity checks. SSH protects=0A= against replay of messages across SSH sessions by ensuring that=0A= the cryptographic keys used for encryption and integrity checks=0A= are generated afresh for each session.=0A= =0A= 4. Disclosure - SSH provides protection against the disclosure of=0A= information to unauthorized recipients or eavesdroppers by=0A= allowing for encryption of all traffic between SNMP engines.=0A= =0A= 3.1.2. Message Authentication=0A= =0A= The RFC 3411 architecture recognizes three levels of security:=0A= =0A= - without authentication and without privacy (noAuthNoPriv)=0A= =0A= - with authentication but without privacy (authNoPriv)=0A= =0A= - with authentication and with privacy (authPriv)=0A= =0A= The Secure Shell protocol provides support for encryption and data=0A= integrity. While it is technically possible to support no=0A= authentication and no encryption in SSH it is NOT RECOMMENDED by=0A= [RFC4253].=0A= =0A= The SSH Transport Model determines from SSH the identity of the=0A= authenticated principal, and the type and address associated with an=0A= incoming message, and provides this information to SSH for an=0A= outgoing message. The transport layer algorithms used to provide=0A= authentication, data integrity and encryption SHOULD NOT be exposed=0A= to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided=0A= this and settled for an assertion by the security model that the=0A= requirements of securityLevel were met The SSH Transport Model has no=0A= mechanisms by which it can test whether an underlying SSH connection=0A= provides auth or priv, so the SSH Transport Model trusts that the=0A= underlying SSH connection has been properly configured to support=0A= authPriv security characteristics.=0A= =0A= An SSH Transport Model-compliant implementation MUST use an SSH=0A= connection that provides authentication, data integrity and=0A= encryption that meets the highest level of SNMP security (authPriv).=0A= Outgoing messages specified with a securityLevel of noAuthNoPriv or=0A= authNoPriv, are actually sent by the SSH Transport Model with=0A= authPriv-level protection.=0A= =0A= The security protocols used in the Secure Shell Authentication=0A= Protocol [RFC4252] and the Secure Shell Transport Layer Protocol=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 9]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= [RFC4253] are considered acceptably secure at the time of writing.=0A= However, the procedures allow for new authentication and privacy=0A= methods to be specified at a future time if the need arises.=0A= =0A= 3.1.3. Authentication Protocol Support=0A= =0A= The SSH Transport Model should support any server or client=0A= authentication mechanism supported by SSH. This includes the three=0A= authentication methods described in the SSH Authentication Protocol=0A= document [RFC4252] - publickey, password, and host-based - and=0A= keyboard interactive and others.=0A= =0A= The password authentication mechanism allows for integration with=0A= deployed password based infrastructure. It is possible to hand a=0A= password to a service such as RADIUS [RFC2865] or Diameter [RFC3588]=0A= for validation. The validation could be done using the user-name and=0A= user-password attributes. It is also possible to use a different=0A= password validation protocol such as CHAP [RFC1994] or digest=0A= authentication [RFC5090] to integrate with RADIUS or Diameter. At=0A= some point in the processing, these mechanisms require the password=0A= be made available as clear text on the device that is authenticating=0A= the password which might introduce threats to the authentication=0A= infrastructure.=0A= =0A= GSSKeyex [RFC4462] provides a framework for the addition of client=0A= authentication mechanisms which support different security=0A= infrastructures and provide different security properties.=0A= Additional authentication mechanisms, such as one that supports X.509=0A= certificates, may be added to SSH in the future.=0A= =0A= 3.1.4. SSH Subsystem=0A= =0A= This document describes the use of an SSH subsystem for SNMP to make=0A= SNMP usage distinct from other usages.=0A= =0A= An SSH subsystem of type "snmp" is opened by the SSH Transport Model=0A= during the elements of procedure for an outgoing SNMP message. Since=0A= the sender of a message initiates the creation of an SSH session if=0A= needed, the SSH session will already exist for an incoming message or=0A= the incoming message would never reach the SSH Transport Model.=0A= =0A= Implementations MAY choose to instantiate SSH sessions in=0A= anticipation of outgoing messages. This approach might be useful to=0A= ensure that an SSH session to a given target can be established=0A= before it becomes important to send a message over the SSH session.=0A= Of course, there is no guarantee that a pre-established session will=0A= still be valid when needed.=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 10]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= SSH sessions are uniquely identified within the SSH Transport Model=0A= by the combination of tmTransportAddress and tmSecurityName=0A= associated with each session.=0A= =0A= 3.2. Security Parameter Passing=0A= =0A= For incoming messages, SSH-specific security parameters are=0A= translated by the transport model into security parameters=0A= independent of the transport and security models. The transport=0A= model accepts messages from the SSH subsystem, and records the=0A= transport-related and SSH-security-related information, including the=0A= authenticated identity, in a cache referenced by tmStateReference,=0A= and passes the WholeMsg and the tmStateReference to the dispatcher=0A= using the receiveMessage() ASI (Application Service Interface).=0A= =0A= For outgoing messages, the transport model takes input provided by=0A= the dispatcher in the sendMessage() ASI. The SSH Transport Model=0A= converts that information into suitable security parameters for SSH,=0A= establishes sessions as needed, and passes messages to the SSH=0A= subsystem for sending.=0A= =0A= 3.3. Notifications and Proxy=0A= =0A= SSH connections may be initiated by command generators or by=0A= notification originators. Command generators are frequently operated=0A= by a human, but notification originators are usually unmanned=0A= automated processes. As a result, it may be necessary to provision=0A= authentication credentials on the SNMP engine containing the=0A= notification originator, or use a third party key provider such as=0A= Kerberos, so the engine can successfully authenticate to an engine=0A= containing a notification receiver.=0A= =0A= The targets to whom notifications or proxy requests should be sent is=0A= typically determined and configured by a network administrator. The=0A= SNMP-TARGET-MIB module [RFC3413] contains objects for defining=0A= management targets, including transport domains and addresses and=0A= security parameters, for applications such as notification generators=0A= and proxy forwarders.=0A= =0A= For the SSH Transport Model, transport type and address are=0A= configured in the snmpTargetAddrTable, and the securityName, and=0A= securityLevel parameters are configured in the snmpTargetParamsTable.=0A= The default approach is for an administrator to statically=0A= preconfigure this information to identify the targets authorized to=0A= receive notifications or perform proxy.=0A= =0A= These MIB modules may be configured using SNMP or other=0A= implementation-dependent mechanisms, such as CLI scripting or loading=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 11]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= a configuration file. It may be necessary to provide additional=0A= implementation-specific configuration of SSH parameters.=0A= =0A= 4. Cached Information and References=0A= =0A= When performing SNMP processing, there are two levels of state=0A= information that may need to be retained: the immediate state linking=0A= a request-response pair, and potentially longer-term state relating=0A= to transport and security. "Transport Subsystem for the Simple=0A= Network Management Protocol" [I-D.ietf-isms-tmsm] defines general=0A= requirements for caches and references.=0A= =0A= This document defines additional cache requirements related to the=0A= Secure Shell Transport Model.=0A= =0A= 4.1. Secure Shell Transport Model Cached Information=0A= =0A= The Secure Shell Transport Model has specific responsibilities=0A= regarding the cached information. See the Elements of Procedure in=0A= Section 5 for detailed processing instructions on the use of the=0A= tmStateReference fields by the SSH Transport Model.=0A= =0A= 4.1.1. tmSecurityName=0A= =0A= The tmSecurityName MUST be a human-readable name (in snmpAdminString=0A= format) representing the identity that has been set according to the=0A= procedures in Section 5.=0A= =0A= On the SSH server side of a connection:=0A= =0A= The tmSecurityName SHOULD be the value of the user name field of=0A= the SSH_MSG_USERAUTH_REQUEST message for which a=0A= SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH user name is=0A= extracted from the SSH layer is implementation-dependent.=0A= =0A= The SSH protocol is not always clear on whether the user name=0A= field must be filled in, so for some implementations, such as=0A= those using GSSAPI authentication, it may be necessary to use a=0A= mapping algorithm to transform an SSH identity to a=0A= tmSecurityName, or to transform a tmSecurityName to an SSH=0A= identity.=0A= =0A= In other cases the user name may not be verified by the server, so=0A= for these implementations, it may be necessary to obtain the user=0A= name from other credentials exchanged during the SSH exchange.=0A= =0A= On the SSH client side of a connection:=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 12]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= The tmSecurityName is presented to the SSH Transport Model by the=0A= application (possibly because of configuration specified in the=0A= SNMP-TARGET-MIB).=0A= =0A= The securityName MAY be derived from the tmSecurityName by a security=0A= model, and MAY be used to configure notifications and access=0A= controls. Transport models SHOULD generate a predictable=0A= tmSecurityName.=0A= =0A= 4.1.2. tmSessionID=0A= =0A= The tmSessionID MUST be recorded per message at the time of receipt.=0A= When tmSameSecurity is set, the recorded tmSessionID can be used to=0A= determine whether the SSH session available for sending a=0A= corresponding outgoing message is the same SSH session as was used=0A= when receiving the incoming message (e.g., a response to a request).=0A= =0A= 4.1.3. Session State=0A= =0A= The per-session state that is referenced by tmStateReference may be=0A= saved across multiple messages in a Local Configuration Datastore.=0A= Additional session/connection state information might also be stored=0A= in a Local Configuration Datastore.=0A= =0A= 5. Elements of Procedure=0A= =0A= Abstract service interfaces have been defined by [RFC3411] and=0A= further augmented by [I-D.ietf-isms-tmsm] to describe the conceptual=0A= data flows between the various subsystems within an SNMP entity. The=0A= Secure Shell Transport Model uses some of these conceptual data flows=0A= when communicating between subsystems.=0A= =0A= To simplify the elements of procedure, the release of state=0A= information is not always explicitly specified. As a general rule,=0A= if state information is available when a message gets discarded, the=0A= message-state information should also be released, and if state=0A= information is available when a session is closed, the session state=0A= information should also be released.=0A= =0A= An error indication in statusInformation will typically include the=0A= OID and value for an incremented error counter. This may be=0A= accompanied by the requested securityLevel, and the tmStateReference.=0A= Per-message context information is not accessible to Transport=0A= Models, so for the returned counter OID and value contextEngine would=0A= be set to the local value of snmpEngineID, and contextName to the=0A= default context for error counters.=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 13]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= 5.1. Procedures for an Incoming Message=0A= =0A= 1. The SSH Transport Model queries the SSH engine, in an=0A= implementation-dependent manner, to determine the=0A= transportAddress, the principal name authenticated by SSH, and a=0A= session identifier.=0A= =0A= By default on the server side of a SSH connection, the principal=0A= name is the value of the user name field of the=0A= SSH_MSG_USERAUTH_REQUEST message for which a=0A= SSH_MSG_USERAUTH_SUCCESS has been sent. How this name is=0A= extracted from the SSH environment is implementation-dependent.=0A= =0A= 2. Create a tmStateReference cache for subsequent reference to the=0A= information.=0A= =0A= tmTransportDomain =3D snmpSSHDomain=0A= =0A= tmTransportAddress =3D the address the message originated from,=0A= determined in an implementation-dependent way=0A= =0A= tmTransportSecurityLevel =3D "authPriv" (authentication and=0A= confidentiality MUST be used to comply with this transport=0A= model.)=0A= =0A= tmSecurityName =3D the ssh principal name received by the SSH=0A= server or sent from a SSH client.=0A= =0A= tmSessionID =3D an implementation-dependent value that can be=0A= used to detect when a session has closed and been replaced by=0A= another session. The value in tmStateReference should=0A= identify the session over which the message was received.=0A= =0A= Then the Transport model passes the message to the Dispatcher using=0A= the following ASI:=0A= =0A= statusInformation =3D=0A= receiveMessage(=0A= IN transportDomain -- snmpSSHDomain=0A= IN transportAddress -- address for the received message=0A= IN wholeMessage -- the whole SNMP message from SSH=0A= IN wholeMessageLength -- the length of the SNMP message=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 14]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= 5.2. Procedures for sending an Outgoing Message=0A= =0A= The Dispatcher passes the information to the Transport Model using=0A= the ASI defined in the transport subsystem:=0A= =0A= =0A= statusInformation =3D=0A= sendMessage(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN outgoingMessage -- the message to send=0A= IN outgoingMessageLength -- its length=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= The SSH Transport Model performs the following tasks.=0A= =0A= 1. If tmStateReference does not refer to a cache containing values=0A= for tmTransportDomain, tmTransportAddress, tmSecurityName,=0A= tmRequestedSecurityLevel, and tmSameSecurity, then increment the=0A= sshtmSessionInvalidCaches counter, discard the message and return=0A= the error indication in the statusInformation. Processing of=0A= this message stops.=0A= =0A= 2. Extract the tmTransportDomain, tmTransportAddress,=0A= tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and=0A= tmSessionID from the tmStateReference.=0A= =0A= 3. If tmSameSecurity is true and there is no existing session with=0A= the same sessionID as tmSessionID, then increment the=0A= sshtmSessionNoAvailableSessions counter, discard the message and=0A= return the error indication in the statusInformation. Processing=0A= of this message stops.=0A= =0A= 4. If there is no existing session corresponding to the=0A= tmTransportAddress and tmSecurityName, then call openSession()=0A= with the tmStateReference as a parameter. If OpenSession fails,=0A= then discard the message, release tmStateReference and pass the=0A= error indication returned by OpenSession back to the calling=0A= module. Processing stops for this message.=0A= =0A= 5. Pass the wholeMessage to SSH for encapsulation as data in an SSH=0A= message over the specified SSH session. Any necessary additional=0A= SSH-specific parameters should be provided in an implementation-=0A= dependent manner.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 15]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= 5.3. Establishing a Session=0A= =0A= The Secure Shell Transport Model provides the following abstract=0A= service interface (ASI) to describe the data passed between the SSH=0A= Transport Model and the SSH service. It is an implementation=0A= decision how such data is passed.=0A= =0A= statusInformation =3D=0A= openSession(=0A= IN tmStateReference -- transport information to be used=0A= OUT tmStateReference -- transport information to be used=0A= IN maxMessageSize -- of the sending SNMP entity=0A= )=0A= =0A= =0A= The following describes the procedure to follow to establish a=0A= session between a client and server to run SNMP over SSH. This=0A= process is used by any SNMP engine establishing a session for=0A= subsequent use.=0A= =0A= This will be done automatically for an SNMP application that=0A= initiates a transaction, such as a Command Generator or a=0A= Notification Originator or a Proxy Forwarder.=0A= =0A= 1. Increment the sshtmSessionOpens counter.=0A= =0A= 2. (To authenticate the server, the client usually stores=0A= (tmTransportAddress, server host public key) pairs in an=0A= implementation-dependent manner.)=0A= =0A= 3. Using tmTransportAddress, the client will establish an SSH=0A= transport connection using the SSH transport protocol,=0A= authenticate the server, and exchange keys for message integrity=0A= and encryption. The tmTransportAddress field may contain a user-=0A= name followed by an '@' character (ASCII 0x40) that will indicate=0A= a specific user-name string that should be presented to the ssh=0A= server as the "user name" for authentication purposes. This MAY=0A= be different than the passed tmSecurityName value that will be=0A= used in the remaining steps below. If there is no specified=0A= user-name in the tmTransportAddress then the tmSecurityName=0A= should be used as the user-name. The other parameters of the=0A= transport connection and the credentials used to authenticate the=0A= server are provided in an implementation-dependent manner.=0A= =0A= If the attempt to establish a connection is unsuccessful, or=0A= server authentication fails, then sshtmSessionOpenErrors is=0A= incremented, an openSession error indication is returned, and=0A= openSession processing stops.=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 16]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= 4. In an implementation-specific manner, pass the calculated user-=0A= name from step 1 to the SSH layer. The client will then invoke=0A= an SSH authentication service to authenticate the principal, such=0A= as that described in the SSH authentication protocol [RFC4252].=0A= The credentials used to authenticate the SSH principal are=0A= determined in an implementation-dependent manner.=0A= =0A= 5. If the authentication is unsuccessful, then the transport=0A= connection is closed, the sshtmSessionUserAuthFailures counter is=0A= incremented, an error indication is returned to the calling=0A= module, and processing stops for this message.=0A= =0A= 6. Once the principal has been successfully authenticated, the=0A= client should invoke the "ssh-connection" service (also known as=0A= the SSH connection protocol [RFC4254]), request a channel of type=0A= "session" in an implementation-dependent manner. If=0A= unsuccessful, the transport connection is closed, the=0A= sshtmSessionChannelOpenFailures counter is incremented, an error=0A= indication is returned to the calling module, and processing=0A= stops for this message.=0A= =0A= 7. Once the SSH session has been established, the client will invoke=0A= "snmp" as an SSH subsystem, as indicated in the "subsystem"=0A= parameter. If unsuccessful, the transport connection is closed,=0A= the sshtmSessionUnavailableSubsystems counter is incremented, an=0A= error indication is returned to the calling module, and=0A= processing stops for this message.=0A= =0A= In order to allow SNMP traffic to be easily identified and=0A= filtered by firewalls and other network devices, servers=0A= associated with SNMP entities using the Secure Shell Transport=0A= Model MUST default to providing access to the "snmp" SSH=0A= subsystem if the SSH session is established using the IANA-=0A= assigned TCP ports (YYY and ZZZ). Servers SHOULD be configurable=0A= to allow access to the SNMP SSH subsystem over other ports.=0A= =0A= 8. If successful, this will result in an SSH session. Set=0A= tmSessionID to an implementation-dependent value to identify the=0A= session.=0A= =0A= 5.4. Closing a Session=0A= =0A= The Secure Shell Transport Model provides the following ASI to close=0A= a session:=0A= =0A= statusInformation =3D=0A= closeSession(=0A= IN tmSessionID -- transport address to be used=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 17]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= )=0A= =0A= =0A= =0A= The following describes the procedure to follow to close a session=0A= between a client and server . This process is followed by any SNMP=0A= engine to close an SSH session. It is implementation-dependent when=0A= a session should be closed. The calling code should release the=0A= associated tmStateReference.=0A= =0A= 1. Increment the sshtmSessionCloses counter.=0A= =0A= 2. If there is no session corresponding to tmSessionID, then=0A= closeSession processing is completed.=0A= =0A= 3. Have SSH close the session associated with tmSessionID.=0A= =0A= 6. MIB Module Overview=0A= =0A= This MIB module provides management of the Secure Shell Transport=0A= Model. It defines an OID to identify the SNMP-over-SSH transport=0A= domain, a textual convention for SSH Addresses and several statistics=0A= counters.=0A= =0A= 6.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= 6.2. Textual Conventions=0A= =0A= Generic and Common Textual Conventions used in this document can be=0A= found summarized at http://www.ops.ietf.org/mib-common-tcs.html=0A= =0A= 6.3. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing the SSH Transport Model. In particular, it=0A= is assumed that an entity implementing the SSHTM-MIB will implement=0A= the SNMPv2-MIB [RFC3418], and the SNMP-FRAMEWORK-MIB [RFC3411]. It=0A= is expected that an entity implementing this MIB will also support=0A= the Transport Security Model=0A= [I-D.ietf-isms-transport-security-model], and therefore implement the=0A= SNMP-TSM-MIB.=0A= =0A= This MIB module is for monitoring SSH Transport Model information.=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 18]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= 6.3.1. MIB Modules Required for IMPORTS=0A= =0A= The following MIB module imports items from [RFC2578], [RFC2579],=0A= [RFC2580].=0A= =0A= This MIB module also references [RFC3490] and [RFC3986]=0A= =0A= 7. MIB Module Definition=0A= =0A= =0A= SSHTM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= OBJECT-IDENTITY, mib-2, snmpDomains,=0A= Counter32=0A= FROM SNMPv2-SMI=0A= TEXTUAL-CONVENTION=0A= FROM SNMPv2-TC=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= ;=0A= =0A= sshtmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200810130000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= quittek@netlab.nec.de=0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Co-editors:=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 19]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= David Harrington=0A= Huawei Technologies USA=0A= 1700 Alma Drive=0A= Plano Texas 75075=0A= USA=0A= +1 603-436-8634=0A= ietfdbh@comcast.net=0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= jsalowey@cisco.com=0A= =0A= Wes Hardaker=0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= USA=0A= +1 530 792 1913=0A= ietf@hardakers.net=0A= "=0A= DESCRIPTION "The Secure Shell Transport Model MIB=0A= =0A= Copyright (C) The IETF Trust (2008). This=0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200810130000Z"=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- ---------------------------------------------------------- --=0A= -- subtrees in the SNMP-SSH-TM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= sshtmNotifications OBJECT IDENTIFIER ::=3D { sshtmMIB 0 }=0A= sshtmObjects OBJECT IDENTIFIER ::=3D { sshtmMIB 1 }=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 20]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= sshtmConformance OBJECT IDENTIFIER ::=3D { sshtmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= snmpSSHDomain OBJECT-IDENTITY=0A= STATUS current=0A= DESCRIPTION=0A= "The SNMP over SSH transport domain. The corresponding transport=0A= address is of type SnmpSSHAddress.=0A= =0A= When an SNMP entity uses the snmpSSHDomain transport=0A= model, it must be capable of accepting messages up to=0A= and including 8192 octets in size. Implementation of=0A= larger values is encouraged whenever possible.=0A= =0A= The securityName prefix to be associated with the=0A= snmpSSHDomain is 'ssh'. This prefix may be used by security=0A= models or other components to identify what secure transport=0A= infrastructure authenticated a securityName."=0A= ::=3D { snmpDomains yy }=0A= =0A= -- RFC Ed.: Please replace the I-D reference with a proper one once it=0A= -- has been published.=0A= =0A= -- RFC Ed.: replace yy with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- RFC Ed.: replace 'ssh' with the actual IANA assigned prefix string=0A= -- if 'ssh' is not assigned to this document.=0A= =0A= SnmpSSHAddress ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "1a"=0A= STATUS current=0A= DESCRIPTION=0A= "Represents either a hostname or IP address, along with a port=0A= number and an optional username.=0A= =0A= The beginning of the address specification may contain a=0A= username followed by an '@' (ASCII character 0x40). This=0A= portion of the address will indicate the user name that should=0A= be used when authenticating to an SSH server. If missing, the=0A= SNMP securityName should be used. After the optional user name=0A= field and '@' character comes the hostname or IP address.=0A= =0A= The hostname must be encoded in ASCII, as specified in=0A= RFC3490 (Internationalizing Domain Names in Applications)=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 21]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= followed by a colon ':' (ASCII character 0x3A) and a=0A= decimal port number in ASCII. The name SHOULD be fully=0A= qualified whenever possible.=0A= =0A= An IPv4 address must be in dotted decimal format followed=0A= by a colon ':' (ASCII character 0x3A) and a decimal port=0A= number in ASCII.=0A= =0A= An IPv6 address must be in colon separated format, surrounded=0A= by square brackets ('[' ASCII character 0x5B and ']' ASCII=0A= character 0x5D), followed by a colon ':' (ASCII character=0A= 0x3A) and a decimal port number in ASCII.=0A= =0A= Values of this textual convention might not be directly useable=0A= as transport-layer addressing information, and may require=0A= runtime resolution. As such, applications that write them=0A= must be prepared for handling errors if such values are=0A= not supported, or cannot be resolved (if resolution occurs=0A= at the time of the management operation).=0A= =0A= The DESCRIPTION clause of TransportAddress objects that may=0A= have snmpSSHAddress values must fully describe how (and=0A= when) such names are to be resolved to IP addresses and vice=0A= versa.=0A= =0A= This textual convention SHOULD NOT be used directly in=0A= object definitions since it restricts addresses to a=0A= specific format. However, if it is used, it MAY be used=0A= either on its own or in conjunction with=0A= TransportAddressType or TransportDomain as a pair.=0A= =0A= When this textual convention is used as a syntax of an=0A= index object, there may be issues with the limit of 128=0A= sub-identifiers specified in SMIv2, STD 58. It is=0A= RECOMMENDED that all MIB documents using this textual=0A= convention make explicit any limitations on index=0A= component lengths that management software must observe.=0A= This may be done either by including SIZE constraints on=0A= the index components or by specifying applicable=0A= constraints in the conceptual row DESCRIPTION clause or=0A= in the surrounding documentation.=0A= "=0A= REFERENCE=0A= "RFC3986, Uniform Resource Identifier (URI): Generic Syntax"=0A= SYNTAX OCTET STRING (SIZE (1..255))=0A= =0A= =0A= -- The sshtmSession Group=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 22]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= sshtmSession OBJECT IDENTIFIER ::=3D { sshtmObjects 1 }=0A= =0A= sshtmSessionOpens OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request has been=0A= executed as an SSH client, whether it succeeded or=0A= failed.=0A= "=0A= ::=3D { sshtmSession 1 }=0A= =0A= sshtmSessionCloses OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times a closeSession() request has been=0A= executed as an SSH client, whether it succeeded or=0A= failed.=0A= "=0A= ::=3D { sshtmSession 2 }=0A= =0A= sshtmSessionOpenErrors OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client, for any=0A= reason.=0A= "=0A= ::=3D { sshtmSession 3 }=0A= =0A= sshtmSessionUserAuthFailures OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client due to user=0A= authentication failures.=0A= "=0A= ::=3D { sshtmSession 4 }=0A= =0A= sshtmSessionChannelOpenFailures OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client due to=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 23]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= channel open failures.=0A= "=0A= ::=3D { sshtmSession 5 }=0A= =0A= sshtmSessionUnavailableSubsystems OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client due to=0A= inability to connect to the requested subsystem.=0A= "=0A= ::=3D { sshtmSession 6 }=0A= =0A= sshtmSessionNoAvailableSessions OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an outgoing message=0A= was dropped because the same=0A= session was no longer available.=0A= "=0A= ::=3D { sshtmSession 7 }=0A= =0A= sshtmSessionInvalidCaches OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of outgoing messages dropped because the=0A= tmStateReference referred to an invalid cache.=0A= "=0A= ::=3D { sshtmSession 8 }=0A= =0A= -- ************************************************=0A= -- sshtmMIB - Conformance Information=0A= -- ************************************************=0A= =0A= sshtmCompliances OBJECT IDENTIFIER ::=3D { sshtmConformance 1 }=0A= =0A= sshtmGroups OBJECT IDENTIFIER ::=3D { sshtmConformance 2 }=0A= =0A= -- ************************************************=0A= -- Compliance statements=0A= -- ************************************************=0A= =0A= sshtmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 24]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= DESCRIPTION "The compliance statement for SNMP engines that=0A= support the SNMP-SSH-TM-MIB"=0A= MODULE=0A= MANDATORY-GROUPS { sshtmGroup }=0A= ::=3D { sshtmCompliances 1 }=0A= =0A= -- ************************************************=0A= -- Units of conformance=0A= -- ************************************************=0A= sshtmGroup OBJECT-GROUP=0A= OBJECTS {=0A= sshtmSessionOpens,=0A= sshtmSessionCloses,=0A= sshtmSessionOpenErrors,=0A= sshtmSessionUserAuthFailures,=0A= sshtmSessionChannelOpenFailures,=0A= sshtmSessionUnavailableSubsystems,=0A= sshtmSessionNoAvailableSessions=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining=0A= information of an SNMP engine which implements the=0A= SNMP Secure Shell Transport Model.=0A= "=0A= =0A= =0A= ::=3D { sshtmGroups 2 }=0A= =0A= =0A= END=0A= =0A= =0A= 8. Operational Considerations=0A= =0A= The SSH Transport Model will likely not work in conditions where=0A= access to the CLI has stopped working. In situations where SNMP=0A= access has to work when the CLI has stopped working, a UDP transport=0A= model should be considered instead of the SSH Transport Model.=0A= =0A= If the SSH Transport Model is configured to utilize AAA services,=0A= operators should consider configuring support for local=0A= authentication mechanisms, such as local passwords, so SNMP can=0A= continue operating during times of network stress.=0A= =0A= The SSH protocol has its own window mechanism, defined in RFC 4254.=0A= The SSH specifications leave it open when window adjustments messages=0A= should be created, and some implementations send these whenever=0A= received data has been passed to the application. There are=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 25]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= noticeable bandwidth and processing overheads to handling such window=0A= adjustment messages, which can be avoided by sending them less=0A= frequently.=0A= =0A= The SSH protocol requires the execution of CPU intensive calculations=0A= to establish a session key during session establishment. This means=0A= that short lived sessions become computationally expensive compared=0A= to USM, which does not have a notion of a session key. Other=0A= transport security protocols such as TLS support a session resumption=0A= feature that allows reusing a cached session key. Such a mechanism=0A= does not exist for SSH and thus SNMP applications should keep SSH=0A= sessions for longer time periods.=0A= =0A= To initiate SSH connections, an entity must be configured with SSH=0A= client credentials plus information to authenticate the server.=0A= While hosts are often configured to be SSH clients, most=0A= internetworking devices are not. To send notifications over SSHTM,=0A= the internetworking device will need to be configured as an SSH=0A= client. How this credential configuration is done is implementation=0A= and deployment specific.=0A= =0A= 9. Security Considerations=0A= =0A= This document describes a transport model that permits SNMP to=0A= utilize SSH security services. The security threats and how the SSH=0A= Transport Model mitigates those threats is covered in detail=0A= throughout this memo.=0A= =0A= The SSH Transport Model relies on SSH mutual authentication, binding=0A= of keys, confidentiality and integrity. Any authentication method=0A= that meets the requirements of the SSH architecture will provide the=0A= properties of mutual authentication and binding of keys.=0A= =0A= SSHv2 provides Perfect Forward Security (PFS) for encryption keys.=0A= PFS is a major design goal of SSH, and any well-designed keyex=0A= algorithm will provide it.=0A= =0A= The security implications of using SSH are covered in [RFC4251].=0A= =0A= The SSH Transport Model has no way to verify that server=0A= authentication was performed, to learn the host's public key in=0A= advance, or verify that the correct key is being used. The SSH=0A= Transport Model simply trusts that these are properly configured by=0A= the implementer and deployer.=0A= =0A= SSH provides the "none" userauth method. The SSH Transport Model=0A= MUST NOT be used with an SSH connection with the "none" userauth=0A= method. While SSH does support turning off confidentiality and=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 26]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= integrity, they MUST NOT be turned off when used with the SSH=0A= Transport Model.=0A= =0A= The SSH protocol is not always clear on whether the user name field=0A= must be filled in, so for some implementations, such as those using=0A= GSSAPI authentication, it may be necessary to use a mapping algorithm=0A= to transform an SSH identity to a tmSecurityName, or to transform a=0A= tmSecurityName to an SSH identity.=0A= =0A= In other cases the user name may not be verified by the server, so=0A= for these implementations, it may be necessary to obtain the user=0A= name from other credentials exchanged during the SSH exchange.=0A= =0A= 9.1. Skipping Public Key Verification=0A= =0A= Most key exchange algorithms are able to authenticate the SSH=0A= server's identity to the client. However, for the common case of DH=0A= signed by public keys, this requires the client to know the host's=0A= public key a priori and to verify that the correct key is being used.=0A= If this step is skipped, then authentication of the SSH server to the=0A= SSH client is not done. Data confidentiality and data integrity=0A= protection to the server still exist, but these are of dubious value=0A= when an attacker can insert himself between the client and the real=0A= SSH server. Note that some userauth methods may defend against this=0A= situation, but many of the common ones (including password and=0A= keyboard-interactive) do not, and in fact depend on the fact that the=0A= server's identity has been verified (so passwords are not disclosed=0A= to an attacker).=0A= =0A= SSH MUST NOT be configured to skip public key verification for use=0A= with the SSH Transport Model.=0A= =0A= 9.2. The 'none' MAC Algorithm=0A= =0A= SSH provides the "none" MAC algorithm, which would allow you to turn=0A= off data integrity while maintaining confidentiality. However, if=0A= you do this, then an attacker may be able to modify the data in=0A= flight, which means you effectively have no authentication.=0A= =0A= SSH MUST NOT be configured using the "none" MAC algorithm for use=0A= with the SSH Transport Model.=0A= =0A= 9.3. Use with SNMPv1/v2c Messages=0A= =0A= The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP=0A= 74) [RFC3584] always select the SNMPv1 or SNMPv2c Security Models=0A= respectively. Both of these, and the User-based Security Model=0A= typically used with SNMPv3, derive the securityName and securityLevel=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 27]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= from the SNMP message received, even when the message was received=0A= over a secure transport. Access control decisions are therefore made=0A= based on the contents of the SNMP message, rather than using the=0A= authenticated identity and securityLevel provided by the SSH=0A= Transport Model.=0A= =0A= 9.4. MIB Module Security=0A= =0A= There are no management objects defined in this MIB module that have=0A= a MAX-ACCESS clause of read-write and/or read-create. So, if this=0A= MIB module is implemented correctly, then there is no risk that an=0A= intruder can alter or create any management objects of this MIB=0A= module via direct SNMP SET operations.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The readable objects in this MIB module are not sensitive.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPSec or=0A= SSH), even then, there is no control as to who on the secure network=0A= is allowed to access and GET/SET (read/change/create/delete) the=0A= objects in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410] section 8), including=0A= full support for the USM and the SSH Transport Model cryptographic=0A= mechanisms (for authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= 10. IANA Considerations=0A= =0A= IANA is requested to assign:=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 28]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= 1. two TCP registered port numbers in the=0A= http://www.iana.org/assignments/port-numbers registry which will=0A= be the default ports for SNMP over an SSH Transport Model (SSHTM)=0A= as defined in this document, and SNMP over an SSH Transport Model=0A= for notifications (SSHTM-TRAP) as defined in this document. It=0A= would be good if the assigned numbers were x161 and x162.=0A= =0A= 2. an SMI number under mib-2, for the MIB module in this document,=0A= =0A= 3. an SMI number under snmpDomains, for the snmpSSHDomain,=0A= =0A= 4. "ssh" as the corresponding prefix for the snmpSSHDomain in the=0A= SNMP Transport Model registry; defined in [I-D.ietf-isms-tmsm]=0A= =0A= 5. "snmp" as an SSH Subsystem Name in the=0A= http://www.iana.org/assignments/ssh-parameters registry.=0A= =0A= -- note to RFC editor -- Please replace YYY and ZZZ in this document=0A= with the assigned port numbers and remove this note.=0A= =0A= 11. Acknowledgements=0A= =0A= The editors would like to thank Jeffrey Hutzelman for sharing his SSH=0A= insights, and Dave Shield for an outstanding job wordsmithing the=0A= existing document to improve organization and clarity.=0A= =0A= Additionally, helpful document reviews were received from: Juergen=0A= Schoenwaelder.=0A= =0A= 12. References=0A= =0A= 12.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for=0A= use in RFCs to Indicate=0A= Requirement Levels",=0A= BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed.,=0A= Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed.,=0A= "Structure of Management=0A= Information Version 2=0A= (SMIv2)", STD 58, RFC 2578,=0A= April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed.,=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 29]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed.,=0A= "Textual Conventions for=0A= SMIv2", STD 58, RFC 2579,=0A= April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins,=0A= D., and J. Schoenwaelder,=0A= "Conformance Statements for=0A= SMIv2", STD 58, RFC 2580,=0A= April 1999.=0A= =0A= [RFC2865] Rigney, C., Willens, S.,=0A= Rubens, A., and W. Simpson,=0A= "Remote Authentication Dial=0A= In User Service (RADIUS)",=0A= RFC 2865, June 2000.=0A= =0A= [RFC3411] Harrington, D., Presuhn,=0A= R., and B. Wijnen, "An=0A= Architecture for Describing=0A= Simple Network Management=0A= Protocol (SNMP) Management=0A= Frameworks", STD 62,=0A= RFC 3411, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B.=0A= Stewart, "Simple Network=0A= Management Protocol (SNMP)=0A= Applications", STD 62,=0A= RFC 3413, December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B.=0A= Wijnen, "User-based=0A= Security Model (USM) for=0A= version 3 of the Simple=0A= Network Management Protocol=0A= (SNMPv3)", STD 62,=0A= RFC 3414, December 2002.=0A= =0A= [RFC3418] Presuhn, R., "Management=0A= Information Base (MIB) for=0A= the Simple Network=0A= Management Protocol=0A= (SNMP)", STD 62, RFC 3418,=0A= December 2002.=0A= =0A= [RFC3490] Faltstrom, P., Hoffman, P.,=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 30]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= and A. Costello,=0A= "Internationalizing Domain=0A= Names in Applications=0A= (IDNA)", RFC 3490,=0A= March 2003.=0A= =0A= [RFC3584] Frye, R., Levi, D.,=0A= Routhier, S., and B.=0A= Wijnen, "Coexistence=0A= between Version 1, Version=0A= 2, and Version 3 of the=0A= Internet-standard Network=0A= Management Framework",=0A= BCP 74, RFC 3584,=0A= August 2003.=0A= =0A= [RFC4251] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Protocol Architecture",=0A= RFC 4251, January 2006.=0A= =0A= [RFC4252] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Authentication Protocol",=0A= RFC 4252, January 2006.=0A= =0A= [RFC4253] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Transport Layer Protocol",=0A= RFC 4253, January 2006.=0A= =0A= [RFC4254] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Connection Protocol",=0A= RFC 4254, January 2006.=0A= =0A= [I-D.ietf-isms-tmsm] Harrington, D. and J.=0A= Schoenwaelder, "Transport=0A= Subsystem for the Simple=0A= Network Management Protocol=0A= (SNMP)",=0A= draft-ietf-isms-tmsm-15=0A= (work in progress),=0A= October 2008.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 31]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= 12.2. Informative References=0A= =0A= [RFC1994] Simpson, W., "PPP Challenge=0A= Handshake Authentication=0A= Protocol (CHAP)", RFC 1994,=0A= August 1996.=0A= =0A= [RFC3410] Case, J., Mundy, R.,=0A= Partain, D., and B.=0A= Stewart, "Introduction and=0A= Applicability Statements=0A= for Internet-Standard=0A= Management Framework",=0A= RFC 3410, December 2002.=0A= =0A= [RFC3588] Calhoun, P., Loughney, J.,=0A= Guttman, E., Zorn, G., and=0A= J. Arkko, "Diameter Base=0A= Protocol", RFC 3588,=0A= September 2003.=0A= =0A= [RFC3986] Berners-Lee, T., Fielding,=0A= R., and L. Masinter,=0A= "Uniform Resource=0A= Identifier (URI): Generic=0A= Syntax", STD 66, RFC 3986,=0A= January 2005.=0A= =0A= [RFC4256] Cusack, F. and M. Forssen,=0A= "Generic Message Exchange=0A= Authentication for the=0A= Secure Shell Protocol=0A= (SSH)", RFC 4256,=0A= January 2006.=0A= =0A= [RFC4462] Hutzelman, J., Salowey, J.,=0A= Galbraith, J., and V.=0A= Welch, "Generic Security=0A= Service Application Program=0A= Interface (GSS-API)=0A= Authentication and Key=0A= Exchange for the Secure=0A= Shell (SSH) Protocol",=0A= RFC 4462, May 2006.=0A= =0A= [RFC5090] Sterman, B., Sadolevsky,=0A= D., Schwartz, D., Williams,=0A= D., and W. Beck, "RADIUS=0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 32]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= Extension for Digest=0A= Authentication", RFC 5090,=0A= February 2008.=0A= =0A= [RFC4742] Wasserman, M. and T.=0A= Goddard, "Using the NETCONF=0A= Configuration Protocol over=0A= Secure SHell (SSH)",=0A= RFC 4742, December 2006.=0A= =0A= [I-D.ietf-isms-transport-security-model] Harrington, D. and W.=0A= Hardaker, "Transport=0A= Security Model for SNMP", d=0A= raft-ietf-isms-transport-=0A= security-model-10 (work in=0A= progress), October 2008.=0A= =0A= Appendix A. Change Log=0A= =0A= From -13 to -14=0A= =0A= Removed duplicated text on Caches and References=0A= =0A= Simplified securityStateReference=0A= =0A= Simplified EOP to use tmStateReference rather than ASI parameters=0A= =0A= Simplified OpenSession and Close Session=0A= =0A= Reworded text to clarify short versus long term information=0A= =0A= Added more warnings about the unreliability of SSH user name=0A= =0A= removed any references to LCD=0A= =0A= From -12 to -13=0A= =0A= Removed redundant sections 3.1.4 and 3.1.5 on privacy and replay/=0A= delay/etc protection.=0A= =0A= From -11- to -12=0A= =0A= Updated "Cached Information and References" to match other ISMS=0A= documents.=0A= =0A= Added separate subsection on Secure Shell Transport Model Cached=0A= Information.=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 33]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= Added IANA considerations to add snmpSSHDomain and "ssh" to a=0A= registry for domains and corresponding prefixes, defined in TMSM.=0A= =0A= Added support for user@ prefixing in the SSH Transport Address=0A= definition and EOP.=0A= =0A= Added support for the "ssh" prefix to the transport address=0A= definition and IANA considerations section.=0A= =0A= Removed the LCD tables and related configuration since the user@=0A= transport address prefixing and the TSM user prefix changes change=0A= makes it no longer needed.=0A= =0A= From -10- to -11=0A= =0A= Changed LCD to sshtmLCDTable so it would not be confused with the=0A= snmpTsmLCD.=0A= =0A= Removed the text that said the format and content of the LCD is=0A= implementation-specific, since we now have a MIB module to=0A= standardize the format and content.=0A= =0A= Designed sshtmLCDTable to reflect there is only one=0A= transportDomain and one securityLevel supported by this transport=0A= model.=0A= =0A= Used sshtmLCDTmSecurityName to reflect that the values in this=0A= table and the values in the tmStateReference are usually the same=0A= for some fields.=0A= =0A= Added operational considerations about SSH client credential=0A= distribution.=0A= =0A= Modified EOP to use sshtmLCDTable=0A= =0A= Resolved Issue #8: Should we allow transport models to select the=0A= corresponding security model by providing an additional parameter=0A= - the securityModel parameter - to tmStateReference, which would=0A= override the securityModel parameter extracted from a message=0A= header? Doing this would resolve Issue #5, and would allow the=0A= transport security model to be used with all SNMP message=0A= versions. - The consensus is that we will not allow the transport=0A= model to specify the security model.=0A= =0A= From -09- to -10=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 34]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= Issue #1: Made release of cached session info an implementation=0A= requirement on session close.=0A= =0A= Issue #4: UTF-8 syntax of userauth user name matches syntax of=0A= SnmpAdminString.=0A= =0A= Issue #7: Resolved to not describe how an SSH session is closed.=0A= =0A= From -08- to -09=0A= =0A= Updated MIB assignment to by rfc4181 compatible=0A= =0A= update MIB security considerations with coexistence issues=0A= =0A= update sameSession and tmSessionID support=0A= =0A= Fixed note about terminology, for consistency with SNMPv3.=0A= =0A= From -07- to -08=0A= =0A= Updated MIB=0A= =0A= update MIB security considerations=0A= =0A= develop sameSession and tmSessionID support=0A= =0A= Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= Removed reference to mappings other than the identity function.=0A= =0A= From -06- to -07=0A= =0A= removed section on SSH to EngineID mappings, since engineIDs are=0A= not exposed to the transport model=0A= =0A= removed references to engineIDs and discovery=0A= =0A= removed references to securityModel.=0A= =0A= added security considerations warning about using with SNMPv1/v2c=0A= messages.=0A= =0A= added keyboard interactive discussion=0A= =0A= noted some implementation-dependent points=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 35]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= removed references to transportModel; we use the transport domain=0A= as a model identifier.=0A= =0A= cleaned up ASIs=0A= =0A= modified MIB to be under snmpModules=0A= =0A= changed transportAddressSSH to snmpSSHDomain style addressing=0A= =0A= From -05- to -06=0A= =0A= replaced transportDomainSSH with RFC3417-style snmpSSHDomain=0A= =0A= replaced transportAddressSSH with RFC3417-style snmpSSHAddress=0A= =0A= Changed recvMessage to receiveMessage, and modified OUT to IN to=0A= match TMSM.=0A= =0A= From -04- to -05=0A= =0A= added sshtmUserTable=0A= =0A= moved session table into the transport model MIB from the=0A= transport subsystem MIB=0A= =0A= added and then removed Appendix A - Notification Tables=0A= Configuration (see Transport Security Model)=0A= =0A= made this document a specification of a transport model, rather=0A= than a security model in two parts. Eliminated TMSP and MPSP and=0A= replaced them with "transport model" and "security model".=0A= =0A= Removed security-model-specific processing from this document.=0A= =0A= Removed discussion of snmpv3/v1/v2c message format co-existence=0A= =0A= changed tmSessionReference back to tmStateReference=0A= =0A= "From -03- to -04-"=0A= =0A= changed tmStateReference to tmSessionReference=0A= =0A= =0A= =0A= "From -02- to -03-"=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 36]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= rewrote almost all sections=0A= =0A= merged ASI section and Elements of Procedure sections=0A= =0A= removed references to the SSH user, in preference to SSH client=0A= =0A= updated references=0A= =0A= created a conventions section to identify common terminology.=0A= =0A= rewrote sections on how SSH addresses threats=0A= =0A= rewrote mapping SSH to engineID=0A= =0A= eliminated discovery section=0A= =0A= detailed the Elements of Procedure=0A= =0A= eliminated sections on msgFlags, transport parameters=0A= =0A= resolved issues of opening notifications=0A= =0A= eliminated sessionID (TMSM needs to be updated to match)=0A= =0A= eliminated use of tmsSessiontable except as an example=0A= =0A= updated Security Considerations=0A= =0A= "From -01- to -02-"=0A= =0A= Added TransportDomainSSH and Address=0A= =0A= Removed implementation considerations=0A= =0A= Changed all "user auth" to "client auth"=0A= =0A= Removed unnecessary MIB module objects=0A= =0A= updated references=0A= =0A= improved consistency of references to TMSM as architectural=0A= extension=0A= =0A= updated conventions=0A= =0A= updated threats to be more consistent with RFC3552=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 37]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= discussion of specific SSH mechanism configurations moved to=0A= security considerations=0A= =0A= modified session discussions to reference TMSM sessions=0A= =0A= expanded discussion of engineIDs=0A= =0A= wrote text to clarify the roles of MPSP and TMSP=0A= =0A= clarified how snmpv3 message parts are ised by SSHSM=0A= =0A= modified nesting of subsections as needed=0A= =0A= securityLevel used by the SSH Transport Model always equals=0A= authPriv=0A= =0A= removed discussion of using SSHSM with SNMPv1/v2c=0A= =0A= started updating Elements of Procedure, but realized missing info=0A= needs discussion.=0A= =0A= updated MIB module relationship to other MIB modules=0A= =0A= "From -00- to -01-"=0A= =0A= -00- initial draft as ISMS work product:=0A= =0A= updated references to secshell RFCs=0A= =0A= Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19,=0A= 20, 29, 30, and 32.=0A= =0A= updated security considerations=0A= =0A= removed Juergen Schoenwaelder from authors, at his request=0A= =0A= ran the mib module through smilint=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 38]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= =0A= EMail: jsalowey@cisco.com=0A= =0A= =0A= Wes Hardaker=0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= US=0A= =0A= Phone: +1 530 792 1913=0A= EMail: ietf@hardakers.net=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 39]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP January 2009=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2009).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires July 26, 2009 [Page 40]=0A= =0C=0A= =0A= ------=_NextPart_000_0CAA_01C97CA8.049D08C0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_0CAA_01C97CA8.049D08C0-- From isms-bounces@ietf.org Thu Jan 22 12:44:15 2009 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 E982228C29B; Thu, 22 Jan 2009 12:44:15 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A0928C291 for ; Thu, 22 Jan 2009 12:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-1.706, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, J_CHICKENPOX_57=0.6, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o1um9+OywSW for ; Thu, 22 Jan 2009 12:44:09 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 1748F28C29B for ; Thu, 22 Jan 2009 12:44:09 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 6g7f1b04g0SCNGk54kjqGl; Thu, 22 Jan 2009 20:43:50 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 6kjp1b00C0UQ6dC3Vkjp0P; Thu, 22 Jan 2009 20:43:50 +0000 From: "David Harrington" To: Date: Thu, 22 Jan 2009 15:43:47 -0500 Message-ID: <0cb101c97cd2$203d8990$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0CB2_01C97CA8.37678190" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl80h/Gecj+oTQcQGq3l30+W2ivmA== Subject: [Isms] tsm pre11 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0CB2_01C97CA8.37678190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think I have covered all the WGLC comments David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0CB2_01C97CA8.37678190 Content-Type: text/plain; name="draft-ietf-isms-transport-security-model-pre11.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-transport-security-model-pre11.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Standards Track W. Hardaker=0A= Expires: July 26, 2009 Sparta, Inc.=0A= January 22, 2009=0A= =0A= =0A= Transport Security Model for SNMP=0A= draft-ietf-isms-transport-security-model-11=0A= =0A= Status of This Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on July 26, 2009.=0A= =0A= Abstract=0A= =0A= This memo describes a Transport Security Model for the Simple Network=0A= Management Protocol.=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for monitoring and managing the Transport Security Model for=0A= SNMP.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 3=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 1]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 2. How the Transport Security Model Fits in the Architecture . . 5=0A= 2.1. Security Capabilities of this Model . . . . . . . . . . . 6=0A= 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 6=0A= 2.2. Transport Sessions . . . . . . . . . . . . . . . . . . . . 7=0A= 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 2.3.1. Coexistence with Message Processing Models . . . . . . 7=0A= 2.3.2. Coexistence with Other Security Models . . . . . . . . 7=0A= 2.3.3. Coexistence with Transport Models . . . . . . . . . . 8=0A= 3. Cached Information and References . . . . . . . . . . . . . . 8=0A= 3.1. Transport Security Model Cached Information . . . . . . . 8=0A= 3.1.1. securityStateReference . . . . . . . . . . . . . . . . 8=0A= 3.1.2. tmStateReference . . . . . . . . . . . . . . . . . . . 8=0A= 3.1.3. Prefixes and securityNames . . . . . . . . . . . . . . 9=0A= 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 9=0A= 4.1. Security Processing for an Outgoing Message . . . . . . . 9=0A= 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 10=0A= 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 11=0A= 5.1. Security Processing for an Incoming Message . . . . . . . 12=0A= 5.2. Elements of Procedure for Incoming Messages . . . . . . . 12=0A= 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 13=0A= 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 13=0A= 6.1.1. The snmpTsmStats Subtree . . . . . . . . . . . . . . . 14=0A= 6.1.2. The snmpTsmConfiguration Subtree . . . . . . . . . . . 14=0A= 6.2. Relationship to Other MIB Modules . . . . . . . . . . . . 14=0A= 6.2.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 14=0A= 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 14=0A= 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19=0A= 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 19=0A= 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20=0A= 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21=0A= 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21=0A= 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21=0A= 11.2. Informative References . . . . . . . . . . . . . . . . . . 22=0A= Appendix A. Notification Tables Configuration . . . . . . . . . . 22=0A= A.1. Transport Security Model Processing for Notifications . . 24=0A= Appendix B. Processing Differences between USM and Secure=0A= Transport . . . . . . . . . . . . . . . . . . . . . . 25=0A= B.1. USM and the RFC3411 Architecture . . . . . . . . . . . . . 25=0A= B.2. Transport Subsystem and the RFC3411 Architecture . . . . . 26=0A= Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 26=0A= Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 26=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 2]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo describes a Transport Security Model for the Simple Network=0A= Management Protocol, for use with secure Transport Models in the=0A= Transport Subsystem [I-D.ietf-isms-tmsm].=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for monitoring and managing the Transport Security Model for=0A= SNMP.=0A= =0A= It is important to understand the SNMP architecture and the=0A= terminology of the architecture to understand where the Transport=0A= Security Model described in this memo fits into the architecture and=0A= interacts with other subsystems and models within the architecture.=0A= It is expected that reader will have also read and understood RFC3411=0A= [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418=0A= [RFC3418].=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications that use=0A= different variations of the same terminology. This is consistent=0A= with the IESG decision to not require the SNMPv3 terminology be=0A= modified to match the usage of other non-SNMP specifications when=0A= SNMPv3 was advanced to Full Standard.=0A= =0A= Authentication in this document typically refers to the English=0A= meaning of "serving to prove the authenticity of" the message, not=0A= data source authentication or peer identity authentication.=0A= =0A= The terms "manager" and "agent" are not used in this document,=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 3]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= because in the RFC 3411 architecture, all SNMP entities have the=0A= capability of acting as either manager or agent or both depending on=0A= the SNMP applications included in the engine. Where distinction is=0A= required, the application names of Command Generator, Command=0A= Responder, Notification Originator, Notification Receiver, and Proxy=0A= Forwarder are used. See "SNMP Applications" [RFC3413] for further=0A= information.=0A= =0A= While security protocols frequently refer to a user, the terminology=0A= used in RFC3411 [RFC3411] and in this memo is "principal". A=0A= principal is the "who" on whose behalf services are provided or=0A= processing takes place. A principal can be, among other things, an=0A= individual acting in a particular role; a set of individuals, with=0A= each acting in a particular role; an application or a set of=0A= applications, or a combination of these within an administrative=0A= domain.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= 1.3. Modularity=0A= =0A= The reader is expected to have read and understood the description of=0A= the SNMP architecture, as defined in [RFC3411], and the architecture=0A= extension specified in "Transport Subsystem for the Simple Network=0A= Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of=0A= external "lower layer transport" protocols to provide message=0A= security, tied into the SNMP architecture through the Transport=0A= Subsystem. The Transport Security Model is designed to work with=0A= such lower-layer secure Transport Models.=0A= =0A= In keeping with the RFC 3411 design decisions to use self-contained=0A= documents, this memo includes the elements of procedure plus=0A= associated MIB objects which are needed for processing the Transport=0A= Security Model for SNMP. These MIB objects SHOULD NOT be referenced=0A= in other documents. This allows the Transport Security Model to be=0A= designed and documented as independent and self-contained, having no=0A= direct impact on other modules, and allowing this module to be=0A= upgraded and supplemented as the need arises, and to move along the=0A= standards track on different time-lines from other modules.=0A= =0A= This modularity of specification is not meant to be interpreted as=0A= imposing any specific requirements on implementation.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 4]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= 1.4. Motivation=0A= =0A= This memo describes a Security Model to make use of Transport Models=0A= that use lower layer secure transports and existing and commonly=0A= deployed security infrastructures. This Security Model is designed=0A= to meet the security and operational needs of network administrators,=0A= maximize usability in operational environments to achieve high=0A= deployment success and at the same time minimize implementation and=0A= deployment costs to minimize the time until deployment is possible.=0A= =0A= 1.5. Constraints=0A= =0A= The design of this SNMP Security Model is also influenced by the=0A= following constraints:=0A= =0A= 1. In times of network stress, the security protocol and its=0A= underlying security mechanisms SHOULD NOT depend solely upon the=0A= ready availability of other network services (e.g., Network Time=0A= Protocol (NTP) or Authentication, Authorization, and Accounting=0A= (AAA) protocols).=0A= =0A= 2. When the network is not under stress, the Security Model and its=0A= underlying security mechanisms MAY depend upon the ready=0A= availability of other network services.=0A= =0A= 3. It may not be possible for the Security Model to determine when=0A= the network is under stress.=0A= =0A= 4. A Security Model should require no changes to the SNMP=0A= architecture.=0A= =0A= 5. A Security Model should require no changes to the underlying=0A= security protocol.=0A= =0A= 2. How the Transport Security Model Fits in the Architecture=0A= =0A= The Transport Security Model is designed to fit into the RFC3411=0A= architecture as a Security Model in the Security Subsystem, and to=0A= utilize the services of a secure Transport Model.=0A= =0A= For incoming messages, a secure Transport Model will pass a=0A= tmStateReference cache, described later. To maintain RFC3411=0A= modularity, the Transport Model will not know which securityModel=0A= will process the incoming message; the Message Processing Model will=0A= determine this. If the Transport Security Model is used with a non-=0A= secure Transport Model, then the cache will not exist or not be=0A= populated with security parameters, which will cause the Transport=0A= Security Model to return an error (see section 5.2)=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 5]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= The Transport Security Model will create the securityName and=0A= securityLevel to be passed to applications, and verify that the=0A= tmTransportSecurityLevel reported by the Transport Model is at least=0A= as strong as the securityLevel requested by the Message Processing=0A= Model.=0A= =0A= For outgoing messages, the Transport Security Model will create a=0A= tmStateReference cache (or use an existing one), and pass the=0A= tmStateReference to the specified Transport Model.=0A= =0A= 2.1. Security Capabilities of this Model=0A= =0A= 2.1.1. Threats=0A= =0A= The Transport Security Model is compatible with the RFC3411=0A= architecture, and provides protection against the threats identified=0A= by the RFC 3411 architecture. However, the Transport Security Model=0A= does not provide security mechanisms such as authentication and=0A= encryption itself, so it SHOULD always be used with a Transport Model=0A= that provides appropriate security. Which threats are addressed and=0A= how they are mitigated depends on the Transport Model.=0A= =0A= 2.1.2. Security Levels=0A= =0A= The RFC 3411 architecture recognizes three levels of security:=0A= =0A= - without authentication and without privacy (noAuthNoPriv)=0A= =0A= - with authentication but without privacy (authNoPriv)=0A= =0A= - with authentication and with privacy (authPriv)=0A= =0A= The model-independent securityLevel parameter is used to request=0A= specific levels of security for outgoing messages, and to assert that=0A= specific levels of security were applied during the transport and=0A= processing of incoming messages.=0A= =0A= The transport layer algorithms used to provide security SHOULD NOT be=0A= exposed to the Transport Security Model, as the Transport Security=0A= Model has no mechanisms by which it can test whether an assertion=0A= made by a Transport Model is accurate.=0A= =0A= The Transport Security Model trusts that the underlying secure=0A= transport connection has been properly configured to support security=0A= characteristics at least as strong as reported in=0A= tmTransportSecurityLevel.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 6]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= 2.2. Transport Sessions=0A= =0A= The Transport Security Model does not work with transport sessions=0A= directly. Instead the transport-related state is associated with a=0A= unique combination of transportDomain, transportAddress, securityName=0A= and securityLevel, and referenced via the tmStateReference parameter.=0A= How and if this is mapped to a particular transport or channel is the=0A= responsibility of the Transport Subsystem.=0A= =0A= 2.3. Coexistence=0A= =0A= In the RFC3411 architecture, a Message Processing Model determines=0A= which Security Model should be called. As of this writing, IANA has=0A= registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/=0A= SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1,=0A= SNMPv2c, and the User-based Security Model).=0A= =0A= 2.3.1. Coexistence with Message Processing Models=0A= =0A= The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP=0A= 74) [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security=0A= Models. Since there is no mechanism defined in RFC3584 to select an=0A= alternative Security Model, SNMPv1 and SNMPv2c messages cannot use=0A= the Transport Security Model. Such messages can still be conveyed=0A= over a secure transport protocol, but the Transport Security Model=0A= will not be invoked.=0A= =0A= The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact=0A= for which there is no existing IETF specification.=0A= =0A= The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts=0A= the securityModel from the msgSecurityModel field of an incoming=0A= SNMPv3Message. When this value is transportSecurityModel(YY),=0A= security processing is directed to the Transport Security Model. For=0A= an outgoing message to be secured using the Transport Security Model,=0A= the application should specify a securityModel parameter value of=0A= transportSecurityModel(YY) in the sendPdu ASI.=0A= =0A= [-- NOTE to RFC editor: replace YY with actual IANA-assigned number,=0A= and remove this note. ]=0A= =0A= 2.3.2. Coexistence with Other Security Models=0A= =0A= The Transport Security Model uses its own MIB module for processing=0A= to maintain independence from other Security Models. This allows the=0A= Transport Security Model to coexist with other Security Models, such=0A= as the User-based Security Model.=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 7]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= 2.3.3. Coexistence with Transport Models=0A= =0A= The Transport Security Model may work with multiple Transport Models,=0A= but the RFC3411 application service interfaces (ASIs) do not carry a=0A= value for the Transport Model. The MIB module defined in this memo=0A= allows an administrator to configure whether or not TSM prepends a=0A= transport model prefix to the securityName. This will allow SNMP=0A= applications to consider transport model as a factor when making=0A= decisions, such as access control, notification generation, and proxy=0A= forwarding.=0A= =0A= 3. Cached Information and References=0A= =0A= When performing SNMP processing, there are two levels of state=0A= information that may need to be retained: the immediate state linking=0A= a request-response pair, and potentially longer-term state relating=0A= to transport and security. "Transport Subsystem for the Simple=0A= Network Management Protocol" [I-D.ietf-isms-tmsm] defines general=0A= requirements for caches and references.=0A= =0A= This document defines additional cache requirements related to the=0A= Transport Security Model.=0A= =0A= 3.1. Transport Security Model Cached Information=0A= =0A= The Transport Security Model has specific responsibilities regarding=0A= the cached information.=0A= =0A= 3.1.1. securityStateReference=0A= =0A= The Transport Security Model adds the tmStateReference received from=0A= the processIncomingMsg ASI to the securityStateReference. This=0A= tmStateReference can then be retrieved during the generateResponseMsg=0A= ASI, so that it can be passed back to the Transport Model.=0A= =0A= 3.1.2. tmStateReference=0A= =0A= For outgoing messages, the Transport Security Model uses parameters=0A= provided by the SNMP application to lookup or create a=0A= tmStateReference.=0A= =0A= The Transport Security Model REQUIRES that the security parameters=0A= used for a response are the same as those used for the corresponding=0A= request. This security model uses the tmStateReference stored as=0A= part of the securityStateReference when appropriate. For responses=0A= and reports, this security model sets the tmSameSecurity flag to true=0A= in the tmStateReference before passing it to a transport model.=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 8]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= For incoming messages, the Transport Security Model uses parameters=0A= provided in the tmStateReference cache to establish a securityName,=0A= and to verify adequate security levels.=0A= =0A= 3.1.3. Prefixes and securityNames=0A= =0A= The SNMP-VIEW-BASED-ACM-MIB [RFC3415], the SNMP-TARGET-MIB module=0A= [RFC3413], and other MIB modules contain objects to configure=0A= security parameters for use by applications such as access control,=0A= notification generation, and proxy forwarding.=0A= =0A= IANA maintains a registry for transport domains and the corresponding=0A= prefix.=0A= =0A= If snmpTsmConfigurationUsePrefix is set to true then all=0A= securityNames provided by, or provided to, the Transport Security=0A= Model MUST include a valid transport domain prefix.=0A= =0A= If snmpTsmConfigurationUsePrefix is set to false then all=0A= securityNames provided by, or provided to, the Transport Security=0A= Model MUST NOT include a transport domain prefix.=0A= =0A= The tmSecurityName in the tmStateReference stored as part of the=0A= securityStateReference does not contain a prefix.=0A= =0A= 4. Processing an Outgoing Message=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected.=0A= =0A= 4.1. Security Processing for an Outgoing Message=0A= =0A= This section describes the procedure followed by the Transport=0A= Security Model.=0A= =0A= The parameters needed for generating a message are supplied to the=0A= Security Model by the Message Processing Model via the=0A= generateRequestMsg() or the generateResponseMsg() ASI. The Transport=0A= Subsystem architectural extension has added the transportDomain,=0A= transportAddress, and tmStateReference parameters to the original=0A= RFC3411 ASIs.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 9]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateRequestMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- (NEW) specified by application=0A= IN transportAddress -- (NEW) specified by application=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) transport info=0A= )=0A= =0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateResponseMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- (NEW) specified by application=0A= IN transportAddress -- (NEW) specified by application=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= IN securityStateReference -- reference to security state=0A= -- information from original=0A= -- request=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) transport info=0A= )=0A= =0A= 4.2. Elements of Procedure for Outgoing Messages=0A= =0A= 1) If there is a securityStateReference (Response or Report message),=0A= then this security model uses the cached information rather than the=0A= information provided by the ASI. Extract the tmStateReference from=0A= the securityStateReference cache. Set the tmRequestedSecurityLevel=0A= to the value of the extracted tmTransportSecurityLevel. Set the=0A= tmSameSecurity parameter in the tmStateReference cache to true. The=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 10]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= cachedSecurityData for this message can now be discarded.=0A= =0A= 2) If there is no securityStateReference then create a=0A= tmStateReference cache. Set tmTransportDomain to the value of=0A= transportDomain tmTransportAddress to the value of transportAddress,=0A= and tmRequestedSecurityLevel to the value of securityLevel.=0A= (Implementers might optimize by pointing to saved copies of these=0A= session-specific values.) Set the transaction-specific=0A= tmSameSecurity parameter to false.=0A= =0A= If the snmpTsmConfigurationUsePrefix object is set to false, then set=0A= tmSecurityName to the value of securityName.=0A= =0A= If the snmpTsmConfigurationUsePrefix object is set to true, then use=0A= the transportDomain to look up the corresponding prefix. (Since the=0A= securityStateReference stores the tmStateReference with the=0A= tmSecurityName for the incoming message, and tmSecurityName never has=0A= a prefix, the prefix stripping step only occurs when we are not using=0A= the securityStateReference).=0A= =0A= If the prefix lookup fails for any reason, then the=0A= snmpTsmUnknownPrefixes counter is incremented, an error indication=0A= is returned to the calling module, and message processing stops.=0A= =0A= If the lookup succeeds, but there is no prefix in the=0A= securityName, or the prefix returned does not match the prefix in=0A= the securityName, or the length of the prefix is less than 1 or=0A= greater than four ASCII characters, then the=0A= snmpTsmInvalidPrefixes counter is incremented, an error indication=0A= is returned to the calling module, and message processing stops.=0A= =0A= Strip the transport-specific prefix and trailing ':' character=0A= (ASCII 0x3a) from the securityName. Set tmSecurityName to the=0A= value of securityName.=0A= =0A= 3) Set securityParameters to a zero-length OCTET STRING ('0400').=0A= =0A= 4) Combine the message parts into a wholeMsg and calculate=0A= wholeMsgLength.=0A= =0A= 5) The wholeMsg, wholeMsgLength, securityParameters and=0A= tmStateReference are returned to the calling Message Processing Model=0A= with the statusInformation set to success.=0A= =0A= 5. Processing an Incoming SNMP Message=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 11]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected.=0A= =0A= 5.1. Security Processing for an Incoming Message=0A= =0A= This section describes the procedure followed by the Transport=0A= Security Model whenever it receives an incoming message from a=0A= Message Processing Model. The ASI from a Message Processing Model to=0A= the Security Subsystem for a received message is:=0A= =0A= statusInformation =3D -- errorIndication or success=0A= -- error counter OID/value if error=0A= processIncomingMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN maxMessageSize -- from the received message=0A= IN securityParameters -- from the received message=0A= IN securityModel -- from the received message=0A= IN securityLevel -- from the received message=0A= IN wholeMsg -- as received on the wire=0A= IN wholeMsgLength -- length as received on the wire=0A= IN tmStateReference -- (NEW) from the Transport Model=0A= OUT securityEngineID -- authoritative SNMP entity=0A= OUT securityName -- identification of the principal=0A= OUT scopedPDU, -- message (plaintext) payload=0A= OUT maxSizeResponseScopedPDU -- maximum size sender can handle=0A= OUT securityStateReference -- reference to security state=0A= ) -- information, needed for response=0A= =0A= 5.2. Elements of Procedure for Incoming Messages=0A= =0A= 1) Set the securityEngineID to the local snmpEngineID.=0A= =0A= 2) If tmStateReference does not refer to a cache containing values=0A= for tmTransportDomain, tmTransportAddress, tmSecurityName and=0A= tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is=0A= incremented, an error indication is returned to the calling module,=0A= and Security Model processing stops for this message.=0A= =0A= 3) Copy the tmSecurityName to securityName.=0A= =0A= If the snmpTsmConfigurationUsePrefix object is set to true, then use=0A= the tmTransportDomain to look up the corresponding prefix.=0A= =0A= a. If the prefix lookup fails for any reason, then the=0A= snmpTsmUnknownPrefixes counter is incremented, an error=0A= indication is returned to the calling module, and message=0A= processing stops.=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 12]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= If the lookup succeeds, but the prefix length is less than one or=0A= greater than four octets, then the snmpTsmInvalidPrefixes counter=0A= is incremented, an error indication is returned to the calling=0A= module, and message processing stops.=0A= =0A= Set the securityName to be the concatenation of the prefix, a ':'=0A= character (ASCII 0x3a) and the tmSecurityName.=0A= =0A= 4) Compare the value of tmTransportSecurityLevel in the=0A= tmStateReference cache to the value of the securityLevel parameter=0A= passed in the processIncomingMsg ASI. If securityLevel specifies=0A= privacy (Priv), and tmTransportSecurityLevel specifies no privacy=0A= (noPriv), or securityLevel specifies authentication (auth) and=0A= tmTransportSecurityLevel specifies no authentication (noAuth) was=0A= provided by the Transport Model, then the=0A= snmpTsmInadequateSecurityLevels counter is incremented, an error=0A= indication (unsupportedSecurityLevel) together with the OID and value=0A= of the incremented counter is returned to the calling module, and=0A= Transport Security Model processing stops for this message.=0A= =0A= 5) The tmStateReference is cached as cachedSecurityData, so that a=0A= possible response to this message will use the same security=0A= parameters. Then securityStateReference is set for subsequent=0A= reference to this cached data.=0A= =0A= 6) The scopedPDU component is extracted from the wholeMsg.=0A= =0A= 7) The maxSizeResponseScopedPDU is calculated. This is the maximum=0A= size allowed for a scopedPDU for a possible Response message.=0A= =0A= 8) The statusInformation is set to success and a return is made to=0A= the calling module passing back the OUT parameters as specified in=0A= the processIncomingMsg ASI.=0A= =0A= 6. MIB Module Overview=0A= =0A= This MIB module provides objects for use only by the Transport=0A= Security Model. It defines a configuration scalar and related error=0A= counters.=0A= =0A= 6.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 13]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= 6.1.1. The snmpTsmStats Subtree=0A= =0A= This subtree contains error counters specific to the Transport=0A= Security Model.=0A= =0A= 6.1.2. The snmpTsmConfiguration Subtree=0A= =0A= This subtree contains a configuration object that enables=0A= administrators to specify if they want a transport domain prefix=0A= prepended to securityNames for use by applications.=0A= =0A= 6.2. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing the Transport Security Model. In=0A= particular, it is assumed that an entity implementing the Transport=0A= Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the=0A= SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and=0A= the SNMPv2-MIB [RFC3418]. These are not needed to implement the=0A= SNMP-TSM-MIB.=0A= =0A= 6.2.1. MIB Modules Required for IMPORTS=0A= =0A= The following MIB module imports items from [RFC2578], [RFC2579], and=0A= [RFC2580].=0A= =0A= 7. MIB module definition=0A= =0A= =0A= SNMP-TSM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= mib-2, Counter32=0A= FROM SNMPv2-SMI=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= TruthValue=0A= FROM SNMPv2-TC=0A= ;=0A= =0A= snmpTsmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200807100000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 14]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= quittek@netlab.nec.de=0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Editor:=0A= David Harrington=0A= Huawei Technologies USA=0A= 1700 Alma Dr.=0A= Plano TX 75075=0A= USA=0A= +1 603-436-8634=0A= ietfdbh@comcast.net=0A= =0A= Wes Hardaker=0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= USA=0A= +1 530 792 1913=0A= ietf@hardakers.net=0A= "=0A= DESCRIPTION "The Transport Security Model MIB=0A= =0A= In keeping with the RFC 3411 design decisions=0A= to use self-contained documents, the RFC which=0A= contains the definition of this MIB module also=0A= includes the elements of procedure which are=0A= needed for processing the Transport Security=0A= Model for SNMP. These MIB objects=0A= SHOULD NOT be modified via other subsystems=0A= or models defined in other document..=0A= This allows the Transport Security Model=0A= for SNMP to be designed and documented as=0A= independent and self- contained, having no=0A= direct impact on other modules, and this=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 15]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= allows this module to be upgraded and=0A= supplemented as the need arises, and to=0A= move along the standards track on different=0A= time-lines from other modules.=0A= =0A= Copyright (C) The IETF Trust (2008). This=0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200807100000Z"=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- ---------------------------------------------------------- --=0A= -- subtrees in the SNMP-TSM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= snmpTsmNotifications OBJECT IDENTIFIER ::=3D { snmpTsmMIB 0 }=0A= snmpTsmMIBObjects OBJECT IDENTIFIER ::=3D { snmpTsmMIB 1 }=0A= snmpTsmConformance OBJECT IDENTIFIER ::=3D { snmpTsmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= -- Statistics for the Transport Security Model=0A= =0A= =0A= snmpTsmStats OBJECT IDENTIFIER ::=3D { snmpTsmMIBObjects 1 }=0A= =0A= snmpTsmInvalidCaches OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of incoming messages dropped because the=0A= tmStateReference referred to an invalid cache.=0A= "=0A= ::=3D { snmpTsmStats 1 }=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 16]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= snmpTsmInadequateSecurityLevels OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of incoming messages dropped because=0A= the securityLevel asserted by the transport model was=0A= less than the securityLevel requested by the=0A= application.=0A= "=0A= ::=3D { snmpTsmStats 2 }=0A= =0A= snmpTsmUnknownPrefixes OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of messages dropped because=0A= snmpTsmConfigurationUsePrefix was set to true and=0A= there is no known prefix for the specified transport=0A= domain.=0A= "=0A= ::=3D { snmpTsmStats 3 }=0A= =0A= snmpTsmInvalidPrefixes OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of messages dropped because=0A= the securityName associated with an outgoing message=0A= did not contain a valid transport domain prefix.=0A= "=0A= ::=3D { snmpTsmStats 4 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Configuration=0A= -- -------------------------------------------------------------=0A= =0A= -- Configuration for the Transport Security Model=0A= =0A= =0A= snmpTsmConfiguration OBJECT IDENTIFIER ::=3D { snmpTsmMIBObjects 2 }=0A= =0A= snmpTsmConfigurationUsePrefix OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION "If this object is set to true then securityNames=0A= passing to and from the application are expected to=0A= contain a transport domain specific prefix. If this=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 17]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= object is set to true then a domain specific prefix=0A= will be added by the TSM to the securityName for=0A= incoming messages and removed from the securityName=0A= when processing outgoing messages. Transport domains=0A= and prefixes are maintained in a registry by IANA.=0A= This object SHOULD persist across system reboots.=0A= "=0A= DEFVAL { false }=0A= ::=3D { snmpTsmConfiguration 1 }=0A= =0A= -- -------------------------------------------------------------=0A= -- snmpTsmMIB - Conformance Information=0A= -- -------------------------------------------------------------=0A= =0A= snmpTsmCompliances OBJECT IDENTIFIER ::=3D { snmpTsmConformance 1 }=0A= =0A= snmpTsmGroups OBJECT IDENTIFIER ::=3D { snmpTsmConformance 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Compliance statements=0A= -- -------------------------------------------------------------=0A= =0A= snmpTsmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION "The compliance statement for SNMP engines that support=0A= the SNMP-TSM-MIB=0A= "=0A= MODULE=0A= MANDATORY-GROUPS { snmpTsmGroup }=0A= ::=3D { snmpTsmCompliances 1 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Units of conformance=0A= -- -------------------------------------------------------------=0A= snmpTsmGroup OBJECT-GROUP=0A= OBJECTS {=0A= snmpTsmInvalidCaches,=0A= snmpTsmInadequateSecurityLevels,=0A= snmpTsmUnknownPrefixes,=0A= snmpTsmInvalidPrefixes,=0A= snmpTsmConfigurationUsePrefix=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining=0A= information of an SNMP engine which implements=0A= the SNMP Transport Security Model.=0A= "=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 18]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= ::=3D { snmpTsmGroups 2 }=0A= =0A= =0A= END=0A= =0A= =0A= 8. Security Considerations=0A= =0A= This document describes a Security Model, compatible with the RFC3411=0A= architecture, that permits SNMP to utilize security services provided=0A= through an SNMP Transport Model. The Transport Security Model relies=0A= on Transport Models for mutual authentication, binding of keys,=0A= confidentiality and integrity.=0A= =0A= The Transport Security Model relies on secure Transport Models to=0A= provide an authenticated principal identifier and an assertion of=0A= whether authentication and privacy are used during transport. This=0A= Security Model SHOULD always be used with Transport Models that=0A= provide adequate security, but "adequate security" is a configuration=0A= and/or run-time decision of the operator or management application.=0A= The security threats and how these threats are mitigated should be=0A= covered in detail in the specifications of the Transport Models and=0A= the underlying secure transports.=0A= =0A= An authenticated principal identifier (securityName) is used in SNMP=0A= applications, for purposes such as access control, notification=0A= generation, and proxy forwarding. This security model supports=0A= multiple transport models. Operators might judge some transports to=0A= be more secure than others, so this security model can be configured=0A= to prepend a prefix to the securityName to indicate the transport=0A= model used to authenticate the principal. Operators can use the=0A= prefixed securityName when making application decisions about levels=0A= of access.=0A= =0A= 8.1. MIB module security=0A= =0A= There are a number of management objects defined in this MIB module=0A= with a MAX-ACCESS clause of read-write and/or read-create. Such=0A= objects may be considered sensitive or vulnerable in some network=0A= environments. The support for SET operations in a non-secure=0A= environment without proper protection can have a negative effect on=0A= network operations. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The snmpTsmConfigurationUsePrefix object could be modified,=0A= creating a denial of service or authorizing SNMP messages that=0A= would not have previously been authorized by an Access Control=0A= Model (e.g. the VACM).=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 19]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o All the counters in this module refer to configuration errors and=0A= do not expose sensitive information.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPsec),=0A= even then, there is no control as to who on the secure network is=0A= allowed to access and GET/SET (read/change/create/delete) the objects=0A= in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410] section 8), including=0A= full support for the USM and Transport Security Model cryptographic=0A= mechanisms (for authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= 9. IANA Considerations=0A= =0A= IANA is requested to assign:=0A= =0A= 1. an SMI number under mib-2, for the MIB module in this document,=0A= =0A= 2. a value, preferably 4, to identify the Transport Security Model,=0A= in the Security Models registry at=0A= http://www.iana.org/assignments/snmp-number-spaces. This should=0A= result in the following table of values:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 20]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= Value Description References=0A= ----- ----------- ----------=0A= 0 reserved for 'any' [RFC3411]=0A= 1 reserved for SNMPv1 [RFC3411]=0A= 2 reserved for SNMPv2c [RFC3411]=0A= 3 User-Based Security Model (USM) [RFC3411]=0A= YY Transport Security Model (TSM) [RFCXXXX]=0A= =0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= -- NOTE to RFC editor: replace YY with actual IANA-assigned number,=0A= throughout this document and remove this note.=0A= =0A= 10. Acknowledgements=0A= =0A= The editors would like to thank Jeffrey Hutzelman for sharing his SSH=0A= insights, and Dave Shield for an outstanding job wordsmithing the=0A= existing document to improve organization and clarity.=0A= =0A= Additionally, helpful document reviews were received from: Juergen=0A= Schoenwaelder.=0A= =0A= 11. References=0A= =0A= 11.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to=0A= Indicate Requirement Levels", BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Structure of Management=0A= Information Version 2 (SMIv2)", STD 58,=0A= RFC 2578, April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Textual Conventions for=0A= SMIv2", STD 58, RFC 2579, April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins, D., and J.=0A= Schoenwaelder, "Conformance Statements for=0A= SMIv2", STD 58, RFC 2580, April 1999.=0A= =0A= [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An=0A= Architecture for Describing Simple Network=0A= Management Protocol (SNMP) Management=0A= Frameworks", STD 62, RFC 3411, December 2002.=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 21]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= [RFC3412] Case, J., Harrington, D., Presuhn, R., and B.=0A= Wijnen, "Message Processing and Dispatching for=0A= the Simple Network Management Protocol (SNMP)",=0A= STD 62, RFC 3412, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple=0A= Network Management Protocol (SNMP)=0A= Applications", STD 62, RFC 3413, December 2002.=0A= =0A= [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport=0A= Subsystem for the Simple Network Management=0A= Protocol (SNMP)", draft-ietf-isms-tmsm-15 (work=0A= in progress), October 2008.=0A= =0A= 11.2. Informative References=0A= =0A= [RFC3410] Case, J., Mundy, R., Partain, D., and B.=0A= Stewart, "Introduction and Applicability=0A= Statements for Internet-Standard Management=0A= Framework", RFC 3410, December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B. Wijnen, "User-based=0A= Security Model (USM) for version 3 of the=0A= Simple Network Management Protocol (SNMPv3)",=0A= STD 62, RFC 3414, December 2002.=0A= =0A= [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie,=0A= "View-based Access Control Model (VACM) for the=0A= Simple Network Management Protocol (SNMP)",=0A= STD 62, RFC 3415, December 2002.=0A= =0A= [RFC3418] Presuhn, R., "Management Information Base (MIB)=0A= for the Simple Network Management Protocol=0A= (SNMP)", STD 62, RFC 3418, December 2002.=0A= =0A= [RFC3584] Frye, R., Levi, D., Routhier, S., and B.=0A= Wijnen, "Coexistence between Version 1, Version=0A= 2, and Version 3 of the Internet-standard=0A= Network Management Framework", BCP 74,=0A= RFC 3584, August 2003.=0A= =0A= Appendix A. Notification Tables Configuration=0A= =0A= The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to=0A= configure notification originators with the destinations to which=0A= notifications should be sent.=0A= =0A= Most of the configuration is security-model-independent and=0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 22]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= transport-model-independent.=0A= =0A= The values we will use in the examples for the five model-independent=0A= security and transport parameters are:=0A= =0A= transportDomain =3D snmpSSHDomain=0A= =0A= transportAddress =3D rtr-nyc4@192.0.2.1:PPP=0A= =0A= securityModel =3D Transport Security Model=0A= =0A= securityName =3D alice=0A= =0A= securityLevel =3D authPriv=0A= =0A= The following example will configure the Notification Originator to=0A= send informs to a Notification Receiver at rtr-nyc4@192.0.2.1:PPP=0A= using the securityName "alice". "alice" is the name for the recipient=0A= from the standpoint of the notification originator, and is used for=0A= processing access controls before sending a notification."rtr-nyc4"=0A= is the name for the recipient from the standpoint of the notification=0A= receiver.=0A= =0A= The columns marked with a "*" are the items that are Security Model=0A= or Transport Model specific.=0A= =0A= The configuration for the "alice" settings in the SNMP-VIEW-BASED-=0A= ACM-MIB objects are not shown here for brevity. First we configure=0A= which type of notification should be sent for this taglist (toCRTag).=0A= In this example, we choose to send an Inform.=0A= snmpNotifyTable row:=0A= snmpNotifyName CRNotif=0A= snmpNotifyTag toCRTag=0A= snmpNotifyType inform=0A= snmpNotifyStorageType nonVolatile=0A= snmpNotifyColumnStatus createAndGo=0A= =0A= Then we configure a transport address to which notifications=0A= associated with this taglist should be sent, and we specify which=0A= snmpTargetParamsEntry should be used (toCR) when sending to this=0A= transport address.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 23]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= snmpTargetAddrTable row:=0A= snmpTargetAddrName toCRAddr=0A= * snmpTargetAddrTDomain snmpSSHDomain=0A= * snmpTargetAddrTAddress rtr-nyc4@192.0.2.1:PPP=0A= snmpTargetAddrTimeout 1500=0A= snmpTargetAddrRetryCount 3=0A= snmpTargetAddrTagList toCRTag=0A= snmpTargetAddrParams toCR (must match below)=0A= snmpTargetAddrStorageType nonVolatile=0A= snmpTargetAddrColumnStatus createAndGo=0A= =0A= =0A= Then we configure which principal at the host should receive the=0A= notifications associated with this taglist. Here we choose "alice",=0A= who uses the Transport Security Model.=0A= snmpTargetParamsTable row:=0A= snmpTargetParamsName toCR=0A= snmpTargetParamsMPModel SNMPv3=0A= * snmpTargetParamsSecurityModel TransportSecurityModel=0A= snmpTargetParamsSecurityName "alice"=0A= snmpTargetParamsSecurityLevel authPriv=0A= snmpTargetParamsStorageType nonVolatile=0A= snmpTargetParamsRowStatus createAndGo=0A= =0A= =0A= A.1. Transport Security Model Processing for Notifications=0A= =0A= The Transport Security Model is called using the generateRequestMsg()=0A= ASI, with the following parameters (* are from the above tables):=0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateRequestMsg(=0A= IN messageProcessingModel -- *snmpTargetParamsMPModel=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- *snmpTargetAddrTDomain=0A= IN transportAddress -- *snmpTargetAddrTAddress=0A= IN securityModel -- *snmpTargetParamsSecurityModel=0A= IN securityEngineID -- immaterial; TSM will ignore.=0A= IN securityName -- snmpTargetParamsSecurityName=0A= IN securityLevel -- *snmpTargetParamsSecurityLevel=0A= IN scopedPDU -- message (plaintext) payload=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- reference to transport info=0A= )=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 24]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= The Transport Security Model will determine the Transport Model based=0A= on the snmpTargetAddrTDomain. The selected Transport Model will=0A= select the appropriate transport connection using the=0A= tmStateReference cache created from the values of=0A= snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and=0A= snmpTargetParamsSecurityLevel.=0A= =0A= Appendix B. Processing Differences between USM and Secure Transport=0A= =0A= USM and secure transports differ in the processing order and=0A= responsibilities within the RFC3411 architecture. While the steps=0A= are the same, they occur in a different order, and may be done by=0A= different subsystems. The following lists illustrate the difference=0A= in the flow and the responsibility for different processing steps for=0A= incoming messages when using USM and when using a secure transport.=0A= (These lists are simplified for illustrative purposes, and do not=0A= represent all details of processing. Transport Models must provide=0A= the detailed elements of procedure.)=0A= =0A= With USM, SNMPv1, and SNMPv2c Security Models, security processing=0A= starts when the Message Processing Model decodes portions of the=0A= ASN.1 message to extract header fields that are used to determine=0A= which Security Model should process the message to perform=0A= authentication, decryption, timeliness checking, integrity checking,=0A= and translation of parameters to model-independent parameters. By=0A= comparison, a secure transport performs those security functions on=0A= the message, before the ASN.1 is decoded.=0A= =0A= Step 6 cannot occur until after decryption occurs. Step 6 and beyond=0A= are the same for USM and a secure transport.=0A= =0A= B.1. USM and the RFC3411 Architecture=0A= =0A= 1) decode the ASN.1 header (Message Processing Model)=0A= =0A= 2) determine the SNMP Security Model and parameters (Message=0A= Processing Model)=0A= =0A= 3) verify securityLevel. [Security Model]=0A= =0A= 4) translate parameters to model-independent parameters (Security=0A= Model)=0A= =0A= 5) authenticate the principal, check message integrity and=0A= timeliness, and decrypt the message. [Security Model]=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 25]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= 6) determine the pduType in the decrypted portions (Message=0A= Processing Model), and=0A= =0A= 7) pass on the decrypted portions with model-independent parameters.=0A= =0A= B.2. Transport Subsystem and the RFC3411 Architecture=0A= =0A= 1) authenticate the principal, check integrity and timeliness of the=0A= message, and decrypt the message. [Transport Model]=0A= =0A= 2) translate parameters to model-independent parameters (Transport=0A= Model)=0A= =0A= 3) decode the ASN.1 header (Message Processing Model)=0A= =0A= 4) determine the SNMP Security Model and parameters (Message=0A= Processing Model)=0A= =0A= 5) verify securityLevel [Security Model]=0A= =0A= 6) determine the pduType in the decrypted portions (Message=0A= Processing Model), and=0A= =0A= 7) pass on the decrypted portions with model-independent security=0A= parameters=0A= =0A= If a message is secured using a secure transport layer, then the=0A= Transport Model should provide the translation from the authenticated=0A= identity (e.g., an SSH user name) to a human-friendly identifier=0A= (tmSecurityName) in step 2. The security model will provide a=0A= mapping from that identifier to a model-independent securityName.=0A= =0A= Appendix C. Open Issues=0A= =0A= =0A= =0A= Appendix D. Change Log=0A= =0A= From -10- to -11-=0A= =0A= Clairifed short vs long term information in tmState=0A= =0A= Removed duplicated text on Caches and References=0A= =0A= removed any references to LCD=0A= =0A= From -09- to -10-=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 26]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= snmpTsmInvalidPrefix -> snmpTsmInvalidPrefixes=0A= =0A= Improvements to the prefix handling text in the EOP=0A= =0A= Removed transform selection=0A= =0A= Removed translation table=0A= =0A= Removed option to disable transports.=0A= =0A= Removed references to the LCD.=0A= =0A= Removed modifications to the "Cached Information" section to keep=0A= this consistent with other ISMS documents.=0A= =0A= Eliminated most "Relationship to Other MIB modules" text.=0A= =0A= Significant text cleanup=0A= =0A= From -08- to -09-=0A= =0A= Added the transport domain specific prefix adding/removing support=0A= as agreed to within the ISMS WG. The implementation is a bit=0A= different than what was originally discussed and is now housed=0A= entirely within this document and requires only a string=0A= allocation in the TM documents. In the end this form greatly=0A= reduced the documentation and procedure complexity in most=0A= documents.=0A= =0A= Added the snmpTsmConfigurationUsePrefix scalar.=0A= =0A= Removed the snmpTsmLCDTable since it is no longer needed.=0A= =0A= Removed the snmpTsmLCDDomainTable since it is not needed with the=0A= prefix addition replaced the functionality.=0A= =0A= From -07- to -08-=0A= =0A= Added tables to the MIB module to define a Transport Security=0A= Model-specific LCD, and updated the Elements of Procedure. This=0A= was because references to an abstract LCD sort of owned by both=0A= the security model and the transport model were found confusing.=0A= =0A= Realized we referred to the MIB module in text as SNMP-TRANSPORT-=0A= SM-MIB, but SNMP-TSM-MIB in the module. Changed all occurrences=0A= of SNMP-TRANSPORT-SM-MIB to SNMP-TSM-MIB, following RFC4181=0A= guidelines for naming.=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 27]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= Updated Security Considerations to warn about writable objects,=0A= and added the new counter to the readable objects list.=0A= =0A= Changed snmpTsmLCDName to snmpTsmLCDTmSecurityName=0A= =0A= From -05- to -06-=0A= =0A= Fixed a bunch of editorial nits=0A= =0A= Fixed the note about terminology consistent with SNMPv3.=0A= =0A= Updated MIB assignment to by rfc4181 compatible=0A= =0A= Replaced tmSameSession with tmSameSecurity to eliminate session-=0A= matching from the security model.=0A= =0A= Eliminated all reference to the LCD from the Transport Security=0A= Model; the LCD is now TM-specific.=0A= =0A= Added tmTransportSecurityLevel and tmRequestedSecurityLevel to=0A= clarify incoming versus outgoing=0A= =0A= From -04- to -05-=0A= =0A= Removed check for empty securityParameters for incoming messages=0A= =0A= Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= From -03- to -04-=0A= =0A= Editorial changes requested by Tom Petch, to clarify behavior with=0A= SNMPv1/v2c=0A= =0A= Added early discussion of how TSM fits into the architecture to=0A= clarify behavior when RFC3584 security models are co-resident.=0A= =0A= Editorial changes requested by Bert Wijnen, to eliminate version-=0A= specific discussions.=0A= =0A= Removed sections on version-specific message formats.=0A= =0A= Removed discussion of SNMPv3 in Motivation section.=0A= =0A= Added discussion of request/response session matching.=0A= =0A= From -02- to -03-=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 28]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= Editorial changes suggested by Juergen Schoenwaelder=0A= =0A= Capitalized Transport Models, Security Models, and Message=0A= Processing Models, to be consistent with RFC341x conventions.=0A= =0A= Eliminated some text that duplicated RFC3412, especially in=0A= Elements of Procedure.=0A= =0A= Changed the encoding of msgSecurityParameters=0A= =0A= Marked the (NEW) fields added to existing ASIs=0A= =0A= Modified text intro discussing relationships to other MIB modules.=0A= =0A= From -01- to -02-=0A= =0A= Changed transportSecurityModel(4) to transportSecurityModel(YY),=0A= waiting for assignment=0A= =0A= cleaned up elements of procedure [todo]s=0A= =0A= use the same errorIndication as USM for unsupportedSecurityLevel=0A= =0A= fixed syntax of tsmInadequateSecurity counter=0A= =0A= changed the "can and will use" the same security parameters to=0A= "can use", to allow responses that have different security=0A= parameters than the request.=0A= =0A= removed "Relationship to the SNMP-FRAMEWORK-MIB"=0A= =0A= cleaned up "MIB Modules Required for IMPORTS"=0A= =0A= =0A= =0A= From -00- to -01-=0A= =0A= made the Transport Model not know anything about the Security=0A= Model.=0A= =0A= modified the elements of procedure sections, given the=0A= implications of this change.=0A= =0A= simplified elements of procedure, removing most info specified in=0A= architecture/subsystem definitions.=0A= =0A= rethought the coexistence section=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 29]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= noted the implications of the Transport Security Model on=0A= isAccessAllowed()=0A= =0A= modified all text related to the LCD.=0A= =0A= removed most of the MIB (now the TSM has no configuration=0A= parameters).=0A= =0A= added counters needed to support elements of procedure=0A= =0A= renamed MIB module, and registered under snmpModules=0A= =0A= updated IANA and Security Considerations=0A= =0A= updated references.=0A= =0A= modified the notification configurations.=0A= =0A= From SSHSM-04- to Transport-security-model-00=0A= =0A= added tsmUserTable=0A= =0A= updated Appendix - Notification Tables Configuration=0A= =0A= remove open/closed issue appendices=0A= =0A= changed tmSessionReference to tmStateReference=0A= =0A= =0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 30]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= Wes Hardaker=0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= US=0A= =0A= Phone: +1 530 792 1913=0A= EMail: ietf@hardakers.net=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 31]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP January 2009=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2009).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires July 26, 2009 [Page 32]=0A= =0C=0A= =0A= ------=_NextPart_000_0CB2_01C97CA8.37678190 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_0CB2_01C97CA8.37678190-- From isms-bounces@ietf.org Thu Jan 22 13:32:21 2009 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 4658428C257; Thu, 22 Jan 2009 13:32:21 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599153A6985 for ; Thu, 22 Jan 2009 13:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 Ugd1IOLUIvSX for ; Thu, 22 Jan 2009 13:32:19 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 499B428C257 for ; Thu, 22 Jan 2009 13:32:19 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 6g7f1b03s1GhbT854lY3DZ; Thu, 22 Jan 2009 21:32:03 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id 6lY31b00R0UQ6dC3TlY3dS; Thu, 22 Jan 2009 21:32:03 +0000 From: "David Harrington" To: References: <0b9501c97be4$024201d0$0600a8c0@china.huawei.com> <20090122194722.GB7322@elstar.local> Date: Thu, 22 Jan 2009 16:32:01 -0500 Message-ID: <0cc301c97cd8$dcaff8f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090122194722.GB7322@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl8ykWe6ZCkUtenRPWqSAIkB+FtMgADX0Hw Cc: isms@ietf.org Subject: Re: [Isms] ssh authn 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, sentence 1 talks about server authn, which I assume means RFC4253. sentences 2-4 talk about user authn, which I assume means RFC4252 sentence 5 talks about server authn, which I assume means RFC4253. It strikes me that this paragraph should be reworked to separate the server auth and the user auth discussions. Unless, of course, I am misunderstanding this text. Maybe this is about how to use tmTransportAddress during server authn, and it just is not clear. is this all about server authn, or is client and server authn mixed in this paragraph? dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 22, 2009 2:47 PM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] ssh authn > > On Wed, Jan 21, 2009 at 11:19:16AM -0500, David Harrington wrote: > > In the following paragraph, is this all about server authn, or is > > client and server authn mixed into this paragraph? > > > > Using tmTransportAddress, the client will establish an > > SSH transport connection using the SSH transport protocol, > > authenticate the server, and exchange keys for message > > integrity and encryption. The tmTransportAddress field may > > contain a user-name followed by an '@' character > (ASCII 0x40) > > that will indicate a specific user-name string that > should be > > presented to the ssh server as the "user name" for > > authentication purposes. This MAY be different than > the passed > > tmSecurityName value that will be used in the > remaining steps > > below. If there is no specified user-name in the > > tmTransportAddress then the tmSecurityName should be used > > as the user-name. The other parameters of the transport > > connection and the credentials used to authenticate the > > server are provided in an implementation-dependent manner. > > I am not sure where your question is supposed to leads to. The text > tells me that the user-name portion of the tmTransportAddress if > present is used as the ssh user name instead of tmSecurityName. The > user name is relevant for SSH client authentication, not for SSH > server authentication. That said, I am still wondering what the reason > behind your question is... > > /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 Thu Jan 22 15:10:39 2009 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 81E1D3A68E8; Thu, 22 Jan 2009 15:10:39 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7415C3A68E8 for ; Thu, 22 Jan 2009 15:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 fjz0auD1i0Sq for ; Thu, 22 Jan 2009 15:10:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1D6993A6888 for ; Thu, 22 Jan 2009 15:10:36 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49E7BC00F8; Fri, 23 Jan 2009 00:10:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DVJAJtWaG2v9; Fri, 23 Jan 2009 00:10:13 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 078C2C00FE; Fri, 23 Jan 2009 00:10:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E2507917954; Fri, 23 Jan 2009 00:10:08 +0100 (CET) Date: Fri, 23 Jan 2009 00:10:08 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090122231008.GA7514@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <0b9501c97be4$024201d0$0600a8c0@china.huawei.com> <20090122194722.GB7322@elstar.local> <0cc301c97cd8$dcaff8f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0cc301c97cd8$dcaff8f0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] ssh authn 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, Jan 22, 2009 at 04:32:01PM -0500, David Harrington wrote: > Hi, > > sentence 1 talks about server authn, which I assume means RFC4253. > sentences 2-4 talk about user authn, which I assume means RFC4252 > sentence 5 talks about server authn, which I assume means RFC4253. > > It strikes me that this paragraph should be reworked to separate the > server auth and the user auth discussions. > > Unless, of course, I am misunderstanding this text. > Maybe this is about how to use tmTransportAddress during server authn, > and it just is not clear. > > is this all about server authn, or is client and server authn mixed in > this paragraph? So you want to change this text to something like this: Using tmTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, authenticate the server, and exchange keys for message integrity and encryption. The parameters of the transport connection and the credentials used to authenticate the server are provided in an implementation-dependent manner. The tmTransportAddress field may contain a user-name followed by an '@' character (ASCII 0x40) that will indicate a specific user-name string that should be presented to the ssh server as the "user name" for user authentication purposes. This user-name MAY be different than the passed tmSecurityName value that will be used in the remaining steps below. If there is no specified user-name in the tmTransportAddress then the tmSecurityName should be used as the user-name. Such a change is fine with me. /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 Thu Jan 22 18:42:05 2009 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 7851A3A67B1; Thu, 22 Jan 2009 18:42:05 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEADA3A67B1 for ; Thu, 22 Jan 2009 18:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.439, 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 GbKQSvS7VucQ for ; Thu, 22 Jan 2009 18:42:03 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 0F7DC3A6768 for ; Thu, 22 Jan 2009 18:42:02 -0800 (PST) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0N2ffgC007295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 21:41:42 -0500 (EST) Date: Thu, 22 Jan 2009 21:41:41 -0500 From: Jeffrey Hutzelman To: David Harrington , j.schoenwaelder@jacobs-university.de Message-ID: <1A950075E59BF1D8C1987832@atlantis.pc.cs.cmu.edu> In-Reply-To: <200901222132.n0MLW7pl021445@grapenut.srv.cs.cmu.edu> References: <0b9501c97be4$024201d0$0600a8c0@china.huawei.com> <20090122194722.GB7322@elstar.local> <200901222132.n0MLW7pl021445@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.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] ssh authn 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, January 22, 2009 04:32:01 PM -0500 David Harrington wrote: > sentence 1 talks about server authn, which I assume means RFC4253. > sentences 2-4 talk about user authn, which I assume means RFC4252 > sentence 5 talks about server authn, which I assume means RFC4253. The distinction between the different SSH documents is largely opaque to SNMP, which operates at a higher layer. > is this all about server authn, or is client and server authn mixed in > this paragraph? It's not about server authentication, or client authentication. It's about how the client discovers the things it needs to know to establish an SSH connection, most of which are or can be contained in the tmTransportAddress, and some of which come from other places. I think it's quite clear and meaningful the way it is. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jan 23 06:57:28 2009 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 099B328C1A7; Fri, 23 Jan 2009 06:57:28 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B58C28C140 for ; Thu, 22 Jan 2009 12:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_12=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 dieIY3oXbJOH for ; Thu, 22 Jan 2009 12:43:33 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 72DB728C1FA for ; Thu, 22 Jan 2009 12:43:32 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 6baJ1b0020mv7h055kjGhi; Thu, 22 Jan 2009 20:43:16 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id 6kjF1b00J0UQ6dC3XkjFcg; Thu, 22 Jan 2009 20:43:16 +0000 From: "David Harrington" To: Date: Thu, 22 Jan 2009 15:43:13 -0500 Message-ID: <0cad01c97cd2$0c083290$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0CAE_01C97CA8.23322A90" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl80gt4fVg+u1WhSweSk+qhre+WHw== X-Mailman-Approved-At: Fri, 23 Jan 2009 06:57:26 -0800 Subject: [Isms] tmsm pre-16 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0CAE_01C97CA8.23322A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think I have covered all the WGLC comments. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0CAE_01C97CA8.23322A90 Content-Type: text/plain; name="draft-ietf-isms-tmsm-pre16.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-tmsm-pre16.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Updates: 3411,3412,3414,3417 J. Schoenwaelder=0A= (if approved) Jacobs University Bremen=0A= Intended status: Standards Track January 22, 2009=0A= Expires: July 26, 2009=0A= =0A= =0A= Transport Subsystem for the Simple Network Management Protocol (SNMP)=0A= draft-ietf-isms-tmsm-16=0A= =0A= Status of This Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on July 26, 2009.=0A= =0A= Abstract=0A= =0A= This document defines a Transport Subsystem, extending the Simple=0A= Network Management Protocol (SNMP) architecture defined in RFC 3411.=0A= This document defines a subsystem to contain Transport Models,=0A= comparable to other subsystems in the RFC3411 architecture. As work=0A= is being done to expand the transports to include secure transports=0A= such as SSH and TLS, using a subsystem will enable consistent design=0A= and modularity of such Transport Models. This document identifies=0A= and describes some key aspects that need to be considered for any=0A= Transport Model for SNMP.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 1]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 4=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.3. Where this Extension Fits . . . . . . . . . . . . . . . . 4=0A= 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 3. Requirements of a Transport Model . . . . . . . . . . . . . . 8=0A= 3.1. Message Security Requirements . . . . . . . . . . . . . . 8=0A= 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8=0A= 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8=0A= 3.2.1. Architectural Modularity Requirements . . . . . . . . 9=0A= 3.2.2. Access Control Requirements . . . . . . . . . . . . . 12=0A= 3.2.3. Security Parameter Passing Requirements . . . . . . . 13=0A= 3.2.4. Separation of Authentication and Authorization . . . . 13=0A= 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14=0A= 3.3.1. No SNMP Sessions . . . . . . . . . . . . . . . . . . . 14=0A= 3.3.2. Session Establishment Requirements . . . . . . . . . . 15=0A= 3.3.3. Session Maintenance Requirements . . . . . . . . . . . 16=0A= 3.3.4. Message security versus session security . . . . . . . 16=0A= 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17=0A= 5. Cached Information and References . . . . . . . . . . . . . . 17=0A= 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18=0A= 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18=0A= 5.2.1. Transport information . . . . . . . . . . . . . . . . 19=0A= 5.2.2. securityName . . . . . . . . . . . . . . . . . . . . . 19=0A= 5.2.3. securityLevel . . . . . . . . . . . . . . . . . . . . 20=0A= 5.2.4. Session Information . . . . . . . . . . . . . . . . . 21=0A= 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 21=0A= 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 22=0A= 6.2. Changes to RFC3411 Outgoing ASIs . . . . . . . . . . . . . 22=0A= 6.2.1. Message Processing Subsystem Primitives . . . . . . . 23=0A= 6.2.2. Security Subsystem Primitives . . . . . . . . . . . . 24=0A= 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 25=0A= 6.4. Changes to RFC3411 Incoming ASIs . . . . . . . . . . . . . 26=0A= 6.4.1. Message Processing Subsystem Primitive . . . . . . . . 26=0A= 6.4.2. Security Subsystem Primitive . . . . . . . . . . . . . 27=0A= 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28=0A= 7.1. Coexistence, Security Parameters, and Access Control . . . 29=0A= 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30=0A= 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31=0A= 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31=0A= 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31=0A= 10.2. Informative References . . . . . . . . . . . . . . . . . . 32=0A= Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 34=0A= A.1. Define an Abstract Service Interface . . . . . . . . . . . 34=0A= A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 34=0A= A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 35=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 2]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 35=0A= Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 35=0A= Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 3]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= 1. Introduction=0A= =0A= This document defines a Transport Subsystem, extending the Simple=0A= Network Management Protocol (SNMP) architecture defined in [RFC3411].=0A= This document identifies and describes some key aspects that need to=0A= be considered for any Transport Model for SNMP.=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= 1.2. Conventions=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119 [RFC2119].=0A= =0A= Non uppercased versions of the keywords should be read as in normal=0A= English. They will usually, but not always, be used in a context=0A= relating to compatibility with the RFC3411 architecture or the=0A= subsystem defined here, but which might have no impact on on-the-wire=0A= compatibility. These terms are used as guidance for designers of=0A= proposed IETF models to make the designs compatible with RFC3411=0A= subsystems and Abstract Service Interfaces (ASIs) (see section 3.2).=0A= Implementers are free to implement differently. Some usages of these=0A= lowercase terms are simply normal English usage.=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications that use=0A= different variations of the same terminology. This is consistent=0A= with the IESG decision to not require the SNMPv3 terminology be=0A= modified to match the usage of other non-SNMP specifications when=0A= SNMPv3 was advanced to Full Standard.=0A= =0A= 1.3. Where this Extension Fits=0A= =0A= It is expected that readers of this document will have read RFC3410=0A= and RFC3411, and have a general understanding of the functionality=0A= defined in RFCs 3412-3418.=0A= =0A= The "Transport Subsystem" is an additional component for the SNMP=0A= Engine depicted in RFC3411, section 3.1.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 4]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= The following diagram depicts its place in the RFC3411 architecture.:=0A= =0A= +-------------------------------------------------------------------+=0A= | SNMP entity |=0A= | |=0A= | +-------------------------------------------------------------+ |=0A= | | SNMP engine (identified by snmpEngineID) | |=0A= | | | |=0A= | | +------------+ | |=0A= | | | Transport | | |=0A= | | | Subsystem | | |=0A= | | +------------+ | |=0A= | | | |=0A= | | +------------+ +------------+ +-----------+ +-----------+ | |=0A= | | | Dispatcher | | Message | | Security | | Access | | |=0A= | | | | | Processing | | Subsystem | | Control | | |=0A= | | | | | Subsystem | | | | Subsystem | | |=0A= | | +------------+ +------------+ +-----------+ +-----------+ | |=0A= | +-------------------------------------------------------------+ |=0A= | |=0A= | +-------------------------------------------------------------+ |=0A= | | Application(s) | |=0A= | | | |=0A= | | +-------------+ +--------------+ +--------------+ | |=0A= | | | Command | | Notification | | Proxy | | |=0A= | | | Generator | | Receiver | | Forwarder | | |=0A= | | +-------------+ +--------------+ +--------------+ | |=0A= | | | |=0A= | | +-------------+ +--------------+ +--------------+ | |=0A= | | | Command | | Notification | | Other | | |=0A= | | | Responder | | Originator | | | | |=0A= | | +-------------+ +--------------+ +--------------+ | |=0A= | +-------------------------------------------------------------+ |=0A= | |=0A= +-------------------------------------------------------------------+=0A= =0A= =0A= The transport mappings defined in RFC3417 do not provide lower-layer=0A= security functionality, and thus do not provide transport-specific=0A= security parameters. This document updates RFC3411 and RFC3417 by=0A= defining an architectural extension and modifying the ASIs that=0A= transport mappings (hereafter called transport models) can use to=0A= pass transport-specific security parameters to other subsystems,=0A= including transport-specific security parameters that are translated=0A= into the transport-independent securityName and securityLevel=0A= parameters=0A= =0A= The Transport Security Model [I-D.ietf-isms-transport-security-model]=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 5]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= and the Secure Shell Transport Model [I-D.ietf-isms-secshell] utilize=0A= the Transport Subsystem. The Transport Security Model is an=0A= alternative to the existing SNMPv1 Security Model [RFC3584], the=0A= SNMPv2c Security Model [RFC3584], and the User-based Security Model=0A= [RFC3414]. The Secure Shell Transport Model is an alternative to=0A= existing transport mappings as described in [RFC3417].=0A= =0A= 2. Motivation=0A= =0A= Just as there are multiple ways to secure one's home or business, in=0A= a continuum of alternatives, there are multiple ways to secure a=0A= network management protocol. Let's consider three general=0A= approaches.=0A= =0A= In the first approach, an individual could sit on his front porch=0A= waiting for intruders. In the second approach, he could hire an=0A= employee , schedule the employee, position the employee to guard what=0A= he wants protected, hire a second guard to cover if the first gets=0A= sick, and so on. In the third approach, he could hire a security=0A= company, tell them what he wants protected, and leave the details to=0A= them. Considerations of hiring and training employees, positioning=0A= and scheduling the guards, arranging for cover, etc., are the=0A= responsibility of the security company. The individual therefore=0A= achieves the desired security, with no significant effort on his part=0A= other than identifying requirements and verifying the quality of=0A= service being provided.=0A= =0A= The User-based Security Model (USM) as defined in [RFC3414] largely=0A= uses the first approach - it provides its own security. It utilizes=0A= existing mechanisms (e.g., SHA), but provides all the coordination.=0A= USM provides for the authentication of a principal, message=0A= encryption, data integrity checking, timeliness checking, etc.=0A= =0A= USM was designed to be independent of other existing security=0A= infrastructures. USM therefore requires a separate principal and key=0A= management infrastructure. Operators have reported that deploying=0A= another principal and key management infrastructure in order to use=0A= SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use=0A= external mechanisms to handle the distribution of keys for use by=0A= USM. The more important issue is that operators wanted to leverage=0A= existing user base infrastructures that were not specific to SNMP.=0A= =0A= A USM-compliant architecture might combine the authentication=0A= mechanism with an external mechanism, such as RADIUS [RFC2865] to=0A= provide the authentication service. Similarly it might be possible=0A= to utilize an external protocol to encrypt a message, to check=0A= timeliness, to check data integrity, etc. However this corresponds=0A= to the second approach - requiring the coordination of a number of=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 6]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= differently subcontracted services. Building solid security between=0A= the various services is difficult, and there is a significant=0A= potential for gaps in security.=0A= =0A= An alternative approach might be to utilize one or more lower-layer=0A= security mechanisms to provide the message-oriented security services=0A= required. These would include authentication of the sender,=0A= encryption, timeliness checking, and data integrity checking. This=0A= corresponds to the third approach described above. There are a=0A= number of IETF standards available or in development to address these=0A= problems through security layers at the transport layer or=0A= application layer, among them TLS [RFC5246], SASL [RFC4422], and SSH=0A= [RFC4251]=0A= =0A= From an operational perspective, it is highly desirable to use=0A= security mechanisms that can unify the administrative security=0A= management for SNMPv3, command line interfaces (CLIs) and other=0A= management interfaces. The use of security services provided by=0A= lower layers is the approach commonly used for the CLI, and is also=0A= the approach being proposed for other network management protocols,=0A= such as syslog [I-D.ietf-syslog-protocol] and NETCONF [RFC4741].=0A= =0A= This document defines a Transport Subsystem extension to the RFC3411=0A= architecture based on the third approach. This extension specifies=0A= how other lower layer protocols with common security infrastructures=0A= can be used underneath the SNMP protocol and the desired goal of=0A= unified administrative security can be met.=0A= =0A= This extension allows security to be provided by an external protocol=0A= connected to the SNMP engine through an SNMP Transport Model=0A= [RFC3417]. Such a Transport Model would then enable the use of=0A= existing security mechanisms such as (TLS) [RFC5246] or SSH [RFC4251]=0A= within the RFC3411 architecture.=0A= =0A= There are a number of Internet security protocols and mechanisms that=0A= are in wide spread use. Many of them try to provide a generic=0A= infrastructure to be used by many different application layer=0A= protocols. The motivation behind the Transport Subsystem is to=0A= leverage these protocols where it seems useful.=0A= =0A= There are a number of challenges to be addressed to map the security=0A= provided by a secure transport into the SNMP architecture so that=0A= SNMP continues to provide interoperability with existing=0A= implementations. These challenges are described in detail in this=0A= document. For some key issues, design choices are described that=0A= might be made to provide a workable solution that meets operational=0A= requirements and fits into the SNMP architecture defined in=0A= [RFC3411].=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 7]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= 3. Requirements of a Transport Model=0A= =0A= 3.1. Message Security Requirements=0A= =0A= Transport security protocols SHOULD provide protection against the=0A= following message-oriented threats:=0A= =0A= 1. modification of information=0A= =0A= 2. masquerade=0A= =0A= 3. message stream modification=0A= =0A= 4. disclosure=0A= =0A= These threats are described in section 1.4 of [RFC3411]. It is not=0A= required to protect against denial of service or traffic analysis,=0A= but it should not make those threats significantly worse.=0A= =0A= 3.1.1. Security Protocol Requirements=0A= =0A= There are a number of standard protocols that could be proposed as=0A= possible solutions within the Transport Subsystem. Some factors=0A= should be considered when selecting a protocol.=0A= =0A= Using a protocol in a manner for which it was not designed has=0A= numerous problems. The advertised security characteristics of a=0A= protocol might depend on it being used as designed; when used in=0A= other ways, it might not deliver the expected security=0A= characteristics. It is recommended that any proposed model include a=0A= description of the applicability of the Transport Model.=0A= =0A= A Transport Model SHOULD NOT require modifications to the underlying=0A= protocol. Modifying the protocol might change its security=0A= characteristics in ways that could impact other existing usages. If=0A= a change is necessary, the change SHOULD be an extension that has no=0A= impact on the existing usages. Any Transport Model SHOULD include a=0A= description of potential impact on other usages of the protocol.=0A= =0A= Since multiple transport models can exist simultaneously within the=0A= transport subsystem, transport models MUST be able to coexist with=0A= each other.=0A= =0A= 3.2. SNMP Requirements=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 8]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= 3.2.1. Architectural Modularity Requirements=0A= =0A= SNMP version 3 (SNMPv3) is based on a modular architecture (defined=0A= in [RFC3411] section 3) to allow the evolution of the SNMP protocol=0A= standards over time, and to minimize side effects between subsystems=0A= when changes are made.=0A= =0A= The RFC3411 architecture includes a Message Processing Subsystem=0A= permitting different message versions to be handled by a single=0A= engine, a Security Subsystem for enabling different methods of=0A= providing security services, Applications(s) to support different=0A= types of application processors, and an Access Control Subsystem for=0A= allowing multiple approaches to access control. The RFC3411=0A= architecture does not include a subsystem for Transport Models,=0A= despite the fact there are multiple transport mappings already=0A= defined for SNMP. This document describes a Transport Subsystem that=0A= is compatible with the RFC3411 architecture. As work is being done=0A= to use secure transports such as SSH and TLS, using a subsystem will=0A= enable consistent design and modularity of such Transport Models.=0A= =0A= The design of this Transport Subsystem accepts the goals of the=0A= RFC3411 architecture defined in section 1.5 of [RFC3411]. This=0A= Transport Subsystem uses a modular design that permits Transport=0A= Models (which may or may not be security-aware) to be "plugged into"=0A= the RFC3411 architecture . Such Transport Models would be=0A= independent of other modular SNMP components as much as possible.=0A= This design also permits Transport Models to be advanced through the=0A= standards process independently of other Transport Models.=0A= =0A= To encourage a basic level of interoperability, IETF standards=0A= typically require one mandatory-to-implement specification, with the=0A= capability of adding new mechanisms in the future. Any Transport=0A= Model SHOULD define one minimum-compliance security mechanism, but=0A= should also be able to support additional existing and new=0A= mechanisms.=0A= =0A= The following diagram depicts the SNMPv3 architecture including the=0A= new Transport Subsystem defined in this document, and a new Transport=0A= Security Model defined in [I-D.ietf-isms-transport-security-model].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 9]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= +------------------------------+=0A= | Network |=0A= +------------------------------+=0A= ^ ^ ^=0A= | | |=0A= v v v=0A= +-------------------------------------------------------------------+=0A= | +--------------------------------------------------+ |=0A= | | Transport Subsystem | |=0A= | | +-----+ +-----+ +-----+ +-----+ +-------+ | |=0A= | | | UDP | | TCP | | SSH | | TLS | . . . | other | | |=0A= | | +-----+ +-----+ +-----+ +-----+ +-------+ | |=0A= | +--------------------------------------------------+ |=0A= | ^ |=0A= | | |=0A= | Dispatcher v |=0A= | +-------------------+ +---------------------+ +----------------+ |=0A= | | Transport | | Message Processing | | Security | |=0A= | | Dispatch | | Subsystem | | Subsystem | |=0A= | | | | +------------+ | | +------------+ | |=0A= | | | | +->| v1MP |<--->| | USM | | |=0A= | | | | | +------------+ | | +------------+ | |=0A= | | | | | +------------+ | | +------------+ | |=0A= | | | | +->| v2cMP |<--->| | Transport | | |=0A= | | Message | | | +------------+ | | | Security | | |=0A= | | Dispatch <--------->| +------------+ | | | Model | | |=0A= | | | | +->| v3MP |<--->| +------------+ | |=0A= | | | | | +------------+ | | +------------+ | |=0A= | | PDU Dispatch | | | +------------+ | | | Other | | |=0A= | +-------------------+ | +->| otherMP |<--->| | Model(s) | | |=0A= | ^ | +------------+ | | +------------+ | |=0A= | | +---------------------+ +----------------+ |=0A= | v |=0A= | +-------+-------------------------+---------------+ |=0A= | ^ ^ ^ |=0A= | | | | |=0A= | v v v |=0A= | +-------------+ +---------+ +--------------+ +-------------+ |=0A= | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | |=0A= | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |=0A= | | application | | | | applications | | application | |=0A= | +-------------+ +---------+ +--------------+ +-------------+ |=0A= | ^ ^ |=0A= | | | |=0A= | v v |=0A= | +----------------------------------------------+ |=0A= | | MIB instrumentation | SNMP entity |=0A= +-------------------------------------------------------------------+=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 10]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= 3.2.1.1. Changes to the RFC3411 Architecture=0A= =0A= The RFC3411 architecture and the Security Subsystem assume that a=0A= Security Model is called by a Message Processing Model and will=0A= perform multiple security functions within the Security Subsystem. A=0A= Transport Model that supports a secure transport protocol might=0A= perform similar security functions within the Transport Subsystem,=0A= including the translation of transport security parameters to/from=0A= security-model-independent parameters.=0A= =0A= To accommodate this, an implementation-specific cache of transport-=0A= specific information will be described (not shown), and the data=0A= flows on this path will be extended to pass security-model-=0A= independent values. This document amends some of the ASIs defined in=0A= RFC 3411, and these changes are covered in section 6.=0A= =0A= New Security Models may be defined that understand how to work with=0A= these modified ASIs and the transport-information cache. One such=0A= Security Model, the Transport Security Model, is defined in=0A= [I-D.ietf-isms-transport-security-model].=0A= =0A= 3.2.1.2. Changes to RFC3411 processing=0A= =0A= The introduction of secure transports affects the responsibilities=0A= and order of processing within the RFC3411 architecture. While the=0A= steps are the same, they may occur in a different order, and may be=0A= done by different subsystems. With the existing RFC3411=0A= architecture, security processing starts when the Message Processing=0A= Model decodes portions of the encoded message to extract parameters=0A= that identify which Security Model should handle the security-related=0A= tasks.=0A= =0A= A secure transport performs those security functions on the message,=0A= before the message is decoded. Some of these functions might then be=0A= repeated by the selected Security Model.=0A= =0A= 3.2.1.3. Passing Information between SNMP Engines=0A= =0A= A secure Transport Model will establish an authenticated and possibly=0A= encrypted tunnel between the Transport Models of two SNMP engines.=0A= After a transport layer tunnel is established, then SNMP messages can=0A= be sent through the tunnel from one SNMP engine to the other.=0A= Transport Models MAY support sending multiple SNMP messages through=0A= the same tunnel.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 11]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= 3.2.2. Access Control Requirements=0A= =0A= RFC3411 made some design decisions related to the support of an=0A= Access Control Subsystem. These include establishing and passing in=0A= a model-independent manner the securityModel, securityName and=0A= securityLevel parameters, and separating message authentication from=0A= data access authorization.=0A= =0A= 3.2.2.1. securityName and securityLevel Mapping=0A= =0A= SNMP data access controls are expected to work on the basis of who=0A= can perform what operations on which subsets of data, and based on=0A= the security services that will be provided to secure the data in=0A= transit. The securityModel and securityLevel parameters establish=0A= the protections for transit - whether authentication and privacy=0A= services will be or have been applied to the message. The=0A= securityName is a model-independent identifier of the security=0A= "principal".=0A= =0A= A Security Model plays a role in security that goes beyond protecting=0A= the message - it provides a mapping between the security-model-=0A= specific principal for an incoming message to a security-model=0A= independent securityName which can be used for subsequent processing,=0A= such as for access control. The securityName is mapped from a=0A= mechanism-specific identity, and this mapping must be done for=0A= incoming messages by the Security Model before it passes securityName=0A= to the Message Processing Model via the processIncoming ASI.=0A= =0A= A Security Model is also responsible to specify, via the=0A= securityLevel parameter, whether incoming messages have been=0A= authenticated and encrypted, and to ensure that outgoing messages are=0A= authenticated and encrypted based on the value of securityLevel.=0A= =0A= A Transport Model MAY provide suggested values for securityName and=0A= securityLevel. A Security Model may have multiple sources for=0A= determining the principal and desired security services, and a=0A= particular Security Model may or may not utilize the values proposed=0A= by a Transport Model when deciding the value of securityName and=0A= securityLevel.=0A= =0A= Documents defining a new transport domain MUST define a prefix that=0A= MAY be prepended by the Security Model to all passed securityNames.=0A= The prefix MUST include from one to four ASCII characters, not=0A= including a ":" (ASCII 0x3a) character. If a prefix is used, a=0A= securityName is constructed by concatenating the prefix and a ":"=0A= (ASCII 0x3a) character followed by a non-empty identity in an=0A= snmpAdminString compatible format. Transport domains and their=0A= corresponding prefixes are coordinated via the IANA registry "SNMP=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 12]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= Transport Domains".=0A= =0A= 3.2.3. Security Parameter Passing Requirements=0A= =0A= A Message Processing Model might unpack SNMP-specific security=0A= parameters from an incoming message before calling a specific=0A= Security Model to handle the security-related processing of the=0A= message. When using a secure Transport Model, some security=0A= parameters might be extracted from the transport layer by the=0A= Transport Model before the message is passed to the Message=0A= Processing Subsystem.=0A= =0A= This document describes a cache mechanism (see Section 5), into which=0A= the Transport Model puts information about the transport and security=0A= parameters applied to a transport connection or an incoming message,=0A= and a Security Model may extract that information from the cache. A=0A= tmStateReference is passed as an extra parameter in the ASIs between=0A= the Transport Subsystem, the Message Processing and Security=0A= Subsystems, to identify the relevant cache. This approach of passing=0A= a model-independent reference is consistent with the=0A= securityStateReference cache already being passed around in the=0A= RFC3411 ASIs.=0A= =0A= 3.2.4. Separation of Authentication and Authorization=0A= =0A= The RFC3411 architecture defines a separation of authentication and=0A= the authorization to access and/or modify MIB data. A set of model-=0A= independent parameters (securityModel, securityName, and=0A= securityLevel) are passed between the Security Subsystem, the=0A= applications, and the Access Control Subsystem.=0A= =0A= This separation was a deliberate decision of the SNMPv3 WG, to allow=0A= support for authentication protocols which do not provide data access=0A= authorization capabilities, and to support data access authorization=0A= schemes, such as VACM, that do not perform their own authentication.=0A= =0A= A Message Processing Model determines which Security Model is used,=0A= either based on the message version, e.g., SNMPv1 and SNMPv2c, or=0A= possibly by a value specified in the message, e.g., msgSecurityModel=0A= field in SNMPv3.=0A= =0A= The Security Model makes the decision which securityName and=0A= securityLevel values are passed as model-independent parameters to an=0A= application, which then passes them via the isAccessAllowed ASI to=0A= the Access Control Subsystem.=0A= =0A= An Access Control Model performs the mapping from the model-=0A= independent security parameters to a policy within the Access Control=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 13]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= Model that is access-control-model-dependent.=0A= =0A= A Transport Model does not know which Security Model will be used for=0A= an incoming message, so cannot know how the securityName and=0A= securityLevel parameters will be determined. It can propose an=0A= authenticated identity (via the tmSecurityName field), but there is=0A= no guarantee that this value will be used by the Security Model. For=0A= example, non-transport-aware Security Models will typically determine=0A= the securityName (and securityLevel) based on the contents of the=0A= SNMP message itself. Such Security Models will simply not know that=0A= the tmStateReference cache exists.=0A= =0A= Further, even if the Transport Model can influence the choice of=0A= securityName, it cannot directly determine the authorization allowed=0A= to this identity. If two different Transport Models each=0A= authenticate a transport principal, that are then both mapped to the=0A= same securityName, then these two identities will typically be=0A= afforded exactly the same authorization by the Access Control Model.=0A= =0A= The only way for the Access Control Model to differentiate between=0A= identities based on the underlying Transport Model, would be for such=0A= transport-authenticated identities to be mapped to distinct=0A= securityNames. How and if this is done is Security-Model-dependent.=0A= =0A= 3.3. Session Requirements=0A= =0A= Some secure transports have a notion of sessions, while other secure=0A= transports provide channels or other session-like mechanism.=0A= Throughout this document, the term session is used in a broad sense=0A= to cover transport sessions, transport channels, and other transport-=0A= layer session-like mechanisms. Transport-layer sessions that can=0A= secure multiple SNMP messages within the lifetime of the session are=0A= considered desirable because the cost of authentication can be=0A= amortized over potentially many transactions. How a transport=0A= session is actually established, opened, closed, or maintained is=0A= specific to a particular Transport Model.=0A= =0A= To reduce redundancy, this document describes aspects that are=0A= expected to be common to all Transport Model sessions.=0A= =0A= 3.3.1. No SNMP Sessions=0A= =0A= The architecture defined in [RFC3411] and the Transport Subsystem=0A= defined in this document do not support SNMP sessions or include a=0A= session selector in the Abstract Service Interfaces.=0A= =0A= The Transport Subsystem may support transport sessions. However, the=0A= transport subsystem does not have access to the pduType, so cannot=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 14]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= select a given transport session for particular types of traffic.=0A= =0A= Certain parameters of these ASIs might be used to guide the selection=0A= of an appropriate transport session to use for a given request by an=0A= application.=0A= =0A= The transportDomain and transportAddress identify the transport=0A= connection to a remote network node. Elements of the transport=0A= address (such as the port number) might be used by an application to=0A= send a particular PDU type to a particular transport address.=0A= =0A= The securityName identifies which security principal to communicate=0A= with at that address (e.g., different NMS applications), and the=0A= securityLevel might permit selection of different sets of security=0A= properties for different purposes (e.g., encrypted SETs vs. non-=0A= encrypted GETs).=0A= =0A= However, because the handling of transport sessions is specific to=0A= each transport model, some transport models MAY restrict selecting a=0A= particular transport session.=0A= =0A= An application might use a unique combination of transportDomain,=0A= transportAddress, securityModel, securityName, and securityLevel to=0A= try to force the selection of a given transport session. This usage=0A= is NOT RECOMMENDED because it is not guaranteed to be interoperable=0A= across implementatioins and across models.=0A= =0A= Implementations SHOULD be able to maintain some reasonable number of=0A= concurrent transport sessions, and MAY provide non-standard internal=0A= mechanisms to select transport sessions.=0A= =0A= 3.3.2. Session Establishment Requirements=0A= =0A= SNMP applications provide the transportDomain, transportAddress,=0A= securityName, and securityLevel to be used to create a new session.=0A= =0A= If the Transport Model cannot provide at least the requested level of=0A= security, the Transport Model SHOULD discard the message and SHOULD=0A= notify the dispatcher that establishing a session and sending the=0A= message failed. Similarly, if the session cannot be established,=0A= then the message SHOULD be discarded and the dispatcher notified.=0A= =0A= Transport session establishment might require provisioning=0A= authentication credentials at an engine, either statically or=0A= dynamically. How this is done is dependent on the transport model=0A= and the implementation.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 15]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= 3.3.3. Session Maintenance Requirements=0A= =0A= A Transport Model can tear down sessions as needed. It might be=0A= necessary for some implementations to tear down sessions as the=0A= result of resource constraints, for example.=0A= =0A= The decision to tear down a session is implementation-dependent. How=0A= an implementation determines that an operation has completed is=0A= implementation-dependent. While it is possible to tear down each=0A= transport session after processing for each message has completed,=0A= this is not recommended for performance reasons.=0A= =0A= The elements of procedure describe when cached information can be=0A= discarded, and the timing of cache cleanup might have security=0A= implications, but cache memory management is an implementation issue.=0A= =0A= If a Transport Model defines MIB module objects to maintain session=0A= state information, then the Transport Model MUST define what SHOULD=0A= happen to the objects when a related session is torn down, since this=0A= will impact interoperability of the MIB module.=0A= =0A= 3.3.4. Message security versus session security=0A= =0A= A Transport Model session is associated with state information that=0A= is maintained for its lifetime. This state information allows for=0A= the application of various security services to multiple messages.=0A= Cryptographic keys associated with the transport session SHOULD be=0A= used to provide authentication, integrity checking, and encryption=0A= services, as needed, for data that is communicated during the=0A= session. The cryptographic protocols used to establish keys for a=0A= Transport Model session SHOULD ensure that fresh new session keys are=0A= generated for each session. This would ensure that a cross-session=0A= replay attack would be unsuccessful; that is, an attacker could not=0A= take a message observed on one session, and successfully replay this=0A= on another session.=0A= =0A= A good security protocol would also protect against replay attacks=0A= within a session; that is, an attacker could not take a message=0A= observed on a session, and successfully replay this later in the same=0A= session. One approach would be to use sequence information within=0A= the protocol, allowing the participants to detect if messages were=0A= replayed or reordered within a session.=0A= =0A= If a secure transport session is closed between the time a request=0A= message is received, and the corresponding response message is sent,=0A= then the response message SHOULD be discarded, even if a new session=0A= has been established. The SNMPv3 WG decided that this should be a=0A= SHOULD architecturally, and it is a security-model-specific decision=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 16]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= whether to REQUIRE this.=0A= =0A= SNMPv3 was designed to support multiple levels of security,=0A= selectable on a per-message basis by an SNMP application, because,=0A= for example, there is not much value in using encryption for a=0A= Commander Generator to poll for potentially non-sensitive performance=0A= data on thousands of interfaces every ten minutes; the encryption=0A= might add significant overhead to processing of the messages.=0A= =0A= Some Transport Models might support only specific authentication and=0A= encryption services, such as requiring all messages to be carried=0A= using both authentication and encryption, regardless of the security=0A= level requested by an SNMP application. A Transport Model MAY=0A= upgrade the security level requested by a transport-aware security=0A= model, i.e. noAuthNoPriv and authNoPriv might be sent over an=0A= authenticated and encrypted session. A Transport Model MUST NOT=0A= downgrade the security level requested by a transport-aware security=0A= model, and SHOULD discard any message where this would occur.=0A= =0A= 4. Scenario Diagrams and the Transport Subsystem=0A= =0A= RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to=0A= illustrate how an outgoing message is created, and how an incoming=0A= message is processed. RFC3411 does not define ASIs for the "Send=0A= SNMP Request Message to Network", "Receive SNMP Response Message from=0A= Network", "Receive SNMP Message from Network" and "Send SNMP message=0A= to Network" arrows in these diagrams.=0A= =0A= This document defines two ASIs corresponding to these arrows: a=0A= sendMessage ASI to send SNMP messages to the network, and a=0A= receiveMessage ASI to receive SNMP messages from the network. These=0A= ASIs are used for all SNMP messages, regardless of pduType.=0A= =0A= 5. Cached Information and References=0A= =0A= When performing SNMP processing, there are two levels of state=0A= information that may need to be retained: the immediate state linking=0A= a request-response pair, and potentially longer-term state relating=0A= to transport and security.=0A= =0A= The RFC3411 architecture uses caches to maintain the short-term=0A= message state, and uses references in the ASIs to pass this=0A= information between subsystems.=0A= =0A= This document defines the requirements for a cache to handle=0A= additional short-term message state and longer-term transport state=0A= information, using a tmStateReference parameter to pass this=0A= information between subsystems.=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 17]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= To simplify the elements of procedure, the release of state=0A= information is not always explicitly specified. As a general rule,=0A= if state information is available when a message being processed gets=0A= discarded, the state related to that message SHOULD also be=0A= discarded. If state information is available when a relationship=0A= between engines is severed, such as the closing of a transport=0A= session, the state information for that relationship SHOULD also be=0A= discarded.=0A= =0A= Since the contents of a cache are meaningful only within an=0A= implementation, and not on-the-wire, the format of the cache is=0A= implementation-specific.=0A= =0A= 5.1. securityStateReference=0A= =0A= The securityStateReference parameter is defined in RFC3411. Its=0A= primary purpose is to provide a mapping between a request and the=0A= corresponding response. This cache is not accessible to Transport=0A= Models, and an entry is typically only retained for the lifetime of a=0A= request-response pair of messages.=0A= =0A= 5.2. tmStateReference=0A= =0A= For each transport session, information about the transport security=0A= is stored in a tmState cache or datastore, that is referenced by a=0A= tmStateReference. The tmStateReference parameter is used to pass=0A= model-specific and mechanism-specific parameters between the=0A= Transport subsystem and transport-aware Security Models.=0A= =0A= In general, when necessary, the tmState is populated by the security=0A= model for outgoing messages and by the transport model for incoming=0A= messages. However, in both cases, the model populating the tmState=0A= may have incomplete information, and the missing information might be=0A= populated by the other model when the information becomes available.=0A= =0A= The tmState might contain both long-term and short-term information.=0A= The session information typically remains valid for the duration of=0A= the transport session, might be used for several messages, and might=0A= be stored in a local configuration datastore. Some information has a=0A= shorter lifespan, such as tmSameSecurity and tmRequestedSecurityLevel=0A= which are associated with a specific message.=0A= =0A= Since this cache is only used within an implementation, and not on-=0A= the-wire, the precise contents and format of the cache are=0A= implementation-dependent. For architectural modularity between=0A= Transport Models and transport-aware Security Models, a fully-defined=0A= tmState MUST conceptually include at least the following fields:=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 18]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= transportDomain=0A= =0A= transportAddress=0A= =0A= tmSecurityName=0A= =0A= tmRequestedSecurityLevel=0A= =0A= tmTransportSecurityLevel=0A= =0A= tmSameSecurity=0A= =0A= tmSessionID=0A= =0A= The details of these fields are described in the following=0A= subsections.=0A= =0A= 5.2.1. Transport information=0A= =0A= Information about the source of an incoming SNMP message is passed up=0A= from the Transport subsystem as far as the Message Processing=0A= subsystem. However these parameters are not included in the=0A= processIncomingMsg ASI defined in RFC3411, and hence this information=0A= is not directly available to the Security Model.=0A= =0A= A transport-aware Security Model might wish to take account of the=0A= transport protocol and originating address when authenticating the=0A= request, and setting up the authorization parameters. It is=0A= therefore necessary for the Transport Model to include this=0A= information in the tmStateReference cache, so that it is accessible=0A= to the Security Model.=0A= =0A= o transportDomain: the transport protocol (and hence the Transport=0A= Model) used to receive the incoming message=0A= =0A= o transportAddress: the source of the incoming message.=0A= =0A= The ASIs used for processing an outgoing message all include explicit=0A= transportDomain and transportAddress parameters. The values within=0A= the securityStateReference cache might override these parameters for=0A= outgoing messages.=0A= =0A= 5.2.2. securityName=0A= =0A= There are actually three distinct "identities" that can be identified=0A= during the processing of an SNMP request over a secure transport:=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 19]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= o transport principal: the transport-authenticated identity, on=0A= whose behalf the secure transport connection was (or should be)=0A= established. This value is transport-, mechanism- and=0A= implementation- specific, and is only used within a given=0A= Transport Model.=0A= =0A= o tmSecurityName: a human-readable name (in snmpAdminString format)=0A= representing this transport identity. This value is transport-=0A= and implementation-specific, and is only used (directly) by the=0A= Transport and Security Models.=0A= =0A= o securityName: a human-readable name (in snmpAdminString format)=0A= representing the SNMP principal in a model-independent manner.=0A= This value is used directly by SNMP Applications, the access=0A= control subsystem, the message processing subsystem, and the=0A= security subsystem.=0A= =0A= The transport principal may or may not be the same as the=0A= tmSecurityName. Similarly, the tmSecurityName may or may not be the=0A= same as the securityName as seen by the Application and Access=0A= Control subsystems. In particular, a non-transport-aware Security=0A= Model will ignore tmSecurityName completely when determining the SNMP=0A= securityName.=0A= =0A= However it is important that the mapping between the transport=0A= principal and the SNMP securityName (for transport-aware Security=0A= Models) is consistent and predictable, to allow configuration of=0A= suitable access control and the establishment of transport=0A= connections.=0A= =0A= 5.2.3. securityLevel=0A= =0A= There are two distinct issues relating to security level as applied=0A= to secure transports. For clarity, these are handled by separate=0A= fields in the tmStateReference cache:=0A= =0A= o tmTransportSecurityLevel: an indication from the Transport Model=0A= of the level of security offered by this session. The Security=0A= Model can use this to ensure that incoming messages were suitably=0A= protected before acting on them.=0A= =0A= o tmRequestedSecurityLevel: an indication from the Security Model of=0A= the level of security required to be provided by the transport=0A= protocol. The Transport Model can use this to ensure that=0A= outgoing messages will not be sent over an insufficiently secure=0A= session.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 20]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= 5.2.4. Session Information=0A= =0A= For security reasons, if a secure transport session is closed between=0A= the time a request message is received and the corresponding response=0A= message is sent, then the response message SHOULD be discarded, even=0A= if a new session has been established. The SNMPv3 WG decided that=0A= this should be a SHOULD architecturally, and it is a security-model-=0A= specific decision whether to REQUIRE this.=0A= =0A= o tmSameSecurity: this flag is used by a transport-aware Security=0A= Model to indicate whether the Transport Model MUST enforce this=0A= restriction.=0A= =0A= o tmSessionID: in order to verify whether the session has changed,=0A= the Transport Model must be able to compare the session used to=0A= receive the original request with the one to be used to send the=0A= response. This typically requires some form of session=0A= identifier. This value is only ever used by the Transport Model,=0A= so the format and interpretation of this field are model-specific=0A= and implementation-dependent.=0A= =0A= When processing an outgoing message, if tmSameSecurity is true, then=0A= the tmSessionID MUST match the current transport session, otherwise=0A= the message MUST be discarded, and the dispatcher notified that=0A= sending the message failed.=0A= =0A= 6. Abstract Service Interfaces=0A= =0A= Abstract service interfaces have been defined by RFC 3411 to describe=0A= the conceptual data flows between the various subsystems within an=0A= SNMP entity, and to help keep the subsystems independent of each=0A= other except for the common parameters.=0A= =0A= This document introduces a couple of new ASIs to define the interface=0A= between the Transport and Dispatcher Subsystems, and extends some of=0A= the ASIs defined in RFC3411 to include transport-related information.=0A= =0A= This document follows the example of RFC3411 regarding the release of=0A= state information, and regarding error indications.=0A= =0A= 1) The release of state information is not always explicitly=0A= specified in a transport model. As a general rule, if state=0A= information is available when a message gets discarded, the message-=0A= state information should also be released, and if state information=0A= is available when a session is closed, the session state information=0A= should also be released. Keeping sensitive security information=0A= longer than necessary might introduce potential vulnerabilities to an=0A= implementation.=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 21]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= 2)An error indication in statusInformation will typically include the=0A= OID and value for an incremented error counter. This may be=0A= accompanied by values for contextEngineID and contextName for this=0A= counter, a value for securityLevel, and the appropriate state=0A= reference if the information is available at the point where the=0A= error is detected.=0A= =0A= 6.1. sendMessage ASI=0A= =0A= The sendMessage ASI is used to pass a message from the Dispatcher to=0A= the appropriate Transport Model for sending. In the diagram in=0A= section 4.6.1 of RFC 3411, the sendMessage ASI defined in this=0A= document replaces the text "Send SNMP Request Message to Network".=0A= In section 4.6.2, the sendMessage ASI replaces the text "Send SNMP=0A= Message to Network"=0A= =0A= If present and valid, the tmStateReference refers to a cache=0A= containing transport-model-specific parameters for the transport and=0A= transport security. How a tmStateReference is determined to be=0A= present and valid is implementation-dependent. How the information=0A= in the cache is used is transport-model-dependent and implementation-=0A= dependent.=0A= =0A= This may sound underspecified, but a transport model might be=0A= something like SNMP over UDP over IPv6, where no security is=0A= provided, so it might have no mechanisms for utilizing a=0A= tmStateReference cache.=0A= =0A= statusInformation =3D=0A= sendMessage(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN outgoingMessage -- the message to send=0A= IN outgoingMessageLength -- its length=0A= IN tmStateReference -- reference to transport state=0A= )=0A= =0A= 6.2. Changes to RFC3411 Outgoing ASIs=0A= =0A= [DISCUSS: this section has been significantly rewritten and=0A= reorganized. This needs to be checked thoroughly to verify no=0A= technical changes have been introduced in the editorial changes.]=0A= =0A= Additional parameters have been added to the ASIs defined in RFC3411,=0A= concerned with communication between the Dispatcher and Message=0A= Processing subsystems, and between the Message Processing and=0A= Security Subsystems.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 22]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= 6.2.1. Message Processing Subsystem Primitives=0A= =0A= A tmStateReference parameter has been added as an OUT parameter to=0A= the prepareOutgoingMessage and prepareResponseMessage ASIs. This is=0A= passed from Message Processing Subsystem to the dispatcher, and from=0A= there to the Transport Subsystem.=0A= =0A= How or if the Message Processing Subsystem modifies or utilizes the=0A= contents of the cache is message-processing-model specific.=0A= =0A= statusInformation =3D -- success or errorIndication=0A= prepareOutgoingMessage(=0A= IN transportDomain -- transport domain to be used=0A= IN transportAddress -- transport address to be used=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN securityModel -- Security Model to use=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN contextEngineID -- data from/at this entity=0A= IN contextName -- data from/in this context=0A= IN pduVersion -- the version of the PDU=0A= IN PDU -- SNMP Protocol Data Unit=0A= IN expectResponse -- TRUE or FALSE=0A= IN sendPduHandle -- the handle for matching=0A= incoming responses=0A= OUT destTransportDomain -- destination transport domain=0A= OUT destTransportAddress -- destination transport address=0A= OUT outgoingMessage -- the message to send=0A= OUT outgoingMessageLength -- its length=0A= OUT tmStateReference -- (NEW) reference to transport state=0A= )=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 23]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= statusInformation =3D -- success or errorIndication=0A= prepareResponseMessage(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN securityModel -- Security Model to use=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN contextEngineID -- data from/at this entity=0A= IN contextName -- data from/in this context=0A= IN pduVersion -- the version of the PDU=0A= IN PDU -- SNMP Protocol Data Unit=0A= IN maxSizeResponseScopedPDU -- maximum size able to accept=0A= IN stateReference -- reference to state information=0A= -- as presented with the request=0A= IN statusInformation -- success or errorIndication=0A= -- error counter OID/value if error=0A= OUT destTransportDomain -- destination transport domain=0A= OUT destTransportAddress -- destination transport address=0A= OUT outgoingMessage -- the message to send=0A= OUT outgoingMessageLength -- its length=0A= OUT tmStateReference -- (NEW) reference to transport state=0A= )=0A= =0A= 6.2.2. Security Subsystem Primitives=0A= =0A= transportDomain and transportAddress parameters have been added as IN=0A= parameters to the prepareOutgoingMessage and generateResponseMsg=0A= ASIs, and a tmStateReference parameter has been added as an OUT=0A= parameter. The transportDomain and transportAddress parameters will=0A= have been passed into the Message Processing Subsystem from the=0A= dispatcher, and are passed on to the Security Subsystem. The=0A= tmStateReference parameter will be passed from the Security Subsystem=0A= back to the Message Processing Subsystem, and on to the dispatcher=0A= and Transport subsystems.=0A= =0A= If a cache exists for a session identifiable from the=0A= tmTransportDomain, tmTransportAddress, tmSecurityName and requested=0A= securityLevel, then a transport-aware Security Model might create a=0A= tmStateReference parameter to this cache, and pass that as an OUT=0A= parameter.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 24]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= statusInformation =3D=0A= generateRequestMsg(=0A= IN transportDomain -- (NEW) destination transport domain=0A= IN transportAddress -- (NEW) destination transport address=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) reference to transport state=0A= )=0A= =0A= statusInformation =3D=0A= generateResponseMsg(=0A= IN transportDomain -- (NEW) destination transport domain=0A= IN transportAddress -- (NEW) destination transport address=0A= IN messageProcessingModel -- Message Processing Model=0A= IN globalData -- msgGlobalData=0A= IN maxMessageSize -- from msgMaxSize=0A= IN securityModel -- as determined by MPM=0A= IN securityEngineID -- the value of snmpEngineID=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- for the outgoing message=0A= IN scopedPDU -- as provided by MPM=0A= IN securityStateReference -- as provided by MPM=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) reference to transport state=0A= )=0A= =0A= 6.3. The receiveMessage ASI=0A= =0A= The receiveMessage ASI is used to pass a message from the Transport=0A= Subsystem to the Dispatcher. In the diagram in section 4.6.1 of RFC=0A= 3411, the receiveMessage ASI replaces the text "Receive SNMP Response=0A= Message from Network". In section 4.6.2, the receiveMessage ASI=0A= replaces the text "Receive SNMP Message from Network".=0A= =0A= When a message is received on a given transport session, if a cache=0A= does not already exist for that session, the Transport Model might=0A= create one, referenced by tmStateReference. The contents of this=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 25]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= cache are discussed in section 5. How this information is determined=0A= is implementation- and transport-model-specific.=0A= =0A= "Might create one" may sound underspecified, but a transport model=0A= might be something like SNMP over UDP over IPv6, where transport=0A= security is not provided, so it might not create a cache.=0A= =0A= The Transport Model does not know the securityModel for an incoming=0A= message; this will be determined by the Message Processing Model in a=0A= message-processing-model-dependent manner.=0A= =0A= =0A= statusInformation =3D=0A= receiveMessage(=0A= IN transportDomain -- origin transport domain=0A= IN transportAddress -- origin transport address=0A= IN incomingMessage -- the message received=0A= IN incomingMessageLength -- its length=0A= IN tmStateReference -- reference to transport state=0A= )=0A= =0A= 6.4. Changes to RFC3411 Incoming ASIs=0A= =0A= The tmStateReference parameter has also been added to some of the=0A= incoming ASIs defined in RFC3411. How or if a Message Processing=0A= Model or Security Model uses tmStateReference is message-processing-=0A= and security-model-specific.=0A= =0A= This may sound underspecified, but a message processing model might=0A= have access to all the information from the cache and from the=0A= message. The Message Processing Model might determine that the USM=0A= Security Model is specified in an SNMPv3 message header; the USM=0A= Security Model has no need of values in the tmStateReference cache to=0A= authenticate and secure the SNMP message, but an application might=0A= have specified to use a secure transport such as that provided by the=0A= SSH Transport Model to send the message to its destination.=0A= =0A= 6.4.1. Message Processing Subsystem Primitive=0A= =0A= The tmStateReference parameter of prepareDataElements is passed from=0A= the dispatcher to the Message Processing Subsystem. How or if the=0A= Message Processing Subsystem modifies or utilizes the contents of the=0A= cache is message-processing-model-specific.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 26]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= result =3D -- SUCCESS or errorIndication=0A= prepareDataElements(=0A= IN transportDomain -- origin transport domain=0A= IN transportAddress -- origin transport address=0A= IN wholeMsg -- as received from the network=0A= IN wholeMsgLength -- as received from the network=0A= IN tmStateReference -- (NEW) from the Transport Model=0A= OUT messageProcessingModel -- typically, SNMP version=0A= OUT securityModel -- Security Model to use=0A= OUT securityName -- on behalf of this principal=0A= OUT securityLevel -- Level of Security requested=0A= OUT contextEngineID -- data from/at this entity=0A= OUT contextName -- data from/in this context=0A= OUT pduVersion -- the version of the PDU=0A= OUT PDU -- SNMP Protocol Data Unit=0A= OUT pduType -- SNMP PDU type=0A= OUT sendPduHandle -- handle for matched request=0A= OUT maxSizeResponseScopedPDU -- maximum size sender can accept=0A= OUT statusInformation -- success or errorIndication=0A= -- error counter OID/value if error=0A= OUT stateReference -- reference to state information=0A= -- to be used for possible Response=0A= )=0A= =0A= =0A= =0A= =0A= 6.4.2. Security Subsystem Primitive=0A= =0A= The processIncomingMessage ASI passes tmStateReference from the=0A= Message Processing Subsystem to the Security Subsystem.=0A= =0A= If tmStateReference is present and valid, an appropriate Security=0A= Model might utilize the information in the cache. How or if the=0A= Security Subsystem utilizes the information in the cache is security-=0A= model-specific.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 27]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= statusInformation =3D -- errorIndication or success=0A= -- error counter OID/value if error=0A= processIncomingMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN securityParameters -- for the received message=0A= IN securityModel -- for the received message=0A= IN securityLevel -- Level of Security=0A= IN wholeMsg -- as received on the wire=0A= IN wholeMsgLength -- length as received on the wire=0A= IN tmStateReference -- (NEW) from the Transport Model=0A= OUT securityEngineID -- authoritative SNMP entity=0A= OUT securityName -- identification of the principal=0A= OUT scopedPDU, -- message (plaintext) payload=0A= OUT maxSizeResponseScopedPDU -- maximum size sender can handle=0A= OUT securityStateReference -- reference to security state=0A= ) -- information, needed for response=0A= =0A= 7. Security Considerations=0A= =0A= This document defines an architectural approach that permits SNMP to=0A= utilize transport layer security services. Each proposed Transport=0A= Model should discuss the security considerations of that Transport=0A= Model.=0A= =0A= It is considered desirable by some industry segments that SNMP=0A= Transport Models should utilize transport layer security that=0A= addresses perfect forward secrecy at least for encryption keys.=0A= Perfect forward secrecy guarantees that compromise of long term=0A= secret keys does not result in disclosure of past session keys. Each=0A= proposed Transport Model should include a discussion in its security=0A= considerations of whether perfect forward security is appropriate for=0A= that Transport Model.=0A= =0A= The Denial of Service characteristics of various transport models and=0A= security protocols will vary and should be evaluated when determining=0A= the applicability of a transport model to a particular deployment=0A= situation.=0A= =0A= Since the cache will contain security-related parameters,=0A= implementers should store this information (in memory or in=0A= persistent storage) in a manner to protect it from unauthorized=0A= disclosure and/or modification.=0A= =0A= Care must be taken to ensure that a SNMP engine is sending packets=0A= out over a transport using credentials that are legal for that engine=0A= to use on behalf of that user. Otherwise an engine that has multiple=0A= transports open might be "tricked" into sending a message through the=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 28]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= wrong transport.=0A= =0A= A Security Model may have multiple sources from which to define the=0A= securityName and securityLevel. The use of a secure Transport Model=0A= does not imply that the securityName and securityLevel chosen by the=0A= Security Model represent the transport-authenticated identity or the=0A= transport-provided security services. The securityModel,=0A= securityName, and securityLevel parameters are a related set, and an=0A= administrator should understand how the specified securityModel=0A= selects the corresponding securityName and securityLevel.=0A= =0A= 7.1. Coexistence, Security Parameters, and Access Control=0A= =0A= In the RFC3411 architecture, the Message Processing Model makes the=0A= decision about which Security Model to use. The architectural change=0A= described by this document does not alter that.=0A= =0A= The architecture change described by this document does however,=0A= allow SNMP to support two different approaches to security - message-=0A= driven security and transport-driven security. With message-driven=0A= security, SNMP provides its own security, and passes security=0A= parameters within the SNMP message; with transport-driven security,=0A= SNMP depends on an external entity to provide security during=0A= transport by "wrapping" the SNMP message.=0A= =0A= In times of network stress, the security protocol and its underlying=0A= security mechanisms SHOULD NOT depend upon the ready availability of=0A= other network services (e.g., Network Time Protocol (NTP) or=0A= Authentication, Authorization, and Accounting (AAA) protocols or=0A= certificate authorities). The User-based Security Model was=0A= explicitly designed to not depend upon external network services, and=0A= provides its own security services. It is RECOMMENDED that operators=0A= provision authPriv USM to supplement any security model or transport=0A= model that has external dependencies, so that secure SNMP=0A= communications can continue when the external network service is not=0A= available.=0A= =0A= Using a non-transport-aware security model with a secure transport=0A= model is NOT RECOMMENDED, for the following reasons.=0A= =0A= Security models defined before the Transport Security Model (i.e.,=0A= SNMPv1, SNMPv2c, and USM) do not support transport-based security,=0A= and only have access to the security parameters contained within the=0A= SNMP message. They do not know about the security parameters=0A= associated with a secure transport. As a result, the Access Control=0A= Subsystem bases its decisions on the security parameters extracted=0A= from the SNMP message, not on transport-based security parameters.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 29]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= Implications of combining older security models with secure transport=0A= models are known. The securityName used for access control decisions=0A= is based on the message-driven identity, which might be=0A= unauthenticated, not the transport-driven authenticated identity:=0A= =0A= o An SNMPv1 message will always be paired with an SNMPv1 Security=0A= Model (per RFC3584), regardless of the transport mapping or=0A= transport model used, and access controls will be based on the=0A= unauthenticated community name.=0A= =0A= o An SNMPv2c message will always be paired with an SNMPv2c Security=0A= Model (per RFC3584), regardless of the transport mapping or=0A= transport model used, and access controls will be based on the=0A= unauthenticated community name.=0A= =0A= o An SNMPv3 message will always be paired with the securityModel=0A= specified in the msgSecurityParameters field of the message (per=0A= RFC3412), regardless of the transport mapping or transport model=0A= used. If the SNMPv3 message specifies the User-based Security=0A= Model (USM), with noAuthNoPriv, then the access controls will be=0A= based on the unauthenticated USM user.=0A= =0A= o For outgoing messages, if a secure transport model is selected in=0A= combination with a security model that does not populate a=0A= tmStateReference, the secure transport model SHOULD detect the=0A= lack of a valid tmStateReference and fail.=0A= =0A= 8. IANA Considerations=0A= =0A= IANA is requested to create a new registry in the Simple Network=0A= Management Protocol (SNMP) Number Spaces. The new registry should be=0A= called "SNMP Transport Domains". This registry will contain ASCII=0A= strings of one to four characters to identify prefixes for=0A= corresponding SNMP transport domains. Each transport domain requires=0A= an OID assignment under snmpDomains [RFC2578] . Values are to be=0A= assigned via [RFC5226] "Specification Required".=0A= =0A= The registry should be populated with the following initial entries:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 30]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= Registry Name: SNMP Transport Domains=0A= Reference: [RFC2578] [RFC3417] [XXXX]=0A= Registration Procedures: Specification Required=0A= Each domain is assigned a MIB-defined OID under snmpDomains=0A= =0A= Prefix snmpDomains Reference=0A= ------- ----------------------------- ---------=0A= udp snmpUDPDomain RFC3417=0A= clns snmpCLNSDomain RFC3417=0A= cons snmpCONSDomain RFC3417=0A= ddp snmpDDPDomain RFC3417=0A= ipx snmpIPXDomain RFC3417=0A= prxy rfc1157Domain RFC3417=0A= =0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= =0A= 9. Acknowledgments=0A= =0A= The Integrated Security for SNMP WG would like to thank the following=0A= people for their contributions to the process:=0A= =0A= The authors of submitted Security Model proposals: Chris Elliot, Wes=0A= Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David=0A= Perkins, Joseph Salowey, and Juergen Schoenwaelder.=0A= =0A= The members of the Protocol Evaluation Team: Uri Blumenthal,=0A= Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla.=0A= =0A= WG members who performed detailed reviews: Jeffrey Hutzelman, Bert=0A= Wijnen, Tom Petch, Wes Hardaker, and Dave Shield.=0A= =0A= 10. References=0A= =0A= 10.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for=0A= use in RFCs to Indicate=0A= Requirement Levels",=0A= BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed.,=0A= Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed.,=0A= "Structure of Management=0A= Information Version 2=0A= (SMIv2)", STD 58, RFC 2578,=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 31]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= April 1999.=0A= =0A= [RFC3411] Harrington, D., Presuhn,=0A= R., and B. Wijnen, "An=0A= Architecture for Describing=0A= Simple Network Management=0A= Protocol (SNMP) Management=0A= Frameworks", STD 62,=0A= RFC 3411, December 2002.=0A= =0A= [RFC3412] Case, J., Harrington, D.,=0A= Presuhn, R., and B. Wijnen,=0A= "Message Processing and=0A= Dispatching for the Simple=0A= Network Management Protocol=0A= (SNMP)", STD 62, RFC 3412,=0A= December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B.=0A= Wijnen, "User-based=0A= Security Model (USM) for=0A= version 3 of the Simple=0A= Network Management Protocol=0A= (SNMPv3)", STD 62,=0A= RFC 3414, December 2002.=0A= =0A= [RFC3417] Presuhn, R., "Transport=0A= Mappings for the Simple=0A= Network Management Protocol=0A= (SNMP)", STD 62, RFC 3417,=0A= December 2002.=0A= =0A= 10.2. Informative References=0A= =0A= [RFC2865] Rigney, C., Willens, S.,=0A= Rubens, A., and W. Simpson,=0A= "Remote Authentication Dial=0A= In User Service (RADIUS)",=0A= RFC 2865, June 2000.=0A= =0A= [RFC3410] Case, J., Mundy, R.,=0A= Partain, D., and B.=0A= Stewart, "Introduction and=0A= Applicability Statements=0A= for Internet-Standard=0A= Management Framework",=0A= RFC 3410, December 2002.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 32]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= [RFC3584] Frye, R., Levi, D.,=0A= Routhier, S., and B.=0A= Wijnen, "Coexistence=0A= between Version 1, Version=0A= 2, and Version 3 of the=0A= Internet-standard Network=0A= Management Framework",=0A= BCP 74, RFC 3584,=0A= August 2003.=0A= =0A= [RFC5246] Dierks, T. and E. Rescorla,=0A= "The Transport Layer=0A= Security (TLS) Protocol=0A= Version 1.2", RFC 5246,=0A= August 2008.=0A= =0A= [RFC4422] Melnikov, A. and K.=0A= Zeilenga, "Simple=0A= Authentication and Security=0A= Layer (SASL)", RFC 4422,=0A= June 2006.=0A= =0A= [RFC4251] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Protocol Architecture",=0A= RFC 4251, January 2006.=0A= =0A= [RFC4741] Enns, R., "NETCONF=0A= Configuration Protocol",=0A= RFC 4741, December 2006.=0A= =0A= [RFC5226] Narten, T. and H.=0A= Alvestrand, "Guidelines for=0A= Writing an IANA=0A= Considerations Section in=0A= RFCs", BCP 26, RFC 5226,=0A= May 2008.=0A= =0A= [I-D.ietf-isms-transport-security-model] Harrington, D. and W.=0A= Hardaker, "Transport=0A= Security Model for SNMP", d=0A= raft-ietf-isms-transport-=0A= security-model-10 (work in=0A= progress), October 2008.=0A= =0A= [I-D.ietf-isms-secshell] Harrington, D., Salowey,=0A= J., and W. Hardaker,=0A= "Secure Shell Transport=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 33]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= Model for SNMP",=0A= draft-ietf-isms-secshell-13=0A= (work in progress),=0A= November 2008.=0A= =0A= [I-D.ietf-syslog-protocol] Gerhards, R., "The syslog=0A= Protocol", draft-ietf-=0A= syslog-protocol-23 (work in=0A= progress), September 2007.=0A= =0A= Appendix A. Why tmStateReference?=0A= =0A= This appendix considers why a cache-based approach was selected for=0A= passing parameters.=0A= =0A= There are four approaches that could be used for passing information=0A= between the Transport Model and a Security Model.=0A= =0A= 1. one could define an ASI to supplement the existing ASIs, or=0A= =0A= 2. one could add a header to encapsulate the SNMP message,=0A= =0A= 3. one could utilize fields already defined in the existing SNMPv3=0A= message, or=0A= =0A= 4. one could pass the information in an implementation-specific=0A= cache or via a MIB module.=0A= =0A= A.1. Define an Abstract Service Interface=0A= =0A= Abstract Service Interfaces (ASIs) are defined by a set of primitives=0A= that specify the services provided and the abstract data elements=0A= that are to be passed when the services are invoked. Defining=0A= additional ASIs to pass the security and transport information from=0A= the Transport Subsystem to Security Subsystem has the advantage of=0A= being consistent with existing RFC3411/3412 practice, and helps to=0A= ensure that any Transport Model proposals pass the necessary data,=0A= and do not cause side effects by creating model-specific dependencies=0A= between itself and other models or other subsystems other than those=0A= that are clearly defined by an ASI.=0A= =0A= A.2. Using an Encapsulating Header=0A= =0A= A header could encapsulate the SNMP message to pass necessary=0A= information from the Transport Model to the dispatcher and then to a=0A= Message Processing Model. The message header would be included in=0A= the wholeMessage ASI parameter, and would be removed by a=0A= corresponding Message Processing Model. This would imply the (one=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 34]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= and only) messaging dispatcher would need to be modified to determine=0A= which SNMP message version was involved, and a new Message Processing=0A= Model would need to be developed that knew how to extract the header=0A= from the message and pass it to the Security Model.=0A= =0A= A.3. Modifying Existing Fields in an SNMP Message=0A= =0A= [RFC3412] defines the SNMPv3 message, which contains fields to pass=0A= security related parameters. The Transport Subsystem could use these=0A= fields in an SNMPv3 message, or comparable fields in other message=0A= formats to pass information between Transport Models in different=0A= SNMP engines, and to pass information between a Transport Model and a=0A= corresponding Message Processing Model.=0A= =0A= If the fields in an incoming SNMPv3 message are changed by the=0A= Transport Model before passing it to the Security Model, then the=0A= Transport Model will need to decode the ASN.1 message, modify the=0A= fields, and re-encode the message in ASN.1 before passing the message=0A= on to the message dispatcher or to the transport layer. This would=0A= require an intimate knowledge of the message format and message=0A= versions so the Transport Model knew which fields could be modified.=0A= This would seriously violate the modularity of the architecture.=0A= =0A= A.4. Using a Cache=0A= =0A= This document describes a cache, into which the Transport Model puts=0A= information about the security applied to an incoming message, and a=0A= Security Model can extract that information from the cache. Given=0A= that there might be multiple TM-security caches, a tmStateReference=0A= is passed as an extra parameter in the ASIs between the Transport=0A= Subsystem and the Security Subsystem, so the Security Model knows=0A= which cache of information to consult.=0A= =0A= This approach does create dependencies between a specific Transport=0A= Model and a corresponding specific Security Model. However, the=0A= approach of passing a model-independent reference to a model-=0A= dependent cache is consistent with the securityStateReference already=0A= being passed around in the RFC3411 ASIs.=0A= =0A= Appendix B. Open Issues=0A= =0A= NOTE to RFC editor: If this section is empty, then please remove this=0A= open issues section before publishing this document as an RFC. (If=0A= it is not empty, please send it back to the editor to resolve.=0A= =0A= o=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 35]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= Appendix C. Change Log=0A= =0A= NOTE to RFC editor: Please remove this change log before publishing=0A= this document as an RFC.=0A= =0A= Changes from -15- to -16-=0A= =0A= o editorial changes=0A= =0A= o clarified long-term vs short-term nature of tmState=0A= =0A= o removed any references to LCD=0A= =0A= Changes from -14- to -15-=0A= =0A= o editorial changes and reorganization=0A= =0A= Changes from -13- to -14-=0A= =0A= o=0A= =0A= Changes from -12- to -13-=0A= =0A= o moved conventions after Internet Standard framework, for=0A= consistency with related documents.=0A= =0A= o editorial changes and reorganization=0A= =0A= Changes from -10- to -12-=0A= =0A= o clarified relation to other documents.=0A= =0A= o clarified relation to older security models.=0A= =0A= o moved comparison of TSM and USM to TSM document=0A= =0A= Changes from -09- to -10-=0A= =0A= o Pointed to companion documents=0A= =0A= o Wordsmithed extensively=0A= =0A= o Modified the note about SNMPv3-consistent terminology=0A= =0A= o Modified the note about RFC2119 terminology.=0A= =0A= o Modified discussion of cryptographic key generation.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 36]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= o Added security considerations about coexistence with older=0A= security models=0A= =0A= o Expanded discussion of same session functionality=0A= =0A= o Described how sendMessage and receiveMessage fit into RFC3411=0A= diagrams=0A= =0A= o Modified prepareResponseMessage ASI=0A= =0A= Changes from -08- to -09-=0A= =0A= o A question was raised that notifications would not work properly,=0A= but we could never find the circumstances where this was true.=0A= =0A= o removed appendix with parameter matrix=0A= =0A= o Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= Changes from -07- to -08-=0A= =0A= o Identified new parameters in ASIs.=0A= =0A= o Added discussion about well-known ports.=0A= =0A= Changes from -06- to -07-=0A= =0A= o Removed discussion of double authentication=0A= =0A= o Removed all direct and indirect references to pduType by Transport=0A= Subsystem=0A= =0A= o Added warning regarding keeping sensitive security information=0A= available longer than needed.=0A= =0A= o Removed knowledge of securityStateReference from Transport=0A= Subsystem.=0A= =0A= o Changed transport session identifier to not include securityModel,=0A= since this is not known for incoming messages until the message=0A= processing model.=0A= =0A= Changes from revision -05- to -06-=0A= =0A= mostly editorial changes=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 37]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= removed some paragraphs considered unnecessary=0A= =0A= added Updates to header=0A= =0A= modified some text to get the security details right=0A= =0A= modified text re: ASIs so they are not API-like=0A= =0A= cleaned up some diagrams=0A= =0A= cleaned up RFC2119 language=0A= =0A= added section numbers to citations to RFC3411=0A= =0A= removed gun for political correctness=0A= =0A= Changes from revision -04- to -05-=0A= =0A= removed all objects from the MIB module.=0A= =0A= changed document status to "Standard" rather than the xml2rfc=0A= default of informational.=0A= =0A= =0A= =0A= changed mention of MD5 to SHA=0A= =0A= moved addressing style to TDomain and TAddress=0A= =0A= modified the diagrams as requested=0A= =0A= removed the "layered stack" diagrams that compared USM and a=0A= Transport Model processing=0A= =0A= removed discussion of speculative features that might exist in=0A= future Transport Models=0A= =0A= removed openSession and closeSession ASIs, since those are model-=0A= dependent=0A= =0A= removed the MIB module=0A= =0A= removed the MIB boilerplate intro (this memo defines a SMIv2 MIB )=0A= =0A= removed IANA considerations related to the now-gone MIB module=0A= =0A= removed security considerations related to the MIB module=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 38]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= removed references needed for the MIB module=0A= =0A= changed receiveMessage ASI to use origin transport domain/address=0A= =0A= updated Parameter CSV appendix=0A= =0A= Changes from revision -03- to -04-=0A= =0A= changed title from Transport Mapping Security Model Architectural=0A= Extension to Transport Subsystem=0A= =0A= modified the abstract and introduction=0A= =0A= changed TMSM to TMS=0A= =0A= changed MPSP to simply Security Model=0A= =0A= changed SMSP to simply Security Model=0A= =0A= changed TMSP to Transport Model=0A= =0A= removed MPSP and TMSP and SMSP from Acronyms section=0A= =0A= modified diagrams=0A= =0A= removed most references to dispatcher functionality=0A= =0A= worked to remove dependencies between transport and security=0A= models.=0A= =0A= defined snmpTransportModel enumeration similar to=0A= snmpSecurityModel, etc.=0A= =0A= eliminated all reference to SNMPv3 msgXXXX fields=0A= =0A= changed tmSessionReference back to tmStateReference=0A= =0A= Changes from revision -02- to -03-=0A= =0A= o removed session table from MIB module=0A= =0A= o removed sessionID from ASIs=0A= =0A= o reorganized to put ASI discussions in EOP section, as was done in=0A= SSHSM=0A= =0A= o changed user auth to client auth=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 39]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= o changed tmStateReference to tmSessionReference=0A= =0A= o modified document to meet consensus positions published by JS=0A= =0A= * authoritative is model-specific=0A= =0A= * msgSecurityParameters usage is model-specific=0A= =0A= * msgFlags vs. securityLevel is model/implementation-specific=0A= =0A= * notifications must be able to cause creation of a session=0A= =0A= * security considerations must be model-specific=0A= =0A= * TDomain and TAddress are model-specific=0A= =0A= * MPSP changed to SMSP (Security Model security processing)=0A= =0A= Changes from revision -01- to -02-=0A= =0A= o wrote text for session establishment requirements section.=0A= =0A= o wrote text for session maintenance requirements section.=0A= =0A= o removed section on relation to SNMPv2-MIB=0A= =0A= o updated MIB module to pass smilint=0A= =0A= o Added Structure of the MIB module, and other expected MIB-related=0A= sections.=0A= =0A= o updated author address=0A= =0A= o corrected spelling=0A= =0A= o removed msgFlags appendix=0A= =0A= o Removed section on implementation considerations.=0A= =0A= o started modifying the security boilerplate to address TMS and MIB=0A= security issues=0A= =0A= o reorganized slightly to better separate requirements from proposed=0A= solution. This probably needs additional work.=0A= =0A= o removed section with sample protocols and sample=0A= tmSessionReference.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 40]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= o Added section for acronyms=0A= =0A= o moved section comparing parameter passing techniques to appendix.=0A= =0A= o Removed section on notification requirements.=0A= =0A= Changes from revision -00-=0A= =0A= o changed SSH references from I-Ds to RFCs=0A= =0A= o removed parameters from tmSessionReference for DTLS that revealed=0A= lower layer info.=0A= =0A= o Added TMS-MIB module=0A= =0A= o Added Internet-Standard Management Framework boilerplate=0A= =0A= o Added Structure of the MIB Module=0A= =0A= o Added MIB security considerations boilerplate (to be completed)=0A= =0A= o Added IANA Considerations=0A= =0A= o Added ASI Parameter table=0A= =0A= o Added discussion of Sessions=0A= =0A= o Added Open issues and Change Log=0A= =0A= o Rearranged sections=0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 41]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= =0A= Phone: +49 421 200-3587=0A= EMail: j.schoenwaelder@iu-bremen.de=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 42]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem January 2009=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2009).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires July 26, 2009 [Page 43]=0A= =0C=0A= =0A= ------=_NextPart_000_0CAE_01C97CA8.23322A90 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_0CAE_01C97CA8.23322A90-- From isms-bounces@ietf.org Fri Jan 23 07:59:33 2009 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 7218A3A67F2; Fri, 23 Jan 2009 07:59:33 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35033A67F2 for ; Fri, 23 Jan 2009 07:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 dACchi9FznY0 for ; Fri, 23 Jan 2009 07:59:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 135703A67A7 for ; Fri, 23 Jan 2009 07:59:26 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A060C002B; Fri, 23 Jan 2009 16:59:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6ugbmRLfc2Qu; Fri, 23 Jan 2009 16:59:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A536C0111; Fri, 23 Jan 2009 16:59:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 40A8F918E4C; Fri, 23 Jan 2009 16:58:57 +0100 (CET) Date: Fri, 23 Jan 2009 16:58:57 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090123155857.GB9375@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <0cad01c97cd2$0c083290$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0cad01c97cd2$0c083290$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] tmsm pre-16 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, Jan 22, 2009 at 03:43:13PM -0500, David Harrington wrote: > I think I have covered all the WGLC comments. Thanks David for getting the edits done. Can the WG members please review the changes? It would be nice to see feedback posted to the list (and feedback might very well be that you are happy with the changes). /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 Jan 23 07:59:51 2009 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 87AD628C13B; Fri, 23 Jan 2009 07:59:51 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F983A67A7 for ; Fri, 23 Jan 2009 07:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whJWsKqcLLIC for ; Fri, 23 Jan 2009 07:59:50 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3EA1C3A6923 for ; Fri, 23 Jan 2009 07:59:50 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 461CEC0111; Fri, 23 Jan 2009 16:59:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id h3M7naxZFH2X; Fri, 23 Jan 2009 16:59:25 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D588C0112; Fri, 23 Jan 2009 16:59:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 00391918E73; Fri, 23 Jan 2009 16:59:21 +0100 (CET) Date: Fri, 23 Jan 2009 16:59:21 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090123155921.GC9375@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <0cb101c97cd2$203d8990$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0cb101c97cd2$203d8990$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] tsm pre11 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, Jan 22, 2009 at 03:43:47PM -0500, David Harrington wrote: > I think I have covered all the WGLC comments Thanks David for getting the edits done. Can the WG members please review the changes? It would be nice to see feedback posted to the list (and feedback might very well be that you are happy with the changes). /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 Jan 23 08:02:10 2009 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 072673A6ABF; Fri, 23 Jan 2009 08:02:10 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFCB3A6ABF for ; Fri, 23 Jan 2009 08:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 0Mb5zcFQM3+Y for ; Fri, 23 Jan 2009 08:02:03 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CC7F83A6A79 for ; Fri, 23 Jan 2009 08:01:59 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D357AC0113; Fri, 23 Jan 2009 17:01:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id J3PqOB9Ktp2F; Fri, 23 Jan 2009 17:01:35 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F03BDC002B; Fri, 23 Jan 2009 17:01:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AF09E918EC1; Fri, 23 Jan 2009 17:01:30 +0100 (CET) Date: Fri, 23 Jan 2009 17:01:30 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090123160130.GD9375@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <0ca901c97cd1$ed7310c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0ca901c97cd1$ed7310c0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] secshell-pre14 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, Jan 22, 2009 at 03:42:22PM -0500, David Harrington wrote: > This is an updated draft for secshell. > > We still need work on > 1) the processes for client versus server > 2) two ports > > otherwise I think I have covered all the WGLC comments Thanks David for getting the edits done. Can you elaborate on the open issues you see? - I think we reached consensus that we need two port numbers - does this address 2)? - I am not sure what "two processes for client versus server" means. Can the WG members please review the changes? It would be nice to see feedback posted to the list (and feedback might very well be that you are happy with the changes). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 26 04:28:40 2009 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 220F13A6B73; Mon, 26 Jan 2009 04:28:40 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E953A6B73 for ; Mon, 26 Jan 2009 04:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-0.744, 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 7wnebwGyQTVa for ; Mon, 26 Jan 2009 04:28:37 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 7096F3A6B6E for ; Mon, 26 Jan 2009 04:28:37 -0800 (PST) X-Trace: 70816953/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.114/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.114 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAJs7fUk+vGRy/2dsb2JhbACDRYoasDcJi3wBBYQUgTE X-IronPort-AV: E=Sophos;i="4.37,324,1231113600"; d="scan'208";a="70816953" X-IP-Direction: IN Received: from 1cust114.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.114]) by smtp.pipex.tiscali.co.uk with SMTP; 26 Jan 2009 12:28:13 +0000 Message-ID: <00d001c97fa9$16ccf060$0601a8c0@allison> From: "tom.petch" To: , "David Harrington" References: <0ba601c97beb$a8ec4fc0$0600a8c0@china.huawei.com><0bc301c97c15$7eabb730$0600a8c0@china.huawei.com><0bca01c97c16$ad4dc690$0600a8c0@china.huawei.com> <20090122080118.GA929@elstar.local> Date: Mon, 26 Jan 2009 12:11:18 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] IsmsSNMP SSH ports 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: "David Harrington" Cc: Sent: Thursday, January 22, 2009 9:01 AM Subject: Re: [Isms] IsmsSNMP SSH ports > On Wed, Jan 21, 2009 at 05:21:59PM -0500, David Harrington wrote: > > > I think we need two *registered* ports, and I recommend requesting > > 5161 and 5162. > > This sounds like a good concensus position. WG members should speak up > now if they disagree with this resolution. > Works for me. I would suggest amending the examples in tsm to match. Tom Petch > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 27 10:22:44 2009 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 8D7D628C1C7; Tue, 27 Jan 2009 10:22:44 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC34A28C1B5 for ; Tue, 27 Jan 2009 10:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 Tps4Pu5guTD6 for ; Tue, 27 Jan 2009 10:22:42 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id D2CD328C1C8 for ; Tue, 27 Jan 2009 10:22:41 -0800 (PST) X-Trace: 215048315/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.3/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.3 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAJrffkk+vGkD/2dsb2JhbACDRkCJXq9PCY4SAQWEFIEy X-IronPort-AV: E=Sophos;i="4.37,333,1231113600"; d="scan'208";a="215048315" X-IP-Direction: IN Received: from 1cust3.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.3]) by smtp.pipex.tiscali.co.uk with SMTP; 27 Jan 2009 18:22:21 +0000 Message-ID: <006f01c980a3$b7cd9d20$0601a8c0@allison> From: "tom.petch" To: , "David Harrington" References: <0b9501c97be4$024201d0$0600a8c0@china.huawei.com><20090122194722.GB7322@elstar.local><0cc301c97cd8$dcaff8f0$0600a8c0@china.huawei.com> <20090122231008.GA7514@elstar.local> Date: Tue, 27 Jan 2009 17:57:55 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] ssh authn X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I have no problem with the original formulation. If you do opt for Juergen's, I would prefer 'other parameters' - as in the original - to just 'parameters'. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David Harrington" Cc: Sent: Friday, January 23, 2009 12:10 AM Subject: Re: [Isms] ssh authn > On Thu, Jan 22, 2009 at 04:32:01PM -0500, David Harrington wrote: > > Hi, > > > > sentence 1 talks about server authn, which I assume means RFC4253. > > sentences 2-4 talk about user authn, which I assume means RFC4252 > > sentence 5 talks about server authn, which I assume means RFC4253. > > > > It strikes me that this paragraph should be reworked to separate the > > server auth and the user auth discussions. > > > > Unless, of course, I am misunderstanding this text. > > Maybe this is about how to use tmTransportAddress during server authn, > > and it just is not clear. > > > > is this all about server authn, or is client and server authn mixed in > > this paragraph? > > So you want to change this text to something like this: > > Using tmTransportAddress, the client will establish an SSH > transport connection using the SSH transport protocol, authenticate > the server, and exchange keys for message integrity and encryption. > The parameters of the transport connection and the credentials used > to authenticate the server are provided in an implementation-dependent > manner. > > The tmTransportAddress field may contain a user-name followed by an > '@' character (ASCII 0x40) that will indicate a specific user-name > string that should be presented to the ssh server as the "user > name" for user authentication purposes. This user-name MAY be > different than the passed tmSecurityName value that will be used in > the remaining steps below. If there is no specified user-name in > the tmTransportAddress then the tmSecurityName should be used as > the user-name. > > Such a change is fine with me. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 28 14:58:20 2009 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 782B328C1E3; Wed, 28 Jan 2009 14:58:20 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF31828C1C4 for ; Wed, 28 Jan 2009 14:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 im49dtxgm3vy for ; Wed, 28 Jan 2009 14:58:18 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id C85A028C1BC for ; Wed, 28 Jan 2009 14:58:17 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 92ii1b00B0bG4ec54Ay0od; Wed, 28 Jan 2009 22:58:00 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id 9Axz1b00H0UQ6dC3PAxzp4; Wed, 28 Jan 2009 22:58:00 +0000 From: "David B Harrington" To: , References: <20090127083933.GC12355@elstar.local> Date: Wed, 28 Jan 2009 17:57:58 -0500 Message-ID: <015201c9819b$dd873730$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090127083933.GC12355@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmAWtEVeYB7oj+aRESrKYUC9boY1gBJbTDA Subject: [Isms] TBD secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, The EOP need to be updated to deal with two ports. There is a potential issue I have not yet researched; the transport model establishes the connection. But the transport model does not know the operation type. So how will it know which port to use? Of course, we have the port in the transport address, so it can just work from that basis, but I am not sure it knows what it needs to know to do that. In one case it needs to act as an ssh client; in the other it needs to act as a server - and that means the transport model needs to know which type of operation. This violates the RFC3411 architecture established by the SNMPv3 WG, and it has serious ramifications on other potential models for various subsystems; it is not in scope to modify how those other subsystems work. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, January 27, 2009 3:40 AM > To: Dave Harrington > Subject: [j.schoenwaelder@jacobs-university.de: Re: [Isms] > secshell-pre14] > > David, > > can you quickly explain the issues? I would like to move forward with > resolving them and push for a second last call. > > /js > > ----- Forwarded message from Juergen Schoenwaelder > ----- > > Date: Fri, 23 Jan 2009 17:01:30 +0100 > From: Juergen Schoenwaelder > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] secshell-pre14 > Message-ID: <20090123160130.GD9375@elstar.local> > > On Thu, Jan 22, 2009 at 03:42:22PM -0500, David Harrington wrote: > > > This is an updated draft for secshell. > > > > We still need work on > > 1) the processes for client versus server > > 2) two ports > > > > otherwise I think I have covered all the WGLC comments > > Thanks David for getting the edits done. Can you elaborate on the open > issues you see? > > - I think we reached consensus that we need two port > numbers - does this > address 2)? > > - I am not sure what "two processes for client versus server" means. > > Can the WG members please review the changes? It would be nice to see > feedback posted to the list (and feedback might very well be that you > are happy with the changes). > > /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 > > ----- End forwarded message ----- > > -- > 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 Jan 28 15:10:34 2009 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 7F4DB28C1C4; Wed, 28 Jan 2009 15:10:34 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C56B28C1AD for ; Wed, 28 Jan 2009 15:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.472, 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 hT8vdRkn6eym for ; Wed, 28 Jan 2009 15:10:31 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 9461C28C17E for ; Wed, 28 Jan 2009 15:10:31 -0800 (PST) Received: from 173-114-124-216.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0SNA8Rn008640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 18:10:09 -0500 (EST) Date: Wed, 28 Jan 2009 18:10:08 -0500 From: Jeffrey Hutzelman To: David B Harrington , j.schoenwaelder@jacobs-university.de, isms@ietf.org Message-ID: <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> In-Reply-To: <200901282258.n0SMw53g024330@toasties.srv.cs.cmu.edu> References: <20090127083933.GC12355@elstar.local> <200901282258.n0SMw53g024330@toasties.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: jhutz@cmu.edu Subject: Re: [Isms] TBD secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, January 28, 2009 05:57:58 PM -0500 David B Harrington wrote: > Hi, > > The EOP need to be updated to deal with two ports. > > There is a potential issue I have not yet researched; the transport > model establishes the > connection. But the transport model does not know the operation type. > So how will it know which port to use? Of course, we have the port in > the transport address, so it can just work from that basis, but I am > not sure it knows what it needs to know to do that. In one case it > needs to act as an ssh client; in the other it needs to act as a > server No. The entity that is establishing a new ssh session is always the ssh client. The more interesting question is which default port to use if one is not specified in the transport address, as this depends upon whether one is sending a command or notification. How do the existing transports do this? -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 28 15:36:36 2009 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 309413A6899; Wed, 28 Jan 2009 15:36:36 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429AF3A6899 for ; Wed, 28 Jan 2009 15:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 EYi5xfHeGGA2 for ; Wed, 28 Jan 2009 15:36:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 052153A67E2 for ; Wed, 28 Jan 2009 15:36:32 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16525C0035; Thu, 29 Jan 2009 00:36:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0D+7MJ8VMF6S; Thu, 29 Jan 2009 00:36:07 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CC05C003E; Thu, 29 Jan 2009 00:36:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 01C3091C998; Thu, 29 Jan 2009 00:36:01 +0100 (CET) Date: Thu, 29 Jan 2009 00:36:01 +0100 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20090128233601.GC14106@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , David B Harrington , isms@ietf.org References: <20090127083933.GC12355@elstar.local> <200901282258.n0SMw53g024330@toasties.srv.cs.cmu.edu> <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: David B Harrington , isms@ietf.org Subject: Re: [Isms] TBD secshell 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, Jan 28, 2009 at 06:10:08PM -0500, Jeffrey Hutzelman wrote: > The more interesting question is which default port to use if one is not > specified in the transport address, as this depends upon whether one is > sending a command or notification. How do the existing transports do > this? The SnmpUDPAddress always contains a port number and the same is true for the formats defined in RFC 3419. So once you have an TAddress, everything should be fine. /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 Jan 28 15:45:11 2009 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 CCDC13A6C19; Wed, 28 Jan 2009 15:45:11 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B7A28C15A for ; Wed, 28 Jan 2009 15:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAB0qwnBhbND for ; Wed, 28 Jan 2009 15:45:10 -0800 (PST) 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 E58EB3A63D3 for ; Wed, 28 Jan 2009 15:45:09 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 8zSb1b0020EZKEL52BkrbG; Wed, 28 Jan 2009 23:44:51 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 9Bkr1b00A0UQ6dC3MBkry2; Wed, 28 Jan 2009 23:44:51 +0000 From: "David B Harrington" To: References: <20090127083933.GC12355@elstar.local> <200901282258.n0SMw53g024330@toasties.srv.cs.cmu.edu> <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> Date: Wed, 28 Jan 2009 18:44:50 -0500 Message-ID: <015601c981a2$69202850$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmBnZNsgE0TciM0QG6qIuNwZiT/WAAAj8aQ Subject: Re: [Isms] TBD secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, That would seem correct. Regardess of operation, if the connection is initiated by the sender, the sender is a client. And that means the application MUST provide the port in the transportAddress. If it is an incoming request, the correct port is stored the securityStateRef. If it is a response or report, the correct port is extracted from the securityStateRef. There may still be some work TBD to clarify EOP on incoming versus outgoing processing for SSH support. On 11/27, Pasi raised some specific questions about the EOP in revision 13 that need to be addressed. Here are a couple, but not all the points he raised: - Section 5.1, we should say what the tmTransportAddress for incoming messages looks on the SSH server side: it's "address:port" form (not user@address:port). - Section 5.1: we need a better description of how tmSecurityName works on the SSH client side; IMHO the current behavior isn't quite right: Suppose a command generator sends a command with tmSecurityName="alice" and destTransportAddress="ahopkins@router1.example.net:1234". An SSH connection is opened and so on. When the command response is received, the current text in Section 5.1 would lead to having tmSecurityName="ahopkins" in the response -- a slightly unexpected response. - Section 5.3, step 1: it would be *really* useful to add a note that to authenticate the server, the client usually stores (destTransportAddress, server host public key) pairs in implementation-dependent manner. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, January 28, 2009 6:10 PM > To: David B Harrington; j.schoenwaelder@jacobs-university.de; > isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] TBD secshell > > --On Wednesday, January 28, 2009 05:57:58 PM -0500 David B Harrington > wrote: > > > Hi, > > > > The EOP need to be updated to deal with two ports. > > > > There is a potential issue I have not yet researched; the transport > > model establishes the > > connection. But the transport model does not know the > operation type. > > So how will it know which port to use? Of course, we have > the port in > > the transport address, so it can just work from that basis, but I am > > not sure it knows what it needs to know to do that. In one case it > > needs to act as an ssh client; in the other it needs to act as a > > server > > No. The entity that is establishing a new ssh session is > always the ssh > client. > > The more interesting question is which default port to use if > one is not > specified in the transport address, as this depends upon > whether one is > sending a command or notification. How do the existing > transports do this? > > -- Jeff > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 28 15:59:58 2009 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 18E9428C1AD; Wed, 28 Jan 2009 15:59:58 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7500E28C1AD for ; Wed, 28 Jan 2009 15:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 wFhHrkpI7b7y for ; Wed, 28 Jan 2009 15:59:55 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 7B61628C17E for ; Wed, 28 Jan 2009 15:59:55 -0800 (PST) Received: from 173-114-124-216.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0SNxUBX010061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 18:59:30 -0500 (EST) Date: Wed, 28 Jan 2009 18:59:30 -0500 From: Jeffrey Hutzelman To: David B Harrington , isms@ietf.org Message-ID: In-Reply-To: <200901282344.n0SNiunA000877@grapenut.srv.cs.cmu.edu> References: <20090127083933.GC12355@elstar.local> <200901282258.n0SMw53g024330@toasties.srv.cs.cmu.edu> <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> <200901282344.n0SNiunA000877@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.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] TBD secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, January 28, 2009 06:44:50 PM -0500 David B Harrington wrote: > That would seem correct. Top-posting makes it really hard to understand what you are replying to. > - Section 5.1, we should say what the tmTransportAddress for incoming > messages looks on the SSH server side: it's "address:port" form (not > user@address:port). Right. > - Section 5.1: we need a better description of how tmSecurityName > works on the SSH client side; IMHO the current behavior isn't quite > right: Suppose a command generator sends a command with > tmSecurityName="alice" and > destTransportAddress="ahopkins@router1.example.net:1234". An SSH > connection is opened and so on. When the command response is received, > the current text in Section 5.1 would lead to having > tmSecurityName="ahopkins" in the response -- a slightly unexpected > response. As I understand it, the request and response don't carry tmSecurityName, which is information passed between the TM and the upper layers. The request carries a securityName, and if that is "alice" then the securityName in the response should also be "alice". If a request is sent with securityName="alice" via an SSH transport using transport address "ahopkins@router1.example.net:1234", then what happens next depends on whether tsm or some other security model is used. At the receiver, tmSecurityName is going to be "ahopkins", derived from the SSH user name. If the security model in use is TSM, then TSM is going to look at that value, compare it to the securityName in the message, and reject the request because they do not match. So, there will never be a response. If the security model in use is _not_ TSM, then the value of tmSecurityName is irrelevant. > - Section 5.3, step 1: it would be *really* useful to add a note > that to authenticate the server, the client usually stores > (destTransportAddress, server host public key) pairs in > implementation-dependent manner. That depends on the key exchange method. There's not always a host key involved, which is one of the reasons we declined to standardize this in detail. Certainly a client needs to know, given a transport address, how to verify that an ssh connection opened to that address is actually connected to the correct peer. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 28 17:08:43 2009 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 807073A689E; Wed, 28 Jan 2009 17:08:43 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D1728C15A for ; Wed, 28 Jan 2009 17:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dybUipS5641b for ; Wed, 28 Jan 2009 17:08:41 -0800 (PST) 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 9E27D3A6869 for ; Wed, 28 Jan 2009 17:08:41 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 95WH1b00B0SCNGk52D8Q0K; Thu, 29 Jan 2009 01:08:24 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 9D8Q1b00M0UQ6dC3VD8QVG; Thu, 29 Jan 2009 01:08:24 +0000 From: "David B Harrington" To: References: <20090127083933.GC12355@elstar.local> <200901282258.n0SMw53g024330@toasties.srv.cs.cmu.edu> <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> <200901282344.n0SNiunA000877@grapenut.srv.cs.cmu.edu> Date: Wed, 28 Jan 2009 20:08:23 -0500 Message-ID: <015c01c981ae$15235720$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmBpHobHrf/Mz9lRvml8/QkUE2CygAAIcIQ Subject: Re: [Isms] TBD secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > Top-posting makes it really hard to understand what you are > replying to. (sorry. I intended a really short reply.) > As I understand it, the request and response don't carry > tmSecurityName, > which is information passed between the TM and the upper layers. The > request carries a securityName, and if that is "alice" then the > securityName in the response should also be "alice". > > If a request is sent with securityName="alice" via an SSH > transport using > transport address "ahopkins@router1.example.net:1234", then > what happens > next depends on whether tsm or some other security model is > used. At the > receiver, tmSecurityName is going to be "ahopkins", derived > from the SSH > user name. If the security model in use is TSM, then TSM is > going to look > at that value, compare it to the securityName in the message, I think there is no securityName in the message. Per TSM 4.2 3) 3) Set securityParameters to a zero-length OCTET STRING ('0400'). > and reject > the request because they do not match. Per rfc3412, matching is done by message processing models, in the prepareDataElements EOP. prepareDataElements takes only a transportDomain, transportAddress, a wholeMsg and a message length as input. It returns the sendPDUHandle that identifies the matching request, which is used to direct the response to the appropriate application. The user@ feature is an SSHTM-specific feature, not a TSM feature. I think SSHTM needs to pass a transportAddress for the response that will match the one used in the request. This is symmetrical - it is the SSHTM that takes the requested ahopkins@... transportAddress and splits it into an address and a user name. SSHTM should put "ahopkins@" and the address back together into a corresponding transportAddress. Then the appropriate MPM can find the sendPDUHandle. tmSecurityName is set to "alice" by TSM. SSHTM is the place where the requested tmSecurityName "alice" is overridden, and ahopkins is chosen as the user name. For an incoming response, SSHTM should determine that the matching tmSecurityName for the response should be "alice", not "ahopkins". This would seem to require an internal mapping table that keeps track of all the alice-to-"ahopkins@" conversions done going outward, and back-converting them on the way in. This might require some type of transport-mapping-specific sendPDUHandle for matching specific requests and responses. dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 28 19:08:49 2009 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 3D6B328C11F; Wed, 28 Jan 2009 19:08:49 -0800 (PST) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0972F3A693F for ; Wed, 28 Jan 2009 19:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=0.459, 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 Z3qrOMcnHX1D for ; Wed, 28 Jan 2009 19:08:47 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id EF1453A6872 for ; Wed, 28 Jan 2009 19:08:46 -0800 (PST) Received: from 173-114-124-216.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0T38O24014062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 22:08:24 -0500 (EST) Date: Wed, 28 Jan 2009 22:08:24 -0500 From: Jeffrey Hutzelman To: David B Harrington , isms@ietf.org Message-ID: <8026D632B9CA159AAC2154FA@atlantis.pc.cs.cmu.edu> In-Reply-To: <200901290108.n0T18S7R014276@raisinbran.srv.cs.cmu.edu> References: <20090127083933.GC12355@elstar.local> <200901282258.n0SMw53g024330@toasties.srv.cs.cmu.edu> <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> <200901282344.n0SNiunA000877@grapenut.srv.cs.cmu.edu> <200901290108.n0T18S7R014276@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: jhutz@cmu.edu Subject: Re: [Isms] TBD secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, January 28, 2009 08:08:23 PM -0500 David B Harrington wrote: > >> Top-posting makes it really hard to understand what you are >> replying to. > (sorry. I intended a really short reply.) > >> As I understand it, the request and response don't carry >> tmSecurityName, >> which is information passed between the TM and the upper layers. > The >> request carries a securityName, and if that is "alice" then the >> securityName in the response should also be "alice". >> >> If a request is sent with securityName="alice" via an SSH >> transport using >> transport address "ahopkins@router1.example.net:1234", then >> what happens >> next depends on whether tsm or some other security model is >> used. At the >> receiver, tmSecurityName is going to be "ahopkins", derived >> from the SSH >> user name. If the security model in use is TSM, then TSM is >> going to look >> at that value, compare it to the securityName in the message, > > I think there is no securityName in the message. > Per TSM 4.2 3) > 3) Set securityParameters to a zero-length OCTET STRING ('0400'). > >> and reject >> the request because they do not match. > > Per rfc3412, matching is done by message processing models, in the > prepareDataElements EOP. prepareDataElements takes only a > transportDomain, transportAddress, a wholeMsg and a message length as > input. It returns the sendPDUHandle that identifies the matching > request, which is used to direct the response to the appropriate > application. > > The user@ feature is an SSHTM-specific feature, not a TSM feature. I > think SSHTM needs to pass a transportAddress for the response that > will match the one used in the request. This is symmetrical - it is > the SSHTM that takes the requested ahopkins@... transportAddress and > splits it into an address and a user name. SSHTM should put > "ahopkins@" and the address back together into a corresponding > transportAddress. Then the appropriate MPM can find the sendPDUHandle. > > tmSecurityName is set to "alice" by TSM. SSHTM is the place where the > requested tmSecurityName "alice" is overridden, and ahopkins is chosen > as the user name. For an incoming response, SSHTM should determine > that the matching tmSecurityName for the response should be "alice", > not "ahopkins". This would seem to require an internal mapping table > that keeps track of all the alice-to-"ahopkins@" conversions done > going outward, and back-converting them on the way in. This might > require some type of transport-mapping-specific sendPDUHandle for > matching specific requests and responses. You're making this all too complicated, I think. The purpose of the username part of the transport address is to supply a value for the ssh username when we are originating an ssh connection in a situation where just using the security name won't work. It shouldn't ever be compared or copied to anything else. Most especially, the ssh username used to authenticate an incoming connection should _not_ make its way into the transport address, because that would cause it to be used when trying to send a message back, which would be the wrong thing. This user@ thing is deliberately asymmetric, to accommodate an asymmetry in the SSH protocol. Sorry, that's about all I can think about this for now; I haven't slept in a while and am not likely to be coherent for much longer, if I even still am. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms