From isms-bounces@lists.ietf.org Thu Mar 01 02:42:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMfw4-0003Y2-A4; Thu, 01 Mar 2007 02:42:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMfw3-0003Xs-3c for isms@ietf.org; Thu, 01 Mar 2007 02:42:43 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMfw1-00045z-L1 for isms@ietf.org; Thu, 01 Mar 2007 02:42:43 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3D8996DA24; Thu, 1 Mar 2007 08:42:41 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31669-07; Thu, 1 Mar 2007 08:42:38 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 091356DA1A; Thu, 1 Mar 2007 08:42:38 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 5AE051B4621; Thu, 1 Mar 2007 08:42:36 +0100 (CET) Date: Thu, 1 Mar 2007 08:42:36 +0100 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Subject: Re: [Isms] Request-response pairs Message-ID: <20070301074236.GA13111@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Jeffrey Hutzelman , David Harrington , isms@ietf.org References: <20c801c75a9c$d16c4440$0600a8c0@china.huawei.com> <59C85CC4D01D2312469A0EC8@sirius.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59C85CC4D01D2312469A0EC8@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Wed, Feb 28, 2007 at 06:49:43PM -0500, Jeffrey Hutzelman wrote: > >If this is a requirement, then I think we can sucessfully say that > >SNMP should not use lower layer security services, but should do > >everything internally like USM does. > > I think that's being a little extreme. We can solve the problem without > throwing everything away and starting over, and I think we should. All > that is required si for the SM to send some opaque thing up the stack to > the application, which is sent back down with the response. This thing > contains whatever the SM needs to insure the response goes back over the > same session, if that is required (and the SM gets to decide this, or > perhaps the SM specification gets to specify this). For messages that are > not responses, the "thing" is omitted, which tells the SM it can use any > session it likes. > > BTW, this is still a security issue - it is the SM that gets to decide > whether the same session is needed, not the transport mapping, and thus it > is the SM that needs to toss an opaque object "over the fence" so to speak. I thought that the existing securityStateReference actually serves this purpose. This reference is passed out of the security model when a message is received and passsed back into the security model when a response for such a message must be sent. The transport security model interacts with the secure transport via the tmStateReference and it seems all we have to do is to stick the tmStateReference into the securityStateReferences and when sending a response, we have to check that the tmStateReference in the securityStateReference matches the tmStateReference we lookup in the secure transport model. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Mar 04 16:15:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNy2c-0004rA-Tb; Sun, 04 Mar 2007 16:14:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNy2b-0004r5-EU for isms@ietf.org; Sun, 04 Mar 2007 16:14:49 -0500 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNy2a-0007g0-73 for isms@ietf.org; Sun, 04 Mar 2007 16:14:49 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc16) with SMTP id <20070304211447b16008k70pe>; Sun, 4 Mar 2007 21:14:47 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , References: <20c801c75a9c$d16c4440$0600a8c0@china.huawei.com> <59C85CC4D01D2312469A0EC8@sirius.fac.cs.cmu.edu> Subject: RE: [Isms] Request-response pairs Date: Sun, 4 Mar 2007 16:10:35 -0500 Message-ID: <007f01c75ea1$8da031a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcdbkyHgvt7MfPjwQYWMH9XR3FzXFQDCxh1w In-reply-to: <59C85CC4D01D2312469A0EC8@sirius.fac.cs.cmu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi Jeff, Please send the text needed for the TMSM draft, the Transport Security Model draft, and the SSH Transport Model draft. Please be sure to describe the changes that would be made to the ASIs in RFC3411 and RFC3412, and any changes to the elements of procedure in RFC3413 for each application, and any corresponding changes to the other Transport Mappings, e.g. the UDP transport mapping, defined in RFC3417, and any changes needed to RFC3414 (USM). I am not trying to be difficult; I just don't think you've done the work of understanding all the changes that might be required. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > [...] > All > that is required si for the SM to send some opaque thing up > the stack to > the application, which is sent back down with the response. > This thing > contains whatever the SM needs to insure the response goes > back over the > same session, if that is required (and the SM gets to decide > this, or > perhaps the SM specification gets to specify this). For > messages that are > not responses, the "thing" is omitted, which tells the SM it > can use any > session it likes. > > BTW, this is still a security issue - it is the SM that gets > to decide > whether the same session is needed, not the transport > mapping, and thus it > is the SM that needs to toss an opaque object "over the > fence" so to speak. > > -- Jeff > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Mar 04 20:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO27N-0003yu-2d; Sun, 04 Mar 2007 20:36:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO27L-0003yM-Rb for isms@ietf.org; Sun, 04 Mar 2007 20:35:59 -0500 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO27K-0006Jb-KZ for isms@ietf.org; Sun, 04 Mar 2007 20:35:59 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc15) with SMTP id <20070305013557b1500a2v0oe>; Mon, 5 Mar 2007 01:35:58 +0000 From: "David Harrington" To: "'Wes Hardaker'" References: <166c01c751d2$71865700$0600a8c0@china.huawei.com><20070227095256.GA8692@elstar.iuhb02.iu-bremen.de><20b801c75a89$5415e950$0600a8c0@china.huawei.com> Subject: RE: [Isms] Tmsm#4: persistent session info Date: Sun, 4 Mar 2007 20:31:44 -0500 Message-ID: <009101c75ec6$0924a300$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcdanAWt7lOjbR5nRcu6IXC/Yc38LgEKdslg In-reply-to: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Added the following: "Note that keeping security sensitive information longer then necessary might introduce potential vulnerabilities to an implementation." Is that acceptable? dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Tuesday, February 27, 2007 1:21 PM > To: David Harrington > Cc: j.schoenwaelder@iu-bremen.de; isms@ietf.org > Subject: Re: [Isms] Tmsm#4: persistent session info > > >>>>> "DH" == David Harrington writes: > > DH> I believe the complaint is that we specified the state > was released > DH> when the session is closed; this should be an > implementation decision, > DH> since all release handling is implementation-specific. > > I'd suggest you word in a way it such that the following happens: > > 1) some state MUST be zeroized and freed immediately for security > reasons (keys). > 2) other state MAY be kept around by the implementation or > released immediately. > > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Mar 05 08:25:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODBw-0004Dl-0D; Mon, 05 Mar 2007 08:25:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODBs-0003vu-Hg for isms@ietf.org; Mon, 05 Mar 2007 08:25:24 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOD7X-0005rn-Q1 for isms@ietf.org; Mon, 05 Mar 2007 08:20:58 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20070305132053b1400fs1b0e>; Mon, 5 Mar 2007 13:20:53 +0000 From: "David Harrington" To: Date: Mon, 5 Mar 2007 08:16:39 -0500 Message-ID: <00a801c75f28$830c7230$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A9_01C75EFE.9A3B2520" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcdfJ+mMrxAzoA0IStCLt8L+3q6iMA== X-Spam-Score: 0.0 (/) X-Scan-Signature: be260577393d2c043fbd50d7f13cf3df Cc: Subject: [Isms] Draft-ietf-isms-tmsm-07-prerelease X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C75EFE.9A3B2520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I updated TMSM to address most of the open issues, and submitted it for publication. I also cleaned up the modularity somewhat, eliminating most references to information not seen by the Transport Subsystem. I think more needs to be done on this point. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_00A9_01C75EFE.9A3B2520 Content-Type: text/plain; name="draft-ietf-isms-tmsm-07-prerelease.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-tmsm-07-prerelease.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) International University Bremen=0A= Intended status: Standards Track March 4, 2007=0A= Expires: September 5, 2007=0A= =0A= =0A= Transport Subsystem for the Simple Network Management Protocol (SNMP)=0A= draft-ietf-isms-tmsm-07=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 September 5, 2007.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The IETF Trust (2007).=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 transport to include secure transport=0A= such as SSH and TLS, using a subsystem will enable consistent design=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 1]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =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= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 3=0A= 1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 3=0A= 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 3. Requirements of a Transport Model . . . . . . . . . . . . . . 7=0A= 3.1. Message Security Requirements . . . . . . . . . . . . . . 7=0A= 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 7=0A= 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8=0A= 3.2.1. Architectural Modularity Requirements . . . . . . . . 8=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 . . . . 14=0A= 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14=0A= 3.3.1. Session Establishment Requirements . . . . . . . . . . 15=0A= 3.3.2. Session Maintenance Requirements . . . . . . . . . . . 16=0A= 3.3.3. 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= 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 19=0A= 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 19=0A= 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 20=0A= 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 21=0A= 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 22=0A= 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23=0A= 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24=0A= 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24=0A= 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24=0A= 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24=0A= 10.2. Informative References . . . . . . . . . . . . . . . . . . 25=0A= Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 26=0A= A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 26=0A= Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 28=0A= B.1. Define an Abstract Service Interface . . . . . . . . . . . 28=0A= B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 28=0A= B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 29=0A= B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 29=0A= Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 29=0A= Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 30=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 2]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=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. 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= =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 September 5, 2007 [Page 3]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=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 ASIs that transport mappings=0A= (models) can use to pass transport-specific security parameters to=0A= other subsystems, including transport-specific security parameters=0A= translated into the transport-independent securityName and=0A= securityLevel.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 4]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= 1.3. 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= The key words "must", "must not", "required", "shall", "shall not",=0A= "should", "should not", "recommended", "may", and "optional" in this=0A= document are not to be interpreted as described in RFC2119. They=0A= will usually, but not always, be used in a context relating to=0A= compatibility with the RFC3411 architecture or the subsystem defined=0A= here, but which might have no impact on on-the-wire compatibility.=0A= These terms are used as guidance for designers of proposed IETF=0A= models to make the designs compatible with RFC3411 subsystems and=0A= Abstract Service Interfaces (see section 3.2). Implementers are free=0A= to implement differently. Some usages of these lowercase terms are=0A= simply normal English usage.=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 they could hire=0A= employees, train them, position the guards, schedule the guards, send=0A= a replacement when a guard cannot make it, etc., thus providing the=0A= desired security, with no significant effort on his part other than=0A= identifying requirements and verifying the quality of the service=0A= 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= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 5]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= external mechanisms to handle the distribution of keys for use by=0A= USM. The more important issue is that operators wanted to leverage a=0A= single user base that wasn't specific to SNMP.=0A= =0A= A solution based on the second approach might use a USM-compliant=0A= architecture, but combine the authentication mechanism with an=0A= external mechanism, such as RADIUS [RFC2865], to provide the=0A= authentication service. It might be possible to utilize an external=0A= protocol to encrypt a message, to check timeliness, to check data=0A= integrity, etc. It is difficult to cobble together a number of=0A= subcontracted services and coordinate them however, because it is=0A= difficult to build solid security bindings between the various=0A= services, and potential for gaps in the security is significant.=0A= =0A= A solution based on the third approach might utilize one or more=0A= lower-layer security mechanisms to provide the message-oriented=0A= security services required. These would include authentication of=0A= the sender, encryption, timeliness checking, and data integrity=0A= checking. There are a number of IETF standards available or in=0A= development to address these problems through security layers at the=0A= transport layer or application layer, among them TLS [RFC4366], SASL=0A= [RFC4422], and SSH [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 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) [RFC4366] 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= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 6]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =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= 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 [RFC3411]:=0A= =0A= 1. modification of information=0A= 2. masquerade=0A= 3. message stream modification=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 require no modifications to the underlying=0A= protocol. Modifying the protocol might change its security=0A= characteristics in ways that would 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= Transport Models MUST be able to coexist with each other.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 7]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= 3.2. SNMP Requirements=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 Security Subsystem for enabling=0A= different methods of providing security services, a Message=0A= Processing Subsystem permitting different message versions to be=0A= handled by a single engine, 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 addresses the need for a Transport=0A= Subsystem compatible with the RFC3411 architecture. As work is being=0A= done to expand the transport to include secure transport such as SSH=0A= and TLS, using a subsystem will enable consistent design and=0A= 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 will permit Transport=0A= Models to be advanced through the standards process independently of=0A= other Transport Models, and independent of other modular SNMP=0A= components as much as possible.=0A= =0A= Parameters have been added to the ASIs to pass model-independent=0A= transport address information.=0A= =0A= IETF standards typically require one mandatory to implement solution,=0A= with the capability of adding new mechanisms in the future. Part of=0A= the motivation of developing Transport Models is to develop support=0A= for secure transport protocols, such as a Transport Model that=0A= utilizes the Secure Shell protocol. Any Transport Model SHOULD=0A= define one minimum-compliance security mechanism, such as=0A= certificates, to ensure a basic level of interoperability, but should=0A= also be able to support additional existing and new mechanisms.=0A= =0A= The Transport Subsystem permits multiple transport protocols to be=0A= "plugged into" the RFC3411 architecture, supported by corresponding=0A= Transport Models, including models that are security-aware.=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= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 8]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =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. A=0A= Transport Model might perform the translation of transport security=0A= parameters to/from 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 between the Transport Subsystem and the Transport Dispatch,=0A= between the Message Dispatch and the Message Processing Subsystem,=0A= and between the Message Processing Subsystem and the Security=0A= Subsystem will be extended to pass security-model-independent values.=0A= New Security Models may also be defined that understand how to work=0A= with the modified ASIs and the cache. One such Security Model, the=0A= Transport Security Model, is defined in=0A= [I-D.ietf-isms-transport-security-model]=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= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 9]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=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 September 5, 2007 [Page 10]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= 3.2.1.1. Processing Differences between USM and Secure Transport=0A= =0A= USM and secure transports differ is 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= (Note that these lists are simplified for illustrative purposes, and=0A= do not represent all details of processing. Transport Models must=0A= provide the detailed elements of procedure.)=0A= =0A= With USM and other Security Models, security processing starts when=0A= the Message Processing Model decodes portions of the ASN.1 message to=0A= extract an opaque block of security parameters and header parameters=0A= that identify which Security Model should process the message to=0A= perform authentication, decryption, timeliness checking, integrity=0A= checking, and translation of parameters to model-independent=0A= parameters. 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= 3.2.1.1.1. USM and the RFC3411 Architecture=0A= =0A= 1) decode the ASN.1 header (Message Processing Model)=0A= 2) determine the SNMP Security Model and parameters (Message=0A= Processing Model)=0A= 3) verify securityLevel. [Security Model]=0A= 4) translate parameters to model-independent parameters (Security=0A= Model)=0A= 5) authenticate and decrypt message. [Security Model]=0A= 6) determine the pduType in the decrypted portions (Message=0A= Processing Model), and=0A= 7) pass on the decrypted portions with model-independent parameters.=0A= =0A= 3.2.1.2. Transport Subsystem and the RFC3411 Architecture=0A= =0A= 1) authenticate and decrypt message. [Transport Model]=0A= 2) translate parameters to model-independent parameters (Transport=0A= Model)=0A= 3) decode the ASN.1 header (Message Processing Model)=0A= 4) determine the SNMP Security Model and parameters (Message=0A= Processing Model)=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 11]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= 5) verify securityLevel [Security Model]=0A= 6) determine the pduType in the decrypted portions (Message=0A= Processing Model), and=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 the securityName in step 3.=0A= =0A= 3.2.1.3. Passing Information between Engines=0A= =0A= A secure Transport Model will establish an authenticated and/or=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 SNMP=0A= engine. Transport Models MAY support sending multiple SNMP messages=0A= through the same tunnel.=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 a securityName and=0A= securityLevel mapping, the separation of Authentication and=0A= Authorization, and the passing of model-independent security=0A= parameters.=0A= =0A= 3.2.2.1. securityName and securityLevel Mapping=0A= =0A= For SNMP access control to function properly, Security Models MUST=0A= establish a securityLevel and a securityName, which is the security-=0A= model-independent identifier for a principal. The Message Processing=0A= Subsystem relies on a Security Model, such as USM, to play a role in=0A= security that goes beyond protecting the message - it provides a=0A= mapping between the security-model-specific principal to a security-=0A= model independent securityName which can be used for subsequent=0A= processing, such as for access control.=0A= =0A= The securityName MUST be mapped from the mechanism-specific=0A= authenticated identity, and this mapping must be done for incoming=0A= messages before the Security Model passes securityName to the Message=0A= Processing Model via the processIncoming ASI. This translation from=0A= a mechanism-specific authenticated identity to a securityName might=0A= be done by the Transport Model, and the securityName is then provided=0A= to the Security Model via the tmStateReference to be passed to the=0A= Message Processing Model.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 12]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= 3.2.3. Security Parameter Passing Requirements=0A= =0A= RFC3411 section 4 describes abstract data flows between the=0A= subsystems, models and applications within the architecture.=0A= Abstract Service Interfaces describe the flow of data, passing model-=0A= independent information between subsystems within an engine. The=0A= RFC3411 architecture has no ASI parameters for passing security=0A= information between the Transport Subsystem and the dispatcher, or=0A= between the dispatcher and the Message Processing Model. This=0A= document defines or modifies ASIs for this purpose.=0A= =0A= The security parameters include a model-independent identifier of the=0A= security "principal" (the securityName), the Security Model used to=0A= perform the authentication, and which authentication and privacy=0A= services were (should be) applied to the message (securityLevel).=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 authenticate and decrypt an incoming message,=0A= perform integrity checking, and translate security-model-specific=0A= parameters into model-independent parameters. When using a secure=0A= Transport Model, security parameters might be provided through means=0A= other than carrying them in the SNMP message; the parameters for=0A= incoming messages 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 of the=0A= Transport Subsystem and 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= For outgoing messages, even when a secure Transport Model will=0A= provide the security services, a Message Processing Model might have=0A= a Security Model actually create the message from its component=0A= parts. Whether there are any security services provided by the=0A= Security Model for an outgoing message is security-model-dependent.=0A= For incoming messages, even when a secure Transport Model provides=0A= security services, a Security Model might provide some security=0A= functionality that can only be provided after the message version or=0A= other parameters are extracted from the message.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 13]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= 3.2.4. Separation of Authentication and Authorization=0A= =0A= The RFC3411 architecture defines a separation of authentication and=0A= authorization (access control), and a Transport Model that provides=0A= security services should take care to not violate this separation. A=0A= Transport Model does not know which securityModel will be used for an=0A= incoming message, so must not specify how the securityModel and=0A= securityName could be dynamically mapped to an access control=0A= mechanism, such as a VACM-style groupName.=0A= =0A= The RECOMMENDED approach is to pass the model-independent security=0A= parameters via the isAccessAllowed ASI, and perform the mapping from=0A= the model-independent security parameters to an access-control-model-=0A= dependent policy within the Access Control Model. The=0A= isAccessAllowed ASI is used for passing the securityModel,=0A= securityName, and securityLevel parameters that are independent of=0A= any specific security model and any specific access control model to=0A= the Access Control Subsystem.=0A= =0A= The mapping of (securityModel, securityName, securityLevel) to an=0A= access-control-model-specific policy should be handled within a=0A= specific access control model. This mapping should not be done in=0A= the Transport or Security Subsystems, to be consistent with the=0A= modularity of the RFC3411 architecture. This separation was a=0A= deliberate decision of the SNMPv3 WG, to allow support for=0A= authentication protocols which did not provide authorization (access=0A= control) capabilities, and to support authorization schemes, such as=0A= VACM, that do not perform their own authentication.=0A= =0A= The View-based Access Control Model uses the securityModel and the=0A= securityName as inputs to check for access rights. It determines the=0A= groupName as a function of securityModel and securityName. Providing=0A= a binding outside the Access Control Subsystem might create=0A= dependencies that could make it harder to develop alternate models of=0A= access control, such as one built on UNIX groups or Windows domains.=0A= =0A= 3.3. Session Requirements=0A= =0A= Some secure transports might have a notion of sessions, while other=0A= secure transports might provide channels or other session-like=0A= mechanism. Throughout this document, the term session is used in a=0A= broad sense to cover sessions, channels, and session-like mechanisms.=0A= Session refers to an association between two SNMP engines that=0A= permits the transmission of one or more SNMP messages within the=0A= lifetime of the session. How the session is actually established,=0A= opened, closed, or maintained is specific to a particular Transport=0A= Model.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 14]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= Sessions are not part of the SNMP architecture defined in [RFC3411],=0A= but are considered desirable because the cost of authentication can=0A= be amortized over potentially many transactions.=0A= =0A= The architecture defined in [RFC3411] does not include a session=0A= selector in the Abstract Service Interfaces, and neither is that done=0A= for the Transport Subsystem, so an SNMP application has no mechanism=0A= to select a session using the ASIs except by passing a unique=0A= combination of transportDomain, transportAddress, securityName, and=0A= securityLevel. Implementers, of course, might provide non-standard=0A= mechanisms to select sessions. The transportDomain and=0A= transportAddress identify the transport connection to a remote=0A= network node; the securityName identifies which security principal to=0A= communicate with at that address (e.g., different NMS applications),=0A= and the securityLevel might permit selection of different sets of=0A= security properties for different purposes (e.g., encrypted SETs vs.=0A= non-encrypted GETs).=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. Session Establishment Requirements=0A= =0A= SNMP applications provide the transportDomain, transportAddress,=0A= securityName, and securityLevel to be used to identify a session in a=0A= transport-independent manner.=0A= =0A= For an outgoing message, securityLevel is the requested security for=0A= the message, passed in the ASIs. If the Transport Model cannot=0A= provide at least the requested level of security, the Transport Model=0A= SHOULD discard the message and notify the dispatcher that sending the=0A= message failed.=0A= =0A= A Transport Model determines whether an approrpiate session exists=0A= (transportDomain, transportAddress, securityName, and securityLevel)=0A= for an outgoing message. If an appropriate session does not yet=0A= exist, the Transport Model attempts to establish a session for=0A= delivery . If a session cannot be established then the message is=0A= discarded and the dispatcher should be notified that sending the=0A= message failed.=0A= =0A= Depending on the secure transport protocol, session establishment=0A= might require provisioning authentication credentials on the agent,=0A= either statically or dynamically, so the client/agent can=0A= successfully authenticate to a receiver.=0A= =0A= The Transport Subsystem has no knowledge of pdutype, so cannot=0A= distinguish between a session created to carry different pduTypes.=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 15]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= To differentiate a session established for different purposes, such=0A= as a notification session versus a request-response session, an=0A= application can use different securityNames or transport addresses=0A= (e.g., port 161 vs. port 162).=0A= =0A= 3.3.2. 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.=0A= While it is possible for an implementation to automatically tear down=0A= each session once an operation has completed, this is not recommended=0A= for anticipated performance reasons. How an implementation=0A= determines that an operation has completed, including all potential=0A= error paths, is implementation-dependent.=0A= =0A= The elements of procedure describe when cached information can be=0A= discarded, in some circumstances, and the timing of cache cleanup=0A= might have security implications, but cache memory management is an=0A= 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.3. 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 established at the beginning of the session SHOULD=0A= be used to provide authentication, integrity checking, and encryption=0A= services for data that is communicated during the session. The=0A= cryptographic protocols used to establish keys for a Transport Model=0A= session SHOULD ensure that fresh new session keys are generated for=0A= each session. In addition sequence information might be maintained=0A= in the session which can be used to prevent the replay and reordering=0A= of messages within a session. If each session uses new keys, then a=0A= cross-session replay attack will be unsuccessful; that is, an=0A= attacker cannot successfully replay on one session a message he=0A= observed from another session. A good security protocol will also=0A= protect against replay attacks _within_ a session; that is, an=0A= attacker cannot successfully replay a message observed earlier in the=0A= same session.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 16]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= A Transport Model session will have a single transportDomain,=0A= transportAddress, securityName and securityLevel associated with it.=0A= If an exchange between communicating engines requires a different=0A= securityLevel or is on behalf of a different securityName, then=0A= another session would be needed. An immediate consequence of this is=0A= that implementations SHOULD be able to maintain some reasonable=0A= number of concurrent sessions.=0A= =0A= For Transport Models, securityName should be specified during session=0A= setup, and associated with the session identifier.=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 requested security level, i.e. noAuthNoPriv and=0A= authNoPriv MAY be sent over an authenticated and encrypted session.=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 "Send SNMP=0A= Request Message to Network" or "Receive SNMP Response Message from=0A= Network", and does not define ASIs for "Receive SNMP Message from=0A= Network" or "Send SNMP message to Network".=0A= =0A= This document defines a sendMessage ASI to send SNMP messages to the=0A= network, regardless of pduType, and a receiveMessage ASI to receive=0A= SNMP messages from the network, regardless of pdutype.=0A= =0A= 5. Cached Information and References=0A= =0A= The RFC3411 architecture uses caches to store dynamic model-specific=0A= information, and uses references in the ASIs to indicate in a model-=0A= independent manner which cached information flows between subsystems.=0A= =0A= There are two levels of state that might need to be maintained: the=0A= security state in a request-response pair, and potentially long-term=0A= state relating to transport and security.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 17]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= This state is maintained in caches. To simplify the elements of=0A= procedure, the release of state information is not always explicitly=0A= specified. As a general rule, if state information is available when=0A= a message being processed gets discarded, the state related to that=0A= message should also be discarded, and if state information is=0A= available when a relationship between engines is severed, such as the=0A= closing of a transport session, the state information for that=0A= relationship might also be discarded.=0A= =0A= This document differentiates the tmStateReference from the=0A= securityStateReference. This document does not specify an=0A= implementation strategy, only an abstract description of the data=0A= that flows between subsystems. An implementation might use one cache=0A= and one reference to serve both functions, but an implementer must be=0A= aware of the cache-release issues to prevent the cache from being=0A= released before a security or Transport Model has had an opportunity=0A= to extract the information it needs.=0A= =0A= 5.1. securityStateReference=0A= =0A= The securityStateReference parameter is defined in RFC3411.=0A= securityStateReference is not accessible to models of the Transport=0A= Subsystem.=0A= =0A= 5.2. tmStateReference=0A= =0A= For each transport session, information about the message security is=0A= stored in a cache to pass model- and mechanism-specific parameters.=0A= The state referenced by tmStateReference may be saved across multiple=0A= messages, in a Local Configuration Datastore (LCD), as compared to=0A= securityStateReference which is usually only saved for the life of a=0A= request-response pair of messages.=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 MUST be discarded, even if=0A= a new session has been established. The tmStateReference captured=0A= during processing of an incoming message SHOULD include a transport-=0A= specific session identifier. Each Security Model SHOULD pass a=0A= tmSameSession parameter in the tmStateReference cache for outgoing=0A= messages to indicate whether the same session must be used for the=0A= outgoing message as was used for the corresponding incoming message.=0A= If the session identified in the tmStateReference does not match the=0A= current established session, the message MUST be discarded, and the=0A= dispatcher should be notified the sending of the message failed.=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 and the=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 18]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= LCD are implementation-specific.=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 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. Note that keeping sensitive security=0A= information longer than necessary might introduce potential=0A= vulnerabilities to an implementation.=0A= =0A= 2) An error indication in statusInformation may include an OID and=0A= value for an incremented counter and a value for securityLevel, and=0A= values for contextEngineID and contextName for the counter, and the=0A= securityStateReference if the information is available at the point=0A= where the 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.=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 the information in the cache is used is=0A= transport-model-dependent and implementation-dependent. How a=0A= tmStateReference is determined to be present and valid is=0A= implementation-dependent.=0A= =0A= This may sound underspecified, but keep in mind that a transport=0A= model might be something like SNMP over UDP over IPv6, where no=0A= security is provided, so it might have no mechanisms for utilizing a=0A= securityName and securityLevel.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 19]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=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 -- reference to transport state=0A= )=0A= =0A= 6.2. Other Outgoing ASIs=0A= =0A= A tmStateReference parameter has been added to the=0A= prepareOutgoingMessage, generateRequestMsg, and generateResponseMsg=0A= ASIs as an OUT parameter.=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= The tmStateReference parameter of generateRequestMsg or=0A= generateResponseMsg is passed in the return parameters of the=0A= Security Subsystem to the Message Processing Subsystem. If a cache=0A= exists for a session identifiable from transportDomain,=0A= transportAddress, securityModel, securityName, and securityLevel,=0A= then an appropriate Security Model might create a tmStateReference to=0A= the cache and pass that as an OUT parameter.=0A= =0A= If one does not exist, the Security Model might create a cache=0A= referenced by tmStateReference. This information might include=0A= transportDomain, transportAddress, the securityLevel, and the=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 20]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= securityName, plus any model or mechanism-specific details. The=0A= contents of the cache may be incomplete until the Transport Model has=0A= established a session. What information is passed, and how this=0A= information is determined, is implementation and security-model-=0A= specific.=0A= =0A= The prepareOutgoingMessage ASI passes tmStateReference from the=0A= Message Processing Subsystem to the dispatcher. How or if the=0A= Message Processing Subsystem modifies or utilizes the contents of the=0A= cache is message-processing-model-specific.=0A= =0A= This may sound underspecified, but keep in mind that a message=0A= processing model might have access to all the information from the=0A= cache and from the message, and have no need to call a Security Model=0A= to do any processing; an application might choose a Security Model=0A= such as USM to authenticate and secure the SNMP message, but also=0A= utilize a secure transport such as that provided by the SSH Transport=0A= Model to send the message to its destination.=0A= =0A= 6.3. The receiveMessage ASI=0A= =0A= If one does not exist, the Transport Model might create a cache=0A= referenced by tmStateReference. If present, this information might=0A= include transportDomain, transportAddress, securityLevel, and=0A= securityName, plus model or mechanism-specific details. How this=0A= information is determined is implementation and transport-model-=0A= specific.=0A= =0A= This may sound underspecified, but keep in mind that a transport=0A= model might be something like SNMP over UDP over IPv6, where no=0A= security is provided, so it might have no mechanisms for determining=0A= a securityName and securityLevel.=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= The receiveMessage ASI is used to pass a message from the Transport=0A= Subsystem to the Dispatcher.=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= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 21]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= 6.4. Other Incoming ASIs=0A= =0A= To support the Transport Subsystem, the tmStateReference is added to=0A= the prepareDataElements ASI (from the Dispatcher to the Message=0A= Processing Subsystem), and to the processIncomingMsg ASI (from the=0A= Message Processing Subsystem to the Security Model Subsystem). How=0A= or if a Message Processing Model or Security Model uses=0A= tmStateReference is message-processing-model-dependent and security-=0A= model-dependent.=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= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 22]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=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= 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= 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= This may sound underspecified, but keep in mind that a message=0A= processing model might have access to all the information from the=0A= cache and from the message, and have no need to call a Security Model=0A= to do any processing. The Message Processing Model might determine=0A= that the USM Security Model is specified in an SNMPv3 message header;=0A= the USM Security Model has no need of values in the tmStateReference=0A= cache to authenticate and secure the SNMP message, but an application=0A= might have chosen to use a secure transport such as that provided by=0A= the SSH Transport Model to send the message to its destination.=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 the Transport=0A= Model.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 23]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =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= the Transport Model.=0A= =0A= Since the cache and LCD 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= wrong transport.=0A= =0A= 8. IANA Considerations=0A= =0A= This document requires no action by IANA.=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 committed to and performed detailed reviews: Jeffrey=0A= Hutzelman=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= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 24]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =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= [RFC3413] Levi, D., Meyer, P., and B.=0A= Stewart, "Simple Network=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 25]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= Management Protocol (SNMP)=0A= Applications", STD 62,=0A= RFC 3413, December 2002.=0A= =0A= [RFC4366] Blake-Wilson, S., Nystrom,=0A= M., Hopwood, D., Mikkelsen,=0A= J., and T. Wright,=0A= "Transport Layer Security=0A= (TLS) Extensions",=0A= RFC 4366, April 2006.=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= [I-D.ietf-isms-transport-security-model] Harrington, D., "Transport=0A= Security Model for SNMP", d=0A= raft-ietf-isms-transport-=0A= security-model-03 (work in=0A= progress), February 2007.=0A= =0A= Appendix A. Parameter Table=0A= =0A= Following is a Comma-separated-values (CSV) formatted matrix useful=0A= for tracking data flows into and out of the dispatcher, Transport,=0A= Message Processing, and Security Subsystems. This will be of most=0A= use to designers of models, to understand what information is=0A= available at which points in the processing, following the RFC3411=0A= architecture (and this subsystem). Import this into your favorite=0A= spreadsheet or other CSV compatible application. You will need to=0A= remove lines feeds from the second, third, and fourth lines, which=0A= needed to be wrapped to fit into RFC line lengths.=0A= =0A= A.1. ParameterList.csv=0A= =0A= ,Dispatcher,,,,Messaging,,,Security,,,Transport,=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 26]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= ,sendPDU,returnResponse,processPDU,processResponse,=0A= =0A= prepareOutgoingMessage,prepareResponseMessage,prepareDataElements,=0A= =0A= generateRequest,processIncoming,generateResponse,=0A= =0A= sendMessage,receiveMessage=0A= =0A= transportDomain,In,,,,In,,In,,,,,In=0A= =0A= transportAddress,In,,,,In,,In,,,,,In=0A= =0A= destTransportDomain,,,,,Out,Out,,,,,In,=0A= =0A= destTransportAddress,,,,,Out,Out,,,,,In,=0A= =0A= messageProcessingModel,In,In,In,In,In,In,Out,In,In,In,,=0A= =0A= securityModel,In,In,In,In,In,In,Out,In,In,In,,=0A= =0A= securityName,In,In,In,In,In,In,Out,In,Out,In,,=0A= =0A= securityLevel,In,In,In,In,In,In,Out,In,In,In,,=0A= =0A= contextEngineID,In,In,In,In,In,In,Out,,,,,=0A= =0A= contextName,In,In,In,In,In,In,Out,,,,,=0A= =0A= expectResponse,In,,,,In,,,,,,,=0A= =0A= PDU,In,In,In,In,In,In,Out,,,,,=0A= =0A= pduVersion,In,In,In,In,In,In,Out,,,,,=0A= =0A= statusInfo,Out,In,,In,,In,Out,Out,Out,Out,,=0A= =0A= errorIndication,Out,Out,,,,,Out,,,,,=0A= =0A= sendPduHandle,Out,,,In,In,,Out,,,,,=0A= =0A= maxSizeResponsePDU,,In,In,,,In,Out,,Out,,,=0A= =0A= stateReference,,In,In,,,In,Out,,,,,=0A= =0A= wholeMessage,,,,,Out,Out,In,Out,In,Out,In,In=0A= =0A= messageLength,,,,,Out,Out,In,Out,In,Out,In,In=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 27]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= maxMessageSize,,,,,,,,In,In,In,,=0A= =0A= globalData,,,,,,,,In,,In,,=0A= =0A= securityEngineID,,,,,,,,In,Out,In,,=0A= =0A= scopedPDU,,,,,,,,In,Out,In,,=0A= =0A= securityParameters,,,,,,,,Out,In,Out,,=0A= =0A= securityStateReference,,,,,,,,,Out,In,,=0A= =0A= pduType,,,,,,,Out,,,,,=0A= =0A= tmStateReference,,,,,Out,Out,In,,In,,In,In=0A= =0A= Appendix B. 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= 2. one could add a header to encapsulate the SNMP message,=0A= 3. one could utilize fields already defined in the existing SNMPv3=0A= message, or=0A= 4. one could pass the information in an implementation-specific=0A= cache or via a MIB module.=0A= =0A= B.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= B.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= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 28]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =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= 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= B.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= B.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 C. 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= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 29]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= o MUST responses go back on the same transport session? How is this=0A= accomplished since the TM does not know pduType, and subsystems=0A= with knowledge of pdutype do not known about transport sessions.=0A= o Do Informs work correctly?=0A= =0A= Appendix D. 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 -06- to -07-=0A= =0A= o Removed discussion of double authentication=0A= o Removed all direct and indirect references to pduType by Transport=0A= Subsystem=0A= o Added warning regarding keeping sensitive security informaiton=0A= available longer than needed.=0A= o Removed knowledge of securityStateReference from Transport=0A= Subsystem.=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= removed some paragraphs considered unnecessary=0A= added Updates to header=0A= modified some text to get the security details right=0A= modified text re: ASIs so they are not API-like=0A= cleaned up some diagrams=0A= cleaned up RFC2119 language=0A= added section numbers to citations to RFC3411=0A= removed gun for political correctness=0A= =0A= Changes from revision -04- to -05-=0A= =0A= removed all objects from the MIB module.=0A= changed document status to "Standard" rather than the xml2rfc=0A= default of informational.=0A= =0A= changed mention of MD5 to SHA=0A= moved addressing style to TDomain and TAddress=0A= modified the diagrams as requested=0A= removed the "layered stack" diagrams that compared USM and a=0A= Transport Model processing=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 30]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= removed discussion of speculative features that might exist in=0A= future Transport Models=0A= removed openSession and closeSession ASIs, since those are model-=0A= dependent=0A= removed the MIB module=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= removed security considerations related to the MIB module=0A= removed references needed for the MIB module=0A= changed receiveMessage ASI to use origin transport domain/address=0A= updated Parameter CSV appendix=0A= Changes from revision -03- to -04-=0A= =0A= changed title from Transport Mapping Security Model Architectural=0A= Extension to Transport Subsystem=0A= modified the abstract and introduction=0A= changed TMSM to TMS=0A= changed MPSP to simply Security Model=0A= changed SMSP to simply Security Model=0A= changed TMSP to Transport Model=0A= removed MPSP and TMSP and SMSP from Acronyms section=0A= modified diagrams=0A= removed most references to dispatcher functionality=0A= worked to remove dependencies between transport and security=0A= models.=0A= defined snmpTransportModel enumeration similar to=0A= snmpSecurityModel, etc.=0A= eliminated all reference to SNMPv3 msgXXXX fields=0A= changed tmSessionReference back to tmStateReference=0A= =0A= Changes from revision -02- to -03-=0A= =0A= o removed session table from MIB module=0A= o removed sessionID from ASIs=0A= o reorganized to put ASI discussions in EOP section, as was done in=0A= SSHSM=0A= o changed user auth to client auth=0A= o changed tmStateReference to tmSessionReference=0A= o modified document to meet consensus positions published by JS=0A= o=0A= * authoritative is model-specific=0A= * msgSecurityParameters usage is model-specific=0A= * msgFlags vs. securityLevel is model/implementation-specific=0A= * notifications must be able to cause creation of a session=0A= * security considerations must be model-specific=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 31]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= * TDomain and TAddress are model-specific=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= o wrote text for session maintenance requirements section.=0A= o removed section on relation to SNMPv2-MIB=0A= o updated MIB module to pass smilint=0A= o Added Structure of the MIB module, and other expected MIB-related=0A= sections.=0A= o updated author address=0A= o corrected spelling=0A= o removed msgFlags appendix=0A= o Removed section on implementation considerations.=0A= o started modifying the security boilerplate to address TMS and MIB=0A= security issues=0A= o reorganized slightly to better separate requirements from proposed=0A= solution. This probably needs additional work.=0A= o removed section with sample protocols and sample=0A= tmSessionReference.=0A= o Added section for acronyms=0A= o moved section comparing parameter passing techniques to appendix.=0A= o Removed section on notification requirements.=0A= =0A= Changes from revision -00-=0A= o changed SSH references from I-Ds to RFCs=0A= o removed parameters from tmSessionReference for DTLS that revealed=0A= lower layer info.=0A= o Added TMS-MIB module=0A= o Added Internet-Standard Management Framework boilerplate=0A= o Added Structure of the MIB Module=0A= o Added MIB security considerations boilerplate (to be completed)=0A= o Added IANA Considerations=0A= o Added ASI Parameter table=0A= o Added discussion of Sessions=0A= o Added Open issues and Change Log=0A= o Rearranged sections=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 32]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=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= Juergen Schoenwaelder=0A= International 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= Harrington & Schoenwaelder Expires September 5, 2007 [Page 33]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem March 2007=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2007).=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= Acknowledgement=0A= =0A= Funding for the RFC Editor function is provided by the IETF=0A= Administrative Support Activity (IASA).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires September 5, 2007 [Page 34]=0A= =0C=0A= =0A= ------=_NextPart_000_00A9_01C75EFE.9A3B2520 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ------=_NextPart_000_00A9_01C75EFE.9A3B2520-- From isms-bounces@lists.ietf.org Wed Mar 07 10:50:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyP8-0002r9-62; Wed, 07 Mar 2007 10:50:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyOz-0002nO-HC; Wed, 07 Mar 2007 10:50:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOyOx-0003kE-89; Wed, 07 Mar 2007 10:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 26E0532AB1; Wed, 7 Mar 2007 15:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOyOx-0006Uz-1d; Wed, 07 Mar 2007 10:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 10:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-tmsm-07.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-07.txt Pages : 34 Date : 2007-3-7 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-tmsm-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-tmsm-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-7095441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-tmsm-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7095441.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Fri Mar 09 18:13:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPoHS-00071S-HX; Fri, 09 Mar 2007 18:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPoHR-00071L-EY for isms@ietf.org; Fri, 09 Mar 2007 18:13:45 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPoHN-0004QA-4e for isms@ietf.org; Fri, 09 Mar 2007 18:13:45 -0500 Received: from [192.168.1.133] (HSI-KBW-091-089-053-224.hsi2.kabelbw.de [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 268A113CF81 for ; Sat, 10 Mar 2007 00:13:39 +0100 (CET) Date: Sat, 10 Mar 2007 00:13:39 +0100 From: Juergen Quittek To: isms@ietf.org Message-ID: X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Isms] working group last call on draft-ietf-isms-transport-security-model-03 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Dear all, This is the working group last call on the "Transport Security Model for SNMP" to be found at . The authors and the chairs think that this document is mature enough for last call. Please do review the document and post your comments on this list until March 25, 2007. Of course it would be great to get your comments already before our next meeting on March 22. Please also post to the list if you have read the document and are fine with it as it is. It is very useful to know how many people have read the document. Thanks, Juergen Q. -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK Registered in England 2832014 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Mar 14 15:20:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZ1P-0001qv-Md; Wed, 14 Mar 2007 15:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZ1O-0001qq-Ko for isms@ietf.org; Wed, 14 Mar 2007 15:20:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRZ1N-0001Jl-66 for isms@ietf.org; Wed, 14 Mar 2007 15:20:26 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Mar 2007 12:20:24 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2EJKONt025141; Wed, 14 Mar 2007 12:20:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2EJKNZd004202; Wed, 14 Mar 2007 19:20:24 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 12:20:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Mar 2007 12:20:18 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C30325ECA6@xmb-sjc-22d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SSHSM RADIUS Integration draft (draft-narayan-isms-sshsm-radius-01.txt) submitted Thread-Index: Acdmbc1EfazkBdlySeOyq4YZUbSbAw== From: "Kaushik Narayan \(kaushik\)" To: X-OriginalArrivalTime: 14 Mar 2007 19:20:21.0444 (UTC) FILETIME=[CF0B4840:01C7666D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4240; t=1173900024; x=1174764024; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20SSHSM=20RADIUS=20Integration=20draft=20(draft-narayan-isms-ss hsm-radius-01.txt)=20submitted=20 |Sender:=20; bh=LioRZdph18n96mpuSHYoqUab/EaCOLJlv1zKoVh5hX8=; b=u9axiuRhFLgKRqyGGiYhmQuW6sBQ8UZhn0n2tKlD9DH/NKkNSq5TYGuWj3D+BJ9eFtdFGOQ2 r8Ij4rWMuFGeAE6neN5oC0cSzQK/BnkIHVFhFTZBGJYKyuecS58AiISk; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: [Isms] SSHSM RADIUS Integration draft (draft-narayan-isms-sshsm-radius-01.txt) submitted X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0041479747==" Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0041479747== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7666D.CE56EF18" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7666D.CE56EF18 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, =20 The RADIUS integration draft for SSHSM has been submitted to the drafts directory. The draft specifies details how RADIUS could be used as an authentication and authorization mechanism for SSHSM.=20 =20 This draft currently describes two approaches for integration of authorization information returned from the RADIUS server. =20 a. Receive authorization information along with authentication request (traditional RADIUS model) & cache authorization information within TMSM. Augment VACM in an implementation-dependent fashion to fetch authorization parameters from TMSM (using tmStateReference). b. Define a new access control model that can issue direct RADIUS authorize-only requests to fetch authorization information on demand. This approach will also require the use of the TMSM cache to store the RADIUS state attribute. The draft does not elaborate on the details of such an access control model. =20 We need further discussion within the WG on the two approaches and whether we need to elaborate on both.=20 =20 regards, David Nelson & Kaushik Narayan ------_=_NextPart_001_01C7666D.CE56EF18 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
The=20 RADIUS integration draft for SSHSM has been submitted to the drafts = directory.=20 The draft specifies details how RADIUS could be used as an = authentication and=20 authorization mechanism for SSHSM.
 
This=20 draft currently describes two approaches for integration of = authorization=20 information returned from the RADIUS server.
 
a.=20 Receive authorization information along with authentication request = (traditional=20 RADIUS model) & cache authorization information within TMSM. Augment = VACM in=20 an implementation-dependent fashion to fetch authorization parameters = from TMSM=20 (using tmStateReference).
b.=20 Define a new access control model that can issue direct RADIUS = authorize-only=20 requests to fetch authorization information on demand. This approach = will also=20 require the use of the TMSM cache to store the RADIUS state attribute. = The draft=20 does not elaborate on the details of such an access=20 control model.
 
We=20 need further discussion within the WG on the two approaches and whether = we need=20 to elaborate on both.
 
regards,
 David Nelson & Kaushik=20 Narayan
------_=_NextPart_001_01C7666D.CE56EF18-- --===============0041479747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0041479747==-- From isms-bounces@lists.ietf.org Wed Mar 14 15:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZde-0000d4-Re; Wed, 14 Mar 2007 15:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZdd-0000cw-J2 for isms@ietf.org; Wed, 14 Mar 2007 15:59:57 -0400 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRZdc-0008Kv-2H for isms@ietf.org; Wed, 14 Mar 2007 15:59:57 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070314195955b1200nni6oe>; Wed, 14 Mar 2007 19:59:55 +0000 From: "David Harrington" To: "'Kaushik Narayan \(kaushik\)'" , References: <618694EF0B657246A4D55A97E38274C30325ECA6@xmb-sjc-22d.amer.cisco.com> Subject: RE: [Isms] SSHSM RADIUS Integration draft(draft-narayan-isms-sshsm-radius-01.txt) submitted Date: Wed, 14 Mar 2007 15:59:51 -0400 Message-ID: <019701c76673$54139470$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <618694EF0B657246A4D55A97E38274C30325ECA6@xmb-sjc-22d.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdmbc1EfazkBdlySeOyq4YZUbSbAwAAnfyA X-Spam-Score: 0.1 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1172734834==" Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1172734834== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0198_01C76651.CD01F470" This is a multi-part message in MIME format. ------=_NextPart_000_0198_01C76651.CD01F470 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, Following ietf66, we changed direction somewhat in ISMS. There is no SSHSM anymore; there is a Transport subsystem, an SSH-TM (transport model), and a TSM (Transport Security Model). Currently, we do not pass the tmStateReference into the IsAccessAllowed ASI. I don't think we even pass it tothe applications, and the applications call IsAccessAllowed, so you may be talking about changing a few ASIs. Another way to approach the problem would be to use a MIB to store the transport&security information in a local configuration database addressable by securityName/securityModel/securityLevel and transportDomain/Address. Another RADIUS-specific MIB could contain RADIUS information, and that MIB could AUGMENT the transport&security MIB. Actually I can envision 3 MIB modules: 1) known to a specific transport model, indexed by securityN/L,transportD/A, independent of securityModel 2) known to the Transport Security Model, contains TSM-specific info indexed by securityN/L and trasnportD/A, indepednent of specific transport models but it can get a pointer to a specific transport row using securityNL,transportDA 3) a RADIUS-specific MIB indexed by securityM/N/L,transportDA. This MIB could store authoriaztion info and the RADIUS state. A RADIUS-spepxcifc ACM could check for a RADIUS state attribute in the transport model MIB. I'm not sure this maintains the modulairty as much as we want, but at least we' can try to lay the MIBs out in a way that they can remain independnent of each other, and define some common MOs to be used by potentially multiple models within a subsystem, and make the MOs accessible in a model-independent manner from other subsystems. dbh _____ From: Kaushik Narayan (kaushik) [mailto:kaushik@cisco.com] Sent: Wednesday, March 14, 2007 3:20 PM To: isms@ietf.org Subject: [Isms] SSHSM RADIUS Integration draft(draft-narayan-isms-sshsm-radius-01.txt) submitted Hi All, The RADIUS integration draft for SSHSM has been submitted to the drafts directory. The draft specifies details how RADIUS could be used as an authentication and authorization mechanism for SSHSM. This draft currently describes two approaches for integration of authorization information returned from the RADIUS server. a. Receive authorization information along with authentication request (traditional RADIUS model) & cache authorization information within TMSM. Augment VACM in an implementation-dependent fashion to fetch authorization parameters from TMSM (using tmStateReference). b. Define a new access control model that can issue direct RADIUS authorize-only requests to fetch authorization information on demand. This approach will also require the use of the TMSM cache to store the RADIUS state attribute. The draft does not elaborate on the details of such an access control model. We need further discussion within the WG on the two approaches and whether we need to elaborate on both. regards, David Nelson & Kaushik Narayan ------=_NextPart_000_0198_01C76651.CD01F470 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
Following ietf66, we changed direction somewhat = in ISMS.=20 There is no SSHSM anymore; there is a Transport subsystem, an SSH-TM = (transport=20 model), and a TSM (Transport Security Model).
 
Currently, we do not pass the tmStateReference = into the=20 IsAccessAllowed ASI. I don't think we even pass it tothe applications, = and the=20 applications call IsAccessAllowed, so you may be talking about changing = a few=20 ASIs.
 
Another way to approach the problem would be to = use a MIB=20 to store the transport&security information in a local configuration = database addressable by securityName/securityModel/securityLevel and=20 transportDomain/Address. Another RADIUS-specific MIB could contain = RADIUS=20 information, and that MIB could AUGMENT the transport&security=20 MIB.
 
Actually I can envision 3 MIB = modules:
1) known to a specific transport model, indexed = by=20 securityN/L,transportD/A, independent of = securityModel
2) known to the Transport Security Model, = contains=20 TSM-specific info indexed by securityN/L and trasnportD/A, indepednent = of=20 specific transport models but it can get a pointer to a specific = transport row=20 using securityNL,transportDA
3) a RADIUS-specific MIB indexed by=20 securityM/N/L,transportDA. This MIB could store authoriaztion info and = the=20 RADIUS state. A RADIUS-spepxcifc ACM could check for a RADIUS state = attribute in=20 the transport model MIB.
 
I'm not sure this maintains the modulairty as = much as we=20 want, but at least we' can try to lay the MIBs out in a way that they = can remain=20 independnent of each other, and define some common MOs to be used by = potentially=20 multiple models within a subsystem, and make the MOs accessible in a=20 model-independent manner from other subsystems.
 
dbh
 

From: Kaushik Narayan (kaushik)=20 [mailto:kaushik@cisco.com]
Sent: Wednesday, March 14, 2007 = 3:20=20 PM
To: isms@ietf.org
Subject: [Isms] SSHSM RADIUS=20 Integration draft(draft-narayan-isms-sshsm-radius-01.txt) submitted=20

Hi=20 All,
 
The=20 RADIUS integration draft for SSHSM has been submitted to the drafts = directory.=20 The draft specifies details how RADIUS could be used as an = authentication and=20 authorization mechanism for SSHSM.
 
This=20 draft currently describes two approaches for integration of = authorization=20 information returned from the RADIUS server.
 
a.=20 Receive authorization information along with authentication request=20 (traditional RADIUS model) & cache authorization information = within TMSM.=20 Augment VACM in an implementation-dependent fashion to fetch = authorization=20 parameters from TMSM (using tmStateReference).
b.=20 Define a new access control model that can issue direct RADIUS = authorize-only=20 requests to fetch authorization information on demand. This approach = will also=20 require the use of the TMSM cache to store the RADIUS state attribute. = The=20 draft does not elaborate on the details of such an access=20 control model.
 
We=20 need further discussion within the WG on the two approaches and = whether we=20 need to elaborate on both.
 
regards,
 David Nelson & Kaushik=20 Narayan
------=_NextPart_000_0198_01C76651.CD01F470-- --===============1172734834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============1172734834==-- From isms-bounces@lists.ietf.org Thu Mar 15 08:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoy4-0003kp-SJ; Thu, 15 Mar 2007 08:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoy3-0003kU-1R for isms@ietf.org; Thu, 15 Mar 2007 08:22:03 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRoy1-0003hZ-1B for isms@ietf.org; Thu, 15 Mar 2007 08:22:03 -0400 Received: from newton603 (c-24-61-11-96.hsd1.nh.comcast.net[24.61.11.96]) by comcast.net (sccrmhc11) with SMTP id <2007031512220001100ak649e>; Thu, 15 Mar 2007 12:22:00 +0000 From: "David B. Nelson" To: References: <618694EF0B657246A4D55A97E38274C30325ECA6@xmb-sjc-22d.amer.cisco.com> <019701c76673$54139470$0600a8c0@china.huawei.com> Subject: RE: [Isms] SSHSM RADIUS Integrationdraft(draft-narayan-isms-sshsm-radius-01.txt) submitted Date: Thu, 15 Mar 2007 08:19:59 -0400 Message-ID: <001101c766fc$409fe180$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <019701c76673$54139470$0600a8c0@china.huawei.com> Thread-Index: Acdmbc1EfazkBdlySeOyq4YZUbSbAwAAnfyAACLLchA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > Currently, we do not pass the tmStateReference into the > IsAccessAllowed ASI. I don't think we even pass it to the > applications, and the applications call IsAccessAllowed, > so you may be talking about changing a few ASIs. The modularity of the current SNMP architecture seems to be predicated upon the notion that passing around securityName is all that is ever needed. That seems to be predicated on the notion that there is a local configuration store that contains useful information addressed by securityName. That seems to imply USM or something very much like it. If we really want to break the ties to USM, we're going to need to address this issue. > Another way to approach the problem would be to use a MIB > to store the transport&security information in a local > configuration database addressable by > securityName/securityModel/securityLevel and > transportDomain/Address. Another RADIUS-specific MIB could > contain RADIUS information, and that MIB could AUGMENT the > transport&security MIB. So, maybe that is one way to address the issue. I'll need a bit to time to absorb all this... _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Mar 15 09:28:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpzu-0003P5-Uw; Thu, 15 Mar 2007 09:28:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpzt-0003P0-C0 for isms@ietf.org; Thu, 15 Mar 2007 09:28:01 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRpzq-0007Vt-NN for isms@ietf.org; Thu, 15 Mar 2007 09:28:01 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEY005UF5D65B@szxga01-in.huawei.com> for isms@ietf.org; Thu, 15 Mar 2007 21:27:06 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEY006005D403@szxga01-in.huawei.com> for isms@ietf.org; Thu, 15 Mar 2007 21:27:06 +0800 (CST) Received: from l48181 ([10.111.12.171]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JEY0009Y5D00A@szxml03-in.huawei.com> for isms@ietf.org; Thu, 15 Mar 2007 21:27:04 +0800 (CST) Date: Thu, 15 Mar 2007 21:27:00 +0800 From: Li Yan To: isms@ietf.org Message-id: <000701c76705$9d3370c0$ab0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcdnBZzKVlTc4najQ9C+/sezHCua/A== X-Spam-Score: 3.0 (+++) X-Scan-Signature: 91ad537ab983fae778fbdbac06222b32 Cc: Subject: [Isms] A few minor comments on transport-security-model-03 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0888001620==" Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0888001620== Content-type: multipart/alternative; boundary="Boundary_(ID_1gaaoL5+vD6WHUcDNHgCNg)" This is a multi-part message in MIME format. --Boundary_(ID_1gaaoL5+vD6WHUcDNHgCNg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I think the draft is pretty good, I have only found a few minor mistakes. o pg 2 ToC: Sec. 8.1 title : Capitalize "module" and "security". o pg 3 sec. 1.1 "RFC 3410" Does the space between RFC and 3410 be needed? The "RFC XXXX" and "RFCXXXX" coexist in the draft, which is correct? o pg 14 sec. 6 "It defines some needed textual conventions" In fact, there is no textual convention definition in this MIB module. o pg 14 sec. 6.3 There is a period missing before "In particular". o pg 16 sec. 7 I'm not sure if the tsmNotifications object is needed, because this MIB doesn't define any notifications. Yan --Boundary_(ID_1gaaoL5+vD6WHUcDNHgCNg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I think the draft is pretty good, I have only found a few minor mistakes.

o pg 2 ToC: Sec. 8.1 title : Capitalize “module” and “security”.

o pg 3 sec. 1.1  “RFC 3410”

  Does the space between RFC and 3410 be needed? The "RFC XXXX" and "RFCXXXX" coexist in the draft, which is correct?

o pg 14 sec. 6  "It defines some needed textual conventions"

  In fact, there is no textual convention definition in this MIB module.

o pg 14 sec. 6.3  There is a period missing before "In particular".

o pg 16 sec. 7  I'm not sure if the tsmNotifications object is needed, because this MIB doesn't define any notifications.

 

Yan

--Boundary_(ID_1gaaoL5+vD6WHUcDNHgCNg)-- --===============0888001620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0888001620==-- From isms-bounces@lists.ietf.org Thu Mar 15 10:08:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqcS-00047P-TY; Thu, 15 Mar 2007 10:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqcR-00047K-OG for isms@ietf.org; Thu, 15 Mar 2007 10:07:51 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqcQ-0005NF-E4 for isms@ietf.org; Thu, 15 Mar 2007 10:07:51 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20070315140749b14006uahje>; Thu, 15 Mar 2007 14:07:50 +0000 From: "David Harrington" To: "'David B. Nelson'" , References: <618694EF0B657246A4D55A97E38274C30325ECA6@xmb-sjc-22d.amer.cisco.com><019701c76673$54139470$0600a8c0@china.huawei.com> <001101c766fc$409fe180$6401a8c0@NEWTON603> Subject: RE: [Isms] SSHSM RADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt) submitted Date: Thu, 15 Mar 2007 10:07:35 -0400 Message-ID: <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001101c766fc$409fe180$6401a8c0@NEWTON603> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdmbc1EfazkBdlySeOyq4YZUbSbAwAAnfyAACLLchAAAtQuYA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > The modularity of the current SNMP architecture seems to be > predicated upon > the notion that passing around securityName is all that is > ever needed. Roughly, that's true. The other model-dependent details should be hidden within the specific models. > That seems to be predicated on the notion that there is a local > configuration store that contains useful information addressed by > securityName. That's not quite true. In fact, the goal of the modularity is to NOT share model-specific information in the background through a LCD; that type of sharing is one of the problems that was so hard to fix in SNMPv2. We had problems because different operators/implementers want different capabilities for different reasons, and different SNMPv2 designs kept overwriting each other in the "global memory" that is the LCD. The modular approach allowed us to specify model-specific LCDs (MIB modules), modifiable only by the defining model, to prevent volatile changes to the data. > That seems to imply USM or something very much > like it. If > we really want to break the ties to USM, we're going to need > to address this > issue. So far, I have not seen any proposals, either written or just proposed verbally, that provides a secure transport with all the security characteristics of USM. A critical feature of USM, not provided by SSH or TLS or RADIUS proposals so far, is local authentication with NO ties to a third party authenticator. SNMP is deliberately built to work even when network connectivity is impaired. There are a number of design decisions based on this requirements, including having UDP as a mandatory-to-implement transport, messages sizes that do not require fragmentation, and local authentication. SNMP is designed to use a local authentication model (two-party - the manager and agent) rather than a three-party authentication model, because it might be impossible to reach the third party due to network impairment. Any solution that requires a third party authentication server, or a CA, or any other third-party security functionality does not meet all the requirements of SNMP. The USM model combined with the UDP/IPv4 transport model meets the SNMP "reachability" requirements and the SNMP message security requirements. We can **supplement** USM with secure transport models, and centralized authentication and authorization, that are easier to use but do not meet the "reachability" requirement, as long as USM and UDP transport are still mandatory to implement. I don't think we can break the ties to USM until we either 1) design a new security model that provides this non-reliance on third-parties at runtime, or 2) decide that the ability for SNMP to work when network connectivity is impaired is no longer a requirement of SNMP design. Dbh > > > Another way to approach the problem would be to use a MIB > > to store the transport&security information in a local > > configuration database addressable by > > securityName/securityModel/securityLevel and > > transportDomain/Address. Another RADIUS-specific MIB could > > contain RADIUS information, and that MIB could AUGMENT the > > transport&security MIB. > > So, maybe that is one way to address the issue. I'll need a > bit to time to > absorb all this... > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Mar 15 11:15:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrg5-0004Rw-60; Thu, 15 Mar 2007 11:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrg4-0004Ro-Gh for isms@ietf.org; Thu, 15 Mar 2007 11:15:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRrg3-0007Gg-6b for isms@ietf.org; Thu, 15 Mar 2007 11:15:40 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Mar 2007 16:15:39 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2FFFciP016330; Thu, 15 Mar 2007 16:15:38 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4443.cisco.com [10.61.81.90]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2FFFXlZ017330; Thu, 15 Mar 2007 15:15:34 GMT Message-ID: <45F96315.7090709@cisco.com> Date: Thu, 15 Mar 2007 16:15:33 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: David Harrington Subject: Re: [Isms] SSHSM RADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt) submitted References: <618694EF0B657246A4D55A97E38274C30325ECA6@xmb-sjc-22d.amer.cisco.com><019701c76673$54139470$0600a8c0@china.huawei.com> <001101c766fc$409fe180$6401a8c0@NEWTON603> <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> In-Reply-To: <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1946; t=1173971738; x=1174835738; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Isms]=20SSHSM=09RADIUSIntegrationdraft(draft-narayan -isms-sshsm-radius-01.txt)=0A=20submitted |Sender:=20; bh=p66il/IK2ZtjIQyCcRbQ2wOdxKF8Vrq6rz8SPGGoCzk=; b=ZY6Z5AAXVqTRhGfMlomd8TAghPE+CfXWxkQCaWtt9aIud//7TacaVEAH9CKyYbseqhucog4h VSb09PEKQ1gyWkaOuygEF2BN29N6vUZimruEYIxOIdFaCuHFyQ6D/bUs; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington wrote: > > > >> The modularity of the current SNMP architecture seems to be >> predicated upon >> the notion that passing around securityName is all that is >> ever needed. >> > > Roughly, that's true. > The other model-dependent details should be hidden within the specific > models. > > >> That seems to be predicated on the notion that there is a local >> configuration store that contains useful information addressed by >> securityName. >> > > That's not quite true. > > In fact, the goal of the modularity is to NOT share model-specific > information in the background through a LCD; that type of sharing is > one of the problems that was so hard to fix in SNMPv2. We had problems > because different operators/implementers want different capabilities > for different reasons, and different SNMPv2 designs kept overwriting > each other in the "global memory" that is the LCD. The modular > approach allowed us to specify model-specific LCDs (MIB modules), > modifiable only by the defining model, to prevent volatile changes to > the data. > > >> That seems to imply USM or something very much >> like it. If >> we really want to break the ties to USM, we're going to need >> to address this >> issue. >> > > So far, I have not seen any proposals, either written or just proposed > verbally, that provides a secure transport with all the security > characteristics of USM. A critical feature of USM, not provided by SSH > or TLS or RADIUS proposals so far, is local authentication with NO > ties to a third party authenticator. > Well define 3rd party. BEEP with TLS+SASL does the job quite nicely, but when one uses TLS one must of course take some care regarding trust anchors. If you're doing CRL checks then you are probably going off box, unless YOU signed the cert. But most people don't do CRL checks at all. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Mar 15 13:29:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtlS-0004U1-7g; Thu, 15 Mar 2007 13:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtlQ-0004Sj-Mi for isms@ietf.org; Thu, 15 Mar 2007 13:29:20 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRtlG-0000CX-Ks for isms@ietf.org; Thu, 15 Mar 2007 13:29:20 -0400 Received: from pc6 (1Cust132.tnt1.lnd4.gbr.da.uu.net [62.188.130.132]) by blaster.systems.pipex.net (Postfix) with SMTP id BF455E0001F9; Thu, 15 Mar 2007 17:28:56 +0000 (GMT) Message-ID: <02e901c7671e$b5fbb400$0601a8c0@pc6> From: "tom.petch" To: "Juergen Quittek" , References: Subject: Re: [Isms] working group last call ondraft-ietf-isms-transport-security-model-03 Date: Thu, 15 Mar 2007 17:25:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.1 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org s.2 "The Transport Model of an SNMP engine will perform the translation between transport-specific security parameters **only if it is a secure Transport Model - for UDP over IPv6, there are no security parameters. " and the SNMP-specific, model-independent parameters securityName and securityLevel. **only if the Security Model decides to use them; the Transport Model only puts putatative values in a cache which the SM may or may not use. The obvious case is v2c over ssh when the cache will be ignored "To maintain the RFC3411 modularity, the Transport Model does not know which securityModel will be used for an incoming message; **true! " the Message Processing Model will determine the securityModel to be used, in a Message Processing Model dependent manner. In an SNMPv3 message [RFC3412], the Transport Security Model should be specified in the message header. **should be specified? to the exclusion of all else:-) I suggest "In an SNMPv3 message, the Security Model is specified in the message header. **and you might want to add which object and which value of that object is intended to invoke the Transport Security Model **and what about v1 and v2c MPP? can they invoke Transport Security Model; read hard between the lines and my conclusion is not, but I think it should be specified. Tom Petch ----- Original Message ----- From: "Juergen Quittek" To: Sent: Saturday, March 10, 2007 12:13 AM Subject: [Isms] working group last call ondraft-ietf-isms-transport-security-model-03 > Dear all, > > This is the working group last call on the > "Transport Security Model for SNMP" > to be found at > . > > The authors and the chairs think that this document is mature enough > for last call. > > Please do review the document and post your comments on this list until > March 25, 2007. Of course it would be great to get your comments already > before our next meeting on March 22. > > Please also post to the list if you have read the document and are fine > with it as it is. It is very useful to know how many people have read > the document. > > Thanks, > > Juergen Q. > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 > NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > Registered in England 2832014 > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Mar 15 16:45:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwoX-0000JQ-Lx; Thu, 15 Mar 2007 16:44:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwoW-0000JJ-6v for isms@ietf.org; Thu, 15 Mar 2007 16:44:44 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRwoT-0001tH-U3 for isms@ietf.org; Thu, 15 Mar 2007 16:44:44 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc16) with SMTP id <20070315204441b160078cque>; Thu, 15 Mar 2007 20:44:41 +0000 From: "David Harrington" To: "'Eliot Lear'" References: <618694EF0B657246A4D55A97E38274C30325ECA6@xmb-sjc-22d.amer.cisco.com><019701c76673$54139470$0600a8c0@china.huawei.com> <001101c766fc$409fe180$6401a8c0@NEWTON603> <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> <45F96315.7090709@cisco.com> Subject: RE: [Isms] SSHSM RADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt) submitted Date: Thu, 15 Mar 2007 16:44:33 -0400 Message-ID: <024901c76742$be1db970$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45F96315.7090709@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdnFMoJq1la8kY5Rj+Sh7pdV5191gAAYP5w X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Party #1: an snmp engine (e.g., a manager) Party #2: another snmp engine (e.g., an agent) Party #3: anybody else not co-locaetd with #1 or #2 that needs to be involved. With USM, only #1 and #2 need to be able to reach each other. dbh > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Thursday, March 15, 2007 11:16 AM > To: David Harrington > Cc: 'David B. Nelson'; isms@ietf.org > Subject: Re: [Isms] SSHSM > RADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt) > submitted > > David Harrington wrote: > > > > > > > >> The modularity of the current SNMP architecture seems to be > >> predicated upon > >> the notion that passing around securityName is all that is > >> ever needed. > >> > > > > Roughly, that's true. > > The other model-dependent details should be hidden within > the specific > > models. > > > > > >> That seems to be predicated on the notion that there is a local > >> configuration store that contains useful information addressed by > >> securityName. > >> > > > > That's not quite true. > > > > In fact, the goal of the modularity is to NOT share model-specific > > information in the background through a LCD; that type of sharing is > > one of the problems that was so hard to fix in SNMPv2. We > had problems > > because different operators/implementers want different capabilities > > for different reasons, and different SNMPv2 designs kept overwriting > > each other in the "global memory" that is the LCD. The modular > > approach allowed us to specify model-specific LCDs (MIB modules), > > modifiable only by the defining model, to prevent volatile > changes to > > the data. > > > > > >> That seems to imply USM or something very much > >> like it. If > >> we really want to break the ties to USM, we're going to need > >> to address this > >> issue. > >> > > > > So far, I have not seen any proposals, either written or > just proposed > > verbally, that provides a secure transport with all the security > > characteristics of USM. A critical feature of USM, not > provided by SSH > > or TLS or RADIUS proposals so far, is local authentication with NO > > ties to a third party authenticator. > > > > Well define 3rd party. BEEP with TLS+SASL does the job quite nicely, > but when one uses TLS one must of course take some care > regarding trust > anchors. If you're doing CRL checks then you are probably going off > box, unless YOU signed the cert. But most people don't do > CRL checks at > all. > > Eliot > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Mar 15 19:04:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyzr-0001wg-84; Thu, 15 Mar 2007 19:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyzq-0001wb-Go for isms@ietf.org; Thu, 15 Mar 2007 19:04:34 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRyzp-0004LD-0e for isms@ietf.org; Thu, 15 Mar 2007 19:04:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2007 16:04:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2FN4W5p005320; Thu, 15 Mar 2007 16:04:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2FN4HFA006790; Thu, 15 Mar 2007 23:04:32 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); Thu, 15 Mar 2007 16:04:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Date: Thu, 15 Mar 2007 16:04:23 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3032CC615@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Thread-Index: Acdmbc1EfazkBdlySeOyq4YZUbSbAwAAnfyAACLLchAAAtQuYAARPXPA From: "Kaushik Narayan \(kaushik\)" To: "David Harrington" , "David B. Nelson" , X-OriginalArrivalTime: 15 Mar 2007 23:04:25.0691 (UTC) FILETIME=[46DA52B0:01C76756] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4241; t=1173999872; x=1174863872; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Isms]=20SSHSMRADIUSIntegrationdraft(draft-narayan-is ms-sshsm-radius-01.txt)submitted=20 |Sender:=20; bh=amQ/+DHOPPyrVXdiun6xmj9edaD/Uf0gmq0JpXtkSjc=; b=1hCk/7S2vufC8ajrhryRIzVoCxQOIWjs+wvgalQOa2FjFV7+nZ/at5DePEwoW8Z2C2SECZ4i C6CWNK9R3jeLmDlx5WJxy38EFI0dkPewsQz1uafGqECLzjLCicA6mgE3; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi David, Please find my reply inline.=20 > That seems to be predicated on the notion that there is a local=20 > configuration store that contains useful information addressed by=20 > securityName. That's not quite true.=20 In fact, the goal of the modularity is to NOT share model-specific information in the background through a LCD; that type of sharing is one of the problems that was so hard to fix in SNMPv2. We had problems because different operators/implementers want different capabilities for different reasons, and different SNMPv2 designs kept overwriting each other in the "global memory" that is the LCD. The modular approach allowed us to specify model-specific LCDs (MIB modules), modifiable only by the defining model, to prevent volatile changes to the data.=20 I think one of the issues being out here is that we still require the securityName(s) to be defined on every SNMP engine (similar to USM) and that creates a manageability issue. The reason administrators deploy external authentication mechanisms such as RADIUS is to avoid having to manage securityName(s) on every SNMP engine.=20 > That seems to imply USM or something very much like it. If we really=20 > want to break the ties to USM, we're going to need to address this=20 > issue. So far, I have not seen any proposals, either written or just proposed verbally, that provides a secure transport with all the security characteristics of USM. A critical feature of USM, not provided by SSH or TLS or RADIUS proposals so far, is local authentication with NO ties to a third party authenticator. SNMP is deliberately built to work even when network connectivity is impaired. There are a number of design decisions based on this requirements, including having UDP as a mandatory-to-implement transport, messages sizes that do not require fragmentation, and local authentication. SNMP is designed to use a local authentication model (two-party - the manager and agent) rather than a three-party authentication model, because it might be impossible to reach the third party due to network impairment. Any solution that requires a third party authentication server, or a CA, or any other third-party security functionality does not meet all the requirements of SNMP. The USM model combined with the UDP/IPv4 transport model meets the SNMP "reachability" requirements and the SNMP message security requirements. We can **supplement** USM with secure transport models, and centralized authentication and authorization, that are easier to use but do not meet the "reachability" requirement, as long as USM and UDP transport are still mandatory to implement. I don't think we can break the ties to USM until we either 1) design a new security model that provides this non-reliance on third-parties at runtime, or 2) decide that the ability for SNMP to work when network connectivity is impaired is no longer a requirement of SNMP design. It is very common in authentication systems to chain a set of authentication methods, I can think a similar capability is what is required. This is supported by PAM configuration that is typically used by SSH implementations. Alternatively we can build this into the security model and allow fallback to a local user database in case reachability is not available. regards, kaushik Dbh >=20 > > Another way to approach the problem would be to use a MIB to store=20 > > the transport&security information in a local configuration database > > addressable by securityName/securityModel/securityLevel and=20 > > transportDomain/Address. Another RADIUS-specific MIB could contain=20 > > RADIUS information, and that MIB could AUGMENT the=20 > > transport&security MIB. >=20 > So, maybe that is one way to address the issue. I'll need a bit to=20 > time to absorb all this... >=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Mar 16 01:37:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS57d-0003G3-C2; Fri, 16 Mar 2007 01:37:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS57c-00038c-Cr for isms@ietf.org; Fri, 16 Mar 2007 01:37:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS57b-0001lu-4S for isms@ietf.org; Fri, 16 Mar 2007 01:37:00 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2007 06:36:57 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2G5auPn001935; Fri, 16 Mar 2007 06:36:56 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4443.cisco.com [10.61.81.90]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2G5aplZ015698; Fri, 16 Mar 2007 05:36:52 GMT Message-ID: <45FA2CF3.1040607@cisco.com> Date: Fri, 16 Mar 2007 06:36:51 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: David Harrington Subject: Re: [Isms] SSHSM RADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt) submitted References: <618694EF0B657246A4D55A97E38274C30325ECA6@xmb-sjc-22d.amer.cisco.com><019701c76673$54139470$0600a8c0@china.huawei.com> <001101c766fc$409fe180$6401a8c0@NEWTON603> <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> <45F96315.7090709@cisco.com> <024901c76742$be1db970$0600a8c0@china.huawei.com> In-Reply-To: <024901c76742$be1db970$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=317; t=1174023416; x=1174887416; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Isms]=20SSHSM=09RADIUSIntegrationdraft(draft-narayan -isms-sshsm-radius-01.txt)=0A=20submitted |Sender:=20; bh=b20+/5fhSp1ABcBa5noaj07eiTfDApsutHXW6X83lv8=; b=UGdCFY1SpF2qiORPFRycCm8aPo+UHfwLIlrgQRsWWlFb70G3tEGFnU6Y+2Fcz0ce/gLqvkEf LOlG8ljEG4kA8rZ30tBCZIUtCHOQ2jKuEOSSzUCF16bEM5VKVBvfjvDH; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington wrote: > Party #1: an snmp engine (e.g., a manager) > Party #2: another snmp engine (e.g., an agent) > Party #3: anybody else not co-locaetd with #1 or #2 that needs to be > involved. > Yes, SASL+TLS could easily handle this case under the constraints I previously mentioned. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Mar 16 04:47:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS866-0004R1-QY; Fri, 16 Mar 2007 04:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS865-0004Qa-C8 for isms@ietf.org; Fri, 16 Mar 2007 04:47:37 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS864-0007w4-2C for isms@ietf.org; Fri, 16 Mar 2007 04:47:37 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 25D1C6D9DC; Fri, 16 Mar 2007 09:47:29 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29011-02; Fri, 16 Mar 2007 09:47:25 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id BCA7F6D9FF; Fri, 16 Mar 2007 09:47:25 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 8CF461E896F; Fri, 16 Mar 2007 09:47:24 +0100 (CET) Date: Fri, 16 Mar 2007 09:47:24 +0100 From: Juergen Schoenwaelder To: "Kaushik Narayan (kaushik)" Subject: Re: [Isms] SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Message-ID: <20070316084724.GE759@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Kaushik Narayan (kaushik)" , David Harrington , "David B. Nelson" , isms@ietf.org References: <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> <618694EF0B657246A4D55A97E38274C3032CC615@xmb-sjc-22d.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <618694EF0B657246A4D55A97E38274C3032CC615@xmb-sjc-22d.amer.cisco.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Thu, Mar 15, 2007 at 04:04:23PM -0700, Kaushik Narayan (kaushik) wrote: > [...] A critical feature of USM, not provided by SSH or TLS or > RADIUS proposals so far, is local authentication with NO ties to a > third party authenticator. Isn't a locally stored password or key pair providing just exactly that feature? Anyway, I am in general quite confused by this thread as it seems that people talk about different things without really trying to understand the other's background / terminology / view of the world. Perhaps it helps to go through the RADIUS document and to bring up paragraphs that are considered problematic and to propose alternative text fragments so that we avoid getting trapped in some general and abstract discussions that we had in the past and which might not be effective to improve our documents. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Mar 16 07:26:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSAZd-00071w-SH; Fri, 16 Mar 2007 07:26:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSAZc-00071h-EB for isms@ietf.org; Fri, 16 Mar 2007 07:26:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSAZX-0003nU-In for isms@ietf.org; Fri, 16 Mar 2007 07:26:16 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2007 12:26:10 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2GBQ8ES001295; Fri, 16 Mar 2007 12:26:08 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4443.cisco.com [10.61.81.90]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2GBQ8lZ013547; Fri, 16 Mar 2007 11:26:08 GMT Message-ID: <45FA7ED0.3060600@cisco.com> Date: Fri, 16 Mar 2007 12:26:08 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "Kaushik Narayan (kaushik)" , David Harrington , "David B. Nelson" , isms@ietf.org Subject: Re: [Isms] SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted References: <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> <618694EF0B657246A4D55A97E38274C3032CC615@xmb-sjc-22d.amer.cisco.com> <20070316084724.GE759@elstar.iuhb02.iu-bremen.de> In-Reply-To: <20070316084724.GE759@elstar.iuhb02.iu-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1797; t=1174044368; x=1174908368; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Isms]=09SSHSMRADIUSIntegrationdraft(draft-narayan-is ms-sshsm-radius-01.txt)submitted |Sender:=20; bh=w3ddwkt30Olubfw8pqJyoMAlAaSjJqknz/pwfEqfmlc=; b=rxLKQQdkNbiwE/5Jt/IPxhctB55YsNKms3pmlFk4Zv+2xwdIdYNUW1z+nOM4jAuOEQBKH04q wOdVF3HcDXd+tM0UEl0Saed7p3HzIAjhYJl7OGJ3OC4zTrWOyMZwUkdk; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Juergen Schoenwaelder wrote: > Anyway, I am in general quite confused by this thread as it seems that > people talk about different things without really trying to understand > the other's background / terminology / view of the world. > > Perhaps it helps to go through the RADIUS document and to bring up > paragraphs that are considered problematic and to propose alternative > text fragments so that we avoid getting trapped in some general and > abstract discussions that we had in the past and which might not be > effective to improve our documents. > TMSM should work both with a local store AND radius. If there are problems with either that's what needs to be found. This thread came up because David Nelson wrote: > The modularity of the current SNMP architecture seems to be predicated upon > the notion that passing around securityName is all that is ever needed. > That seems to be predicated on the notion that there is a local > configuration store that contains useful information addressed by > securityName. That seems to imply USM or something very much like it. If > we really want to break the ties to USM, we're going to need to address this > issue. > And then Dave Harrington responded: > So far, I have not seen any proposals, either written or just proposed > verbally, that provides a secure transport with all the security > characteristics of USM. A critical feature of USM, not provided by SSH > or TLS or RADIUS proposals so far, is local authentication with NO > ties to a third party authenticator. > Kaushik, Keith and I proposed a method last summer that would have precisely addressed the 2nd sentence in that paragraph. I believe this leaves David Nelson's question somewhat unanswered. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Mar 16 07:41:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSAo2-0000VC-4L; Fri, 16 Mar 2007 07:41:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSAo1-0000V7-Mv for isms@ietf.org; Fri, 16 Mar 2007 07:41:09 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSAo0-000779-9R for isms@ietf.org; Fri, 16 Mar 2007 07:41:09 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A50406DBFE; Fri, 16 Mar 2007 12:41:07 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14261-06; Fri, 16 Mar 2007 12:41:03 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id ECDD26DB67; Fri, 16 Mar 2007 12:41:03 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id B37731E8CA8; Fri, 16 Mar 2007 12:41:02 +0100 (CET) Date: Fri, 16 Mar 2007 12:41:02 +0100 From: Juergen Schoenwaelder To: Eliot Lear Subject: Re: [Isms] SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Message-ID: <20070316114102.GB991@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Eliot Lear , "Kaushik Narayan (kaushik)" , David Harrington , "David B. Nelson" , isms@ietf.org References: <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> <618694EF0B657246A4D55A97E38274C3032CC615@xmb-sjc-22d.amer.cisco.com> <20070316084724.GE759@elstar.iuhb02.iu-bremen.de> <45FA7ED0.3060600@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45FA7ED0.3060600@cisco.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Mar 16, 2007 at 12:26:08PM +0100, Eliot Lear wrote: > And then Dave Harrington responded: > > >So far, I have not seen any proposals, either written or just proposed > >verbally, that provides a secure transport with all the security > >characteristics of USM. A critical feature of USM, not provided by SSH > >or TLS or RADIUS proposals so far, is local authentication with NO > >ties to a third party authenticator. > > Kaushik, Keith and I proposed a method last summer that would have > precisely addressed the 2nd sentence in that paragraph. I believe this > leaves David Nelson's question somewhat unanswered. Again, is a local password or key pair in the context of SSH not exactly addressing the 2nd sentence above, namely "local authentication with NO ties to a third party authenticator"? I remain in the confused state for now. /js PS: Our implementation calls out to PAM and it actually does not matter whether you configure radius, something else, or local passwords if you like that. -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Mar 16 08:09:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSBFe-0003Gr-Cj; Fri, 16 Mar 2007 08:09:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSBFd-0003Gi-Cv for isms@ietf.org; Fri, 16 Mar 2007 08:09:41 -0400 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSBFb-0004O4-4U for isms@ietf.org; Fri, 16 Mar 2007 08:09:41 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc15) with SMTP id <20070316120938b1500c94noe>; Fri, 16 Mar 2007 12:09:38 +0000 From: "David Harrington" To: , "'Eliot Lear'" References: <01df01c7670b$4eb38ec0$0600a8c0@china.huawei.com> <618694EF0B657246A4D55A97E38274C3032CC615@xmb-sjc-22d.amer.cisco.com> <20070316084724.GE759@elstar.iuhb02.iu-bremen.de> <45FA7ED0.3060600@cisco.com> <20070316114102.GB991@elstar.iuhb02.iu-bremen.de> Subject: RE: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Date: Fri, 16 Mar 2007 08:09:28 -0400 Message-ID: <001501c767c3$f337c2f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20070316114102.GB991@elstar.iuhb02.iu-bremen.de> Thread-Index: Acdnv/1Vu86FBWVbTUaRiEbZYVa7xQAAy+uw X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, Yes, I was off-track. A local password or key pair should be acceptable. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Friday, March 16, 2007 7:41 AM > To: Eliot Lear > Cc: Kaushik Narayan (kaushik); David Harrington; David B. > Nelson; isms@ietf.org > Subject: Re: > [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-rad > ius-01.txt)submitted > > On Fri, Mar 16, 2007 at 12:26:08PM +0100, Eliot Lear wrote: > > > And then Dave Harrington responded: > > > > >So far, I have not seen any proposals, either written or > just proposed > > >verbally, that provides a secure transport with all the security > > >characteristics of USM. A critical feature of USM, not > provided by SSH > > >or TLS or RADIUS proposals so far, is local authentication with NO > > >ties to a third party authenticator. > > > > Kaushik, Keith and I proposed a method last summer that would have > > precisely addressed the 2nd sentence in that paragraph. I > believe this > > leaves David Nelson's question somewhat unanswered. > > Again, is a local password or key pair in the context of SSH not > exactly addressing the 2nd sentence above, namely "local > authentication with NO ties to a third party authenticator"? I remain > in the confused state for now. > > /js > > PS: Our implementation calls out to PAM and it actually does not > matter whether you configure radius, something else, or local > passwords if you like that. > > -- > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Mar 16 14:54:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSHZE-00019g-NP; Fri, 16 Mar 2007 14:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSHZD-00019W-Hs for isms@ietf.org; Fri, 16 Mar 2007 14:54:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSHZ4-0002IB-Fl for isms@ietf.org; Fri, 16 Mar 2007 14:54:19 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2007 11:54:10 -0700 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 l2GIs9N1027542; Fri, 16 Mar 2007 11:54:09 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2GIrfML003950; Fri, 16 Mar 2007 18:53:57 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 11:53:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Date: Fri, 16 Mar 2007 11:53:44 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3032CC8E7@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <20070316114102.GB991@elstar.iuhb02.iu-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Thread-Index: AcdnwAA11bS+xE1kT1ODf42Tqspk5QAO3L3Q From: "Kaushik Narayan \(kaushik\)" To: , "Eliot Lear" X-OriginalArrivalTime: 16 Mar 2007 18:53:49.0386 (UTC) FILETIME=[6EEE02A0:01C767FC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2172; t=1174071249; x=1174935249; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms- sshsm-radius-01.txt)submitted |Sender:=20; bh=m/3BnHvlrUZuyIGQtnG+j6YorNa9rNUS5Cyth2ANb5M=; b=OIuIYi/rr/5iSnqVrtdPO8YR78ERZ+lhyyJuQSMA/NkpqFWPlMBroYBnnE952jr+udpueIIi iB3dYsaw+5vYyj47tOo1MgWSBp5JHV1zyepWeSt50b5U7xHTb0uneoXRfXL/yZtFBUXTP4JlN4 hh9pFp6cND8TTB2bPtbOn59AE=; Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi Juergen, I think the question atleast in my mind is about not whether we would support local accounts but more about how to handle them in the context of the current RADIUS integration draft. As I suggested in my previous thread we have two options 1. Leave to implementation specific approaches such as a Pluggable Authentication Module (PAM) framework. 2. Build the chaining of authentication methods into the security model, this would be required especially if we want build an access control model that is RADIUS specific. It would be useful to get some discussion on this topic. regards, kaushik! -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Friday, March 16, 2007 4:41 AM To: Eliot Lear Cc: Kaushik Narayan (kaushik); David Harrington; David B. Nelson; isms@ietf.org Subject: Re: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt )submitted On Fri, Mar 16, 2007 at 12:26:08PM +0100, Eliot Lear wrote: =20 > And then Dave Harrington responded: >=20 > >So far, I have not seen any proposals, either written or just=20 > >proposed verbally, that provides a secure transport with all the=20 > >security characteristics of USM. A critical feature of USM, not=20 > >provided by SSH or TLS or RADIUS proposals so far, is local=20 > >authentication with NO ties to a third party authenticator. >=20 > Kaushik, Keith and I proposed a method last summer that would have=20 > precisely addressed the 2nd sentence in that paragraph. I believe=20 > this leaves David Nelson's question somewhat unanswered. Again, is a local password or key pair in the context of SSH not exactly addressing the 2nd sentence above, namely "local authentication with NO ties to a third party authenticator"? I remain in the confused state for now. /js PS: Our implementation calls out to PAM and it actually does not matter whether you configure radius, something else, or local passwords if you like that. --=20 Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Mar 16 15:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSIRi-0005J8-Ii; Fri, 16 Mar 2007 15:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSIRh-0005J3-ST for isms@ietf.org; Fri, 16 Mar 2007 15:50:37 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSIRg-0002lh-DW for isms@ietf.org; Fri, 16 Mar 2007 15:50:37 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6E6006DBFE; Fri, 16 Mar 2007 20:50:33 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28184-03; Fri, 16 Mar 2007 20:50:29 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id DE39B6DB2F; Fri, 16 Mar 2007 20:50:29 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id A7A681EAA4A; Fri, 16 Mar 2007 20:50:28 +0100 (CET) Date: Fri, 16 Mar 2007 20:50:28 +0100 From: Juergen Schoenwaelder To: "Kaushik Narayan (kaushik)" Subject: Re: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Message-ID: <20070316195028.GA3333@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: "Kaushik Narayan (kaushik)" , Eliot Lear , David Harrington , "David B. Nelson" , isms@ietf.org References: <20070316114102.GB991@elstar.iuhb02.iu-bremen.de> <618694EF0B657246A4D55A97E38274C3032CC8E7@xmb-sjc-22d.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <618694EF0B657246A4D55A97E38274C3032CC8E7@xmb-sjc-22d.amer.cisco.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Mar 16, 2007 at 11:53:44AM -0700, Kaushik Narayan (kaushik) wrote: > Hi Juergen, > > I think the question atleast in my mind is about not whether we would > support local accounts but more about how to handle them in the context > of the current RADIUS integration draft. As I suggested in my previous > thread we have two options > > 1. Leave to implementation specific approaches such as a Pluggable > Authentication Module (PAM) framework. As an implementor and system administrator, I like PAM because this is used by many pieces of software... > 2. Build the chaining of authentication methods into the security model, > this would be required especially if we want build an access control > model that is RADIUS specific. > > It would be useful to get some discussion on this topic. ... and here I have no clue what this is supposed to be good for or why things are needed in the security model; remember that access control is done in the access control model (and all the security processing including authentication exchanges happen in the secure transport models, at least for SSH or TLS. Are you saying all the work in the last months was heading in the wrong direction?? My understanding is that we have in principle two mappings: a) authenticated principal -> securityName b) securityName -> groupName The first mapping a) happens in the security model (USM) or in the transport mappings (TSM). The mapping b) happens in the access control subsystem, that is VACM. We should not confuse these things (I think section 3.3.2 in the RADIUS document is pretty unclear and potentially confusing things, e.g. sentences such as The User- Based Security Method (USM) integrates with VACM, by mapping the user identity as defined in USM to access rights within VACM. seem wrong since all USM provides is a securityName. Do you say this is all wrong? Or is it about how to pass RADIUS attributes provided in a) up to an access control mapping which does b) that you have in mind? /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Mar 17 16:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSfcP-0005Ap-Hs; Sat, 17 Mar 2007 16:35:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSfcN-0005AF-QS for isms@ietf.org; Sat, 17 Mar 2007 16:35:11 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSfYP-0002oO-VB for isms@ietf.org; Sat, 17 Mar 2007 16:31:07 -0400 Received: from harrington73653 (unknown[63.118.136.212]) by comcast.net (alnrmhc12) with SMTP id <20070317203105b1200dbgkne>; Sat, 17 Mar 2007 20:31:05 +0000 From: "David Harrington" To: Date: Sat, 17 Mar 2007 16:30:51 -0400 Message-ID: <007901c768d3$27df4400$f471743f@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdo0ppNPYSTeNf7SsChA7uBxm1sOA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Subject: [Isms] Draft-narayan-isms-sshsm-radius-01 review X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I have reviewed this document and have some general and some specific suggestions. Overall, I think the document is progressing, but needs to be more consistent with other isms documents, and could use a restructuring. General: I recommend restructuring the document based on what is to be supported, in an incremental manner: 1) "integration with legacy RADIUS" which would only deal with authenticating the user and authorizing an SSH subsystem, and not deal with integration with an ACM (or make it implementation-dependent to hang onto authz attributes received during a legacy authn). 2) "integration with Dynamic RADIUS" which would support authorization for a SSH subsystem PLUS authorize-only support in a RADIUS-specific ACM. I suggest that the RADIUS state attribute established during authn be passed as the securityName, since that is what the authorize-only authz is tied to. To maintain modularity, an SSH-RADIUS transport model should pass the RADIUS state attribute in the tmStateReference as the proposed securityName, and the Transport Security Model would translate that into the securityName. A RADIUS-specific ACM would then use the securityName (RADIUS state attr) to attempt an authorize-only access-request, and use the returned attributes to determine what access should be allowed. If the securityname != a known RADIUS-state-attr, then RADIUS would return an access-reject. 3) "integration with the proposed management policy attributes". Used with authorize-only, RADIUS could return the new mgmt-policy-id attribute to be used to create a mapping from securityname (Radius-state-attr) to a "named" mgmt policy. ---------Specific comments--------- Introduction as noted previously, there is no SSH SM, only an SSH TM. This should be fixed throughout the document. section2 s/(SSHSM) [sshsm]/[sshsm]/ s/Security Model/Transport Model/ "SSHSM requires ..." should be rewritten to better reflect current isms documents. I am willign to help rewrite this if you want. s/explicitly// Section 3.1 I recommend moving the sentence starting "SSH integration" before the sentence starting "RADIUS will indicate" Section 3.2 s/support multiple/supports multiple/ s/used SSH/used by SSH/ s/clients,/clients;/ The sentence starting "the 'password' method" is not needed in this document; it is irrelevant to SNMP integration. The sentence starting "SSH server implementations tyically" is not needed. s/rely of implementation/rely on implementation/ 3.3 My mailer won't let me tell you that you have "the" mispelled as "teh" ;-) The paragraph starting "RADIUS Servers will usually" could be condensed. The sentence starting [radman] should start a new paragragh. 3.3.1 s/vlaue/value/ 3.3.2 What happens if RADIUS has authorization attributes from the access-accept saved and passed in tmStateRef provided by the transport model, but the security model (USM/community/etc.) does not use the authorized user (securityName) from the tmStateRef? The sentence starting "The User-based security mdoel integrates with VACM" is incorrect; USM integrates with the RFC3411 architecture, which integrates with VACM. The descritpotrion of the use of a local database is not consistent with the RFC3411 descriotio of this usage. This section talks about the proposed new mgmt-policy attributes, but we should try ot make th epoprosal not dependent on that proposal. See my general comments above. s/comprises a policy or group name/comprises a policy, e.g., a group name,/ s/mapping of the group name to/mapping of th epolicy name to/ "unlikely to change" and "likely to be based" are based on what experience? s/This mapping mechanisms is implementation specific/This mapping mechanisms is model- and implementation-specific/ 3.3.3 s/, at the most simple level,// s/RADIUS clients, with the NAS, initiates/A RADIUS client within the NAS initiates/ The sentence starting "In some cases" is not needed. The sentence starting "In many deployements" should start a new paragraph 3.3.4 TACACS needs a citation/reference s/separate out/separate/ 3.4 See general comments about securityname = RADIUS state attr 3.5 Sentence about accounting packets seems out of place; this should be dropped or expalined further. 3.6 discussion of PAM is not needed. That is purely implementation-specific and we do not discuss implementation issues. "there is no equivalent shell" - is an SSH subsystem comparable to a shell? "The ability of the SSH server to use ..." is this sentence needed? s/such as PAM, provide/such as pAM, may provide/ "Transport Mapping Security Model" is no longer valid. "It is possible therefore," is inconsistent with the architecure, since the ACM does not get passed the tmStateRef. "make calls to the RADIUS client" - would this be clearer as "make calls to the RADIUS server"? 5. s/amy/may/ 7. [sshsm] is incorrect. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Mar 17 16:56:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSfwv-0002KV-5R; Sat, 17 Mar 2007 16:56:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSfwu-0002JU-7p for isms@ietf.org; Sat, 17 Mar 2007 16:56:24 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSfv3-0007Oi-5v for isms@ietf.org; Sat, 17 Mar 2007 16:54:30 -0400 Received: from harrington73653 (unknown[63.118.136.212]) by comcast.net (alnrmhc13) with SMTP id <20070317205427b1300pubdfe>; Sat, 17 Mar 2007 20:54:28 +0000 From: "David Harrington" To: Date: Sat, 17 Mar 2007 16:54:13 -0400 Message-ID: <007a01c768d6$6c05d4c0$f471743f@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdo1hLUptPeMdlfTbKGj7vwOCDiqg== X-Spam-Score: 1.1 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Isms] review of draft-nelson-radius-management-authorization-04 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I support this proposal. I think it would benefit from an introduction that discusses "named policy" access controls before the discussion of the RADIUS attributes to support "named policies". Abstract s/Aauthentication/Authentication/ 1. The document uses terminology from RFC2865 ..." Identify the titles of these RFCs. 3. It is unclear to me why the management-policy-id is for framed management only. Why not also for non-framed protocols? 4. s/is by means outside/is outside/ then add a sentence pointing out examples of policy-specification mechanisms that could be applied, including MIBs, PIBs, XML configuration model, local configuration files, etc. 5. This section seems incomplete. s/this attributes/this attribute/ "one new attribute" - but doesn't section introduce a second new attribute? 6.1 "left to right" would this be network-order? "one new value" aren't there two? 7.1 s/SNMP v3/SNMPv3/ Can this be used to specify snmpv1 and snmpv2c? We are not recommendign their use, only acknowledgeing their presence in real networks, and discussing how to apply policies to them. 9. proxy needs to be identified as RADIUS and/or Diameter proxy to distinguish it from SNMP proxy. Note that the SNMP proxy-forwarder application never opens the PDU and does not apply any access control based on the PDU contents. 11. I find the combination of "framed management protocol" and "non-framed-management-security" a bit odd. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Mar 19 08:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGbo-0004uu-LP; Mon, 19 Mar 2007 08:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGbn-0004uo-FM for isms@ietf.org; Mon, 19 Mar 2007 08:05:03 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTGbj-0006XC-VY for isms@ietf.org; Mon, 19 Mar 2007 08:05:03 -0400 Received: from pc6 (1Cust106.tnt8.lnd4.gbr.da.uu.net [62.188.137.106]) by ranger.systems.pipex.net (Postfix) with SMTP id 96F7CE0001CE; Mon, 19 Mar 2007 12:04:53 +0000 (GMT) Message-ID: <019e01c76a16$1a01d160$0601a8c0@pc6> From: "tom.petch" To: "Juergen Quittek" , References: Subject: Re: [Isms] working group last call ondraft-ietf-isms-transport-security-model-03 Date: Mon, 19 Mar 2007 10:36:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.1 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org I think that this I-D uses securityModel in two different senses and as such, may confuse, mislead even. (securityLevel seems to be used as a class of object of which there are multiple instances). There is an object in the message which describes the security requested by the application, say application.securityLevel; and there is the security achieved by the transport, which is then placed in the tmStateReference cache by the Transport Model and used by the Transport Security Model for comparison, say transport.securityLevel. s2.4 last paragraph and s3.1.1 differentiate the two usages while using the same term for both; in other cases, I find this less clear. s2.1.2 I find unclear, perhaps incorrect. I believe that, as s3.1.1 states, application.securityLevel is used in the request but that transport.securityLevel is then used by TSM, but not to assert the level of security achieved but to check that the level achieved is not less than application.securityLevel as described s2.4. But I do not think that that is what these words say. s2.2 I assume that this is application.securityLevel s2.5 I assume that both uses refer to application.securityLevel s.4 which securityLevel is returned? s.4.2 2) which securityLevel is intended? Should the search in the LCD be for a cache entry whose transport.securityLevel is not less than application.securityLevel or for an exact match? Does this vary depending on whether this is a Response message/NO or a Request? And if an LCD entry is created, then which securityLevel is put into it? for an outoing message, transport.securityLevel is most likely unknown; on the other hand, the tsms i-d s3.2.3 talks of "The security parameters include ... which authentication and privacy services were (should be) applied to the message (securityLevel)." The use of 'were' suggests that transport.securityLevel is intended. I don't think this has been discussed and see problems with either alternative. s.5 which securityLevel is returned? s 5.2 2) by implication this is transport.securityLevel but is open to misinterpretation s 5.2 9) which securityLevel is cached? I think that both need to be. Tom Petch ----- Original Message ----- From: "Juergen Quittek" To: Sent: Saturday, March 10, 2007 12:13 AM Subject: [Isms] working group last call ondraft-ietf-isms-transport-security-model-03 > Dear all, > > This is the working group last call on the > "Transport Security Model for SNMP" > to be found at > . > > The authors and the chairs think that this document is mature enough > for last call. > > Please do review the document and post your comments on this list until > March 25, 2007. Of course it would be great to get your comments already > before our next meeting on March 22. > > Please also post to the list if you have read the document and are fine > with it as it is. It is very useful to know how many people have read > the document. > > Thanks, > > Juergen Q. > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 > NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > Registered in England 2832014 > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Mar 19 08:33:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTH3W-00024Q-GA; Mon, 19 Mar 2007 08:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTH3V-00022q-Mv for isms@ietf.org; Mon, 19 Mar 2007 08:33:41 -0400 Received: from alnrmhc16.comcast.net ([204.127.225.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTH3U-00036v-78 for isms@ietf.org; Mon, 19 Mar 2007 08:33:41 -0400 Received: from harrington73653 (dhcp-11e6.ietf68.org[130.129.17.230]) by comcast.net (alnrmhc16) with SMTP id <20070319123338b16006hp0he>; Mon, 19 Mar 2007 12:33:39 +0000 From: "David Harrington" To: "'tom.petch'" , "'Juergen Quittek'" , References: <019e01c76a16$1a01d160$0601a8c0@pc6> Subject: RE: [Isms] working group last callondraft-ietf-isms-transport-security-model-03 Date: Mon, 19 Mar 2007 08:33:08 -0400 Message-ID: <00e301c76a22$ca0dc1c0$f471743f@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <019e01c76a16$1a01d160$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdqHtR+564qdUbSTdyGAZapmnET4QAA3b+w X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Monday, March 19, 2007 5:37 AM > To: Juergen Quittek; isms@ietf.org > Subject: Re: [Isms] working group last > callondraft-ietf-isms-transport-security-model-03 > > I think that this I-D uses securityModel in two different > senses and as such, > may confuse, mislead even. (securityLevel seems to be used > as a class of object > of which there are multiple instances). > > There is an object in the message which describes the > security requested by the > application, say application.securityLevel; and there is the > security achieved > by the transport, which is then placed in the > tmStateReference cache by the > Transport Model and used by the Transport Security Model for > comparison, say > transport.securityLevel. > > s2.4 last paragraph and s3.1.1 differentiate the two usages > while using the > same > term for both; in other cases, I find this less clear. I concur. I think the securityName and securityLevel in tmSatteRef cache should be called tmSecurityName and tmSecurityLevel. The names used in the ASI (extracted from the message presumably) are previosuly defined, and should remain the same, IMO. I will review the rest of these comments later. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Mar 19 13:35:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLl6-0007hs-2q; Mon, 19 Mar 2007 13:35:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLl5-0007hB-Fi for isms@ietf.org; Mon, 19 Mar 2007 13:34:59 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLkq-0001Hs-VJ for isms@ietf.org; Mon, 19 Mar 2007 13:34:59 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2JHYeqf023189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 10:34:40 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l2JHYdGR004287; Mon, 19 Mar 2007 10:34:39 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l2JHYZKY004119; Mon, 19 Mar 2007 10:34:37 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 10:34:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Date: Mon, 19 Mar 2007 10:34:36 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584E3C@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <20070316195028.GA3333@elstar.iuhb02.iu-bremen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Thread-Index: AcdoBKMk4CxSVF/VRwKmI+D+3apyWQCReg0g References: <20070316114102.GB991@elstar.iuhb02.iu-bremen.de><618694EF0B657246A4D55A97E38274C3032CC8E7@xmb-sjc-22d.amer.cisco.com> <20070316195028.GA3333@elstar.iuhb02.iu-bremen.de> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 19 Mar 2007 17:34:37.0735 (UTC) FILETIME=[DDF6DB70:01C76A4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org My aspirations as a large end user for this WG is for ISMS authentication to be able to fit into (integrate with) the authentication systems used within existing large scale deployments. The problem for this WG is that my goal ultimately is site specific. However, for a variety of reasons, we end users are slowly being "encouraged" to migrate apps to PKI, and so I believe that the solution should include hooks to support PKI. Historically, user name and password is also prevalent, so I also believe that the default approach should also be able to include that. Many other authentication mechanisms are deployed, and it is A Good Thing to also have provisions to support them, but I personally do not believe that they are as compelling as PKI and username-password, which I believe constitute the absolute minimum default alternatives to be supported. Concerning whether this goal of supporting PKI and username-password and other-popular-authentication-mechanisms should be accomplished via PAM or authentication chaining, that particular issue should probably be solved by asking which alternative is the cleanest for the ISMS codebase to support? All things being equal, please favor approaches that are used elsewhere, such as PAM.=20 Rather than "leave to implementations specific approaches" and thereby not address it in the ISMS codebase, I prefer the codebase itself implementing PAM as a default, with the provision of optionally supporting other techniques as well. My concern is that if we don't provide a default solution to this problem, then we will continue to have the same types of problems with ISMS that we currently have with SNMPv3 -- irregularly built applications so that key distribution can't be assured in large deployments, despite the presence of RFCs which, if implemented, could have assured key distribution. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Friday, March 16, 2007 12:50 PM To: Kaushik Narayan (kaushik) Cc: isms@ietf.org Subject: Re:[Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01. txt)submitted On Fri, Mar 16, 2007 at 11:53:44AM -0700, Kaushik Narayan (kaushik) wrote: > Hi Juergen, >=20 > I think the question atleast in my mind is about not whether we would=20 > support local accounts but more about how to handle them in the=20 > context of the current RADIUS integration draft. As I suggested in my=20 > previous thread we have two options >=20 > 1. Leave to implementation specific approaches such as a Pluggable=20 > Authentication Module (PAM) framework. As an implementor and system administrator, I like PAM because this is used by many pieces of software... =20 > 2. Build the chaining of authentication methods into the security=20 > model, this would be required especially if we want build an access=20 > control model that is RADIUS specific. >=20 > It would be useful to get some discussion on this topic. ... and here I have no clue what this is supposed to be good for or why things are needed in the security model; remember that access control is done in the access control model (and all the security processing including authentication exchanges happen in the secure transport models, at least for SSH or TLS. Are you saying all the work in the last months was heading in the wrong direction?? My understanding is that we have in principle two mappings: a) authenticated principal -> securityName b) securityName -> groupName The first mapping a) happens in the security model (USM) or in the transport mappings (TSM). The mapping b) happens in the access control subsystem, that is VACM. We should not confuse these things (I think section 3.3.2 in the RADIUS document is pretty unclear and potentially confusing things, e.g. sentences such as The User- Based Security Method (USM) integrates with VACM, by mapping the user identity as defined in USM to access rights within VACM. seem wrong since all USM provides is a securityName. Do you say this is all wrong? Or is it about how to pass RADIUS attributes provided in a) up to an access control mapping which does b) that you have in mind? /js --=20 Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Mar 19 15:39:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTNh7-0000vH-Pz; Mon, 19 Mar 2007 15:39:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTNh6-0000ut-0n for isms@ietf.org; Mon, 19 Mar 2007 15:39:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTNh3-0002mu-An for isms@ietf.org; Mon, 19 Mar 2007 15:38:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 19 Mar 2007 12:38:58 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2JJcuTq008156; Mon, 19 Mar 2007 12:38:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2JJcfF4018867; Mon, 19 Mar 2007 19:38:56 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 12:38:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Draft-narayan-isms-sshsm-radius-01 review Date: Mon, 19 Mar 2007 12:38:47 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3032CCE82@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <007901c768d3$27df4400$f471743f@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Draft-narayan-isms-sshsm-radius-01 review Thread-Index: Acdo0ppNPYSTeNf7SsChA7uBxm1sOABf/5AQ From: "Kaushik Narayan \(kaushik\)" To: "David Harrington" , X-OriginalArrivalTime: 19 Mar 2007 19:38:49.0482 (UTC) FILETIME=[378D36A0:01C76A5E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6901; t=1174333136; x=1175197136; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Isms]=20Draft-narayan-isms-sshsm-radius-01=20review |Sender:=20; bh=IXoX7aymX1oNYsidfKKTUhSvYM1sRDgks2F3OqUM/4Y=; b=VPcY6Yf64Q0Tn8UaTDSlMnWyR9TZyV76yN/2BGf8oHTS1PbTDO+lsNwPOXxBeWCaT6hco1Ax b826xPw/Vbs1NGcj6mU9azfcA+HyboiyQr0fwlyKF3jSEB6eFDqbHxI8; Authentication-Results: sj-dkim-3; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi David, Thanks for your comments. Please find my reply inline.=20 -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Saturday, March 17, 2007 1:31 PM To: isms@ietf.org Subject: [Isms] Draft-narayan-isms-sshsm-radius-01 review Hi, I have reviewed this document and have some general and some specific suggestions. Overall, I think the document is progressing, but needs to be more consistent with other isms documents, and could use a restructuring. General: I recommend restructuring the document based on what is to be supported, in an incremental manner: 1) "integration with legacy RADIUS" which would only deal with authenticating the user and authorizing an SSH subsystem, and not deal with integration with an ACM (or make it implementation-dependent to hang onto authz attributes received during a legacy authn). 2) "integration with Dynamic RADIUS" which would support authorization for a SSH subsystem PLUS authorize-only support in a RADIUS-specific ACM.=20 I suggest that the RADIUS state attribute established during authn be passed as the securityName, since that is what the authorize-only authz is tied to.=20 To maintain modularity, an SSH-RADIUS transport model should pass the RADIUS state attribute in the tmStateReference as the proposed securityName, and the Transport Security Model would translate that into the securityName. A RADIUS-specific ACM would then use the securityName (RADIUS state attr) to attempt an authorize-only access-request, and use the returned attributes to determine what access should be allowed. If the securityname !=3D a known RADIUS-state-attr, then RADIUS would = return an access-reject. 3) "integration with the proposed management policy attributes". Used with authorize-only, RADIUS could return the new mgmt-policy-id attribute to be used to create a mapping from securityname (Radius-state-attr) to a "named" mgmt policy. =20 The current draft suggests two models of integration for access control A. augment VACM to use securityName or other attributes contained with the RADIUS state attribute. B. build new ACM for RADIUS integration that can use securityName and use RADIUS to acquire additional authorization information.=20 Are you suggesting that we donot pursue the first model. ---------Specific comments--------- Introduction as noted previously, there is no SSH SM, only an SSH TM. This should be fixed throughout the document. section2 s/(SSHSM) [sshsm]/[sshsm]/ s/Security Model/Transport Model/ "SSHSM requires ..." should be rewritten to better reflect current isms documents. I am willign to help rewrite this if you want. s/explicitly// Sure, that would help. Section 3.1 I recommend moving the sentence starting "SSH integration" before the sentence starting "RADIUS will indicate" Section 3.2 s/support multiple/supports multiple/ s/used SSH/used by SSH/ s/clients,/clients;/ The sentence starting "the 'password' method" is not needed in this document; it is irrelevant to SNMP integration. The sentence starting "SSH server implementations tyically" is not needed. s/rely of implementation/rely on implementation/ 3.3 My mailer won't let me tell you that you have "the" mispelled as "teh" ;-) The paragraph starting "RADIUS Servers will usually" could be condensed. The sentence starting [radman] should start a new paragragh. 3.3.1 s/vlaue/value/ Will fix these. 3.3.2 What happens if RADIUS has authorization attributes from the access-accept saved and passed in tmStateRef provided by the transport model, but the security model (USM/community/etc.) does not use the authorized user (securityName) from the tmStateRef? I am not sure about this question. The assumption here is that a specific security model (such as sshsm) MUST use the tmStateRef. Are you asking what if a security model uses a different securityName than the one saved in the tmStateRef. As per RFC2865, the RADIUS client will send the RADIUS state attribute received in the Access Accept unmodified in the subsequent RADIUS request. The security model won't be able to change the state attribute which would be used by the RADIUS server to provide authorization information. The sentence starting "The User-based security mdoel integrates with VACM" is incorrect; USM integrates with the RFC3411 architecture, which integrates with VACM. The descritpotrion of the use of a local database is not consistent with the RFC3411 descriotio of this usage. This section talks about the proposed new mgmt-policy attributes, but we should try ot make th epoprosal not dependent on that proposal. See my general comments above. s/comprises a policy or group name/comprises a policy, e.g., a group name,/ s/mapping of the group name to/mapping of th epolicy name to/ "unlikely to change" and "likely to be based" are based on what experience? s/This mapping mechanisms is implementation specific/This mapping mechanisms is model- and implementation-specific/ 3.3.3 s/, at the most simple level,// s/RADIUS clients, with the NAS, initiates/A RADIUS client within the NAS initiates/ The sentence starting "In some cases" is not needed. The sentence starting "In many deployements" should start a new paragraph 3.3.4 TACACS needs a citation/reference s/separate out/separate/ 3.4 See general comments about securityname =3D RADIUS state attr 3.5 Sentence about accounting packets seems out of place; this should be dropped or expalined further. Will fix these 3.6 discussion of PAM is not needed. That is purely implementation-specific and we do not discuss implementation issues. =20 I think it is useful to mention PAM since that's prevelant model of integrating authentication mechanisms into SSH although it might be implementation specific. "there is no equivalent shell" - is an SSH subsystem comparable to a shell? "The ability of the SSH server to use ..." is this sentence needed? s/such as PAM, provide/such as pAM, may provide/ "Transport Mapping Security Model" is no longer valid. "It is possible therefore," is inconsistent with the architecure, since the ACM does not get passed the tmStateRef. "make calls to the RADIUS client" - would this be clearer as "make calls to the RADIUS server"? 5. s/amy/may/ 7. [sshsm] is incorrect. Will fix these. Thanks, kaushik David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Mar 19 20:27:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTSBz-0004ah-7Q; Mon, 19 Mar 2007 20:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTSBy-0004aa-GM for isms@ietf.org; Mon, 19 Mar 2007 20:27:10 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTSBu-0000aq-8P for isms@ietf.org; Mon, 19 Mar 2007 20:27:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2007 17:27:05 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2K0R5AA032684; Mon, 19 Mar 2007 17:27:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2K0R1Ei010323; Tue, 20 Mar 2007 00:27:01 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:27:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Date: Mon, 19 Mar 2007 17:27:02 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C3032CD04D@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <474EEBD229DF754FB83D256004D0210802584E3C@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Thread-Index: AcdoBKMk4CxSVF/VRwKmI+D+3apyWQCReg0gAAqh8jA= From: "Kaushik Narayan \(kaushik\)" To: "Fleischman, Eric" , X-OriginalArrivalTime: 20 Mar 2007 00:27:00.0979 (UTC) FILETIME=[7A164430:01C76A86] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5577; t=1174350425; x=1175214425; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms- sshsm-radius-01.txt)submitted |Sender:=20; bh=8PC1M5sH3Z7iXTNveCdkvzK3iKdkFmKNAvTujDZYq0Q=; b=aACL0zRnFCc+ZtMpdFjT2Ddq3ISI32Q9G7RypMSqrT7On/En3tYcO6xYR2UQErxSvCBVdE2x 9qmVKMNtXKlBdi8ggeOGQCULsBa1lst0/gv9xEpR4wTPyQueot69nAZ+; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi Eric, Please find my reply inline.=20 My aspirations as a large end user for this WG is for ISMS authentication to be able to fit into (integrate with) the authentication systems used within existing large scale deployments. The problem for this WG is that my goal ultimately is site specific. However, for a variety of reasons, we end users are slowly being "encouraged" to migrate apps to PKI, and so I believe that the solution should include hooks to support PKI. Historically, user name and password is also prevalent, so I also believe that the default approach should also be able to include that. Many other authentication mechanisms are deployed, and it is A Good Thing to also have provisions to support them, but I personally do not believe that they are as compelling as PKI and username-password, which I believe constitute the absolute minimum default alternatives to be supported. Concerning whether this goal of supporting PKI and username-password and other-popular-authentication-mechanisms should be accomplished via PAM or authentication chaining, that particular issue should probably be solved by asking which alternative is the cleanest for the ISMS codebase to support? All things being equal, please favor approaches that are used elsewhere, such as PAM.=20 Rather than "leave to implementations specific approaches" and thereby not address it in the ISMS codebase, I prefer the codebase itself implementing PAM as a default, with the provision of optionally supporting other techniques as well. My concern is that if we don't provide a default solution to this problem, then we will continue to have the same types of problems with ISMS that we currently have with SNMPv3 -- irregularly built applications so that key distribution can't be assured in large deployments, despite the presence of RFCs which, if implemented, could have assured key distribution. =20 Just to clarify, PAMs are typically provided by operating systems for password based authentication. SSH2 implementations provide chaining between X.509 based authentication & password based authentication methods & rely on PAMs to chain individual password based mechanisms. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, March 16, 2007 12:50 PM To: Kaushik Narayan (kaushik) Cc: isms@ietf.org Subject: Re:[Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01. txt)submitted On Fri, Mar 16, 2007 at 11:53:44AM -0700, Kaushik Narayan (kaushik) wrote: > Hi Juergen, >=20 > I think the question atleast in my mind is about not whether we would=20 > support local accounts but more about how to handle them in the=20 > context of the current RADIUS integration draft. As I suggested in my=20 > previous thread we have two options >=20 > 1. Leave to implementation specific approaches such as a Pluggable=20 > Authentication Module (PAM) framework. As an implementor and system administrator, I like PAM because this is used by many pieces of software... =20 > 2. Build the chaining of authentication methods into the security=20 > model, this would be required especially if we want build an access=20 > control model that is RADIUS specific. >=20 > It would be useful to get some discussion on this topic. ... and here I have no clue what this is supposed to be good for or why things are needed in the security model; remember that access control is done in the access control model (and all the security processing including authentication exchanges happen in the secure transport models, at least for SSH or TLS. Are you saying all the work in the last months was heading in the wrong direction?? =20 Sorry, my comment is confusing. I wasn't suggesting that we include authentication part of the access control model. I was really trying to understand whether we need include PAM like functionality part of the security model since PAM implementations (for multiple password mechanisms) might not be available on all operating systems that sshsm will be deployed. I think you have mentioned this question in your email. My understanding is that we have in principle two mappings: a) authenticated principal -> securityName b) securityName -> groupName The first mapping a) happens in the security model (USM) or in the transport mappings (TSM). The mapping b) happens in the access control subsystem, that is VACM. We should not confuse these things (I think section 3.3.2 in the RADIUS document is pretty unclear and potentially confusing things, e.g. sentences such as The User- Based Security Method (USM) integrates with VACM, by mapping the user identity as defined in USM to access rights within VACM. seem wrong since all USM provides is a securityName. Do you say this is all wrong? Or is it about how to pass RADIUS attributes provided in a) up to an access control mapping which does b) that you have in mind? I agree that the text in section 3.3.2 is misleading. The question is whether we can extend VACM to accept a securityName -> groupName mapping done by the RADIUS server. /js --=20 Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Mar 20 12:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgtl-0002gM-2x; Tue, 20 Mar 2007 12:09:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgtk-0002ct-2P for isms@ietf.org; Tue, 20 Mar 2007 12:09:20 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTgtf-0006yR-EW for isms@ietf.org; Tue, 20 Mar 2007 12:09:19 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2KG99ks006796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 11:09:09 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l2KG99Ph028295; Tue, 20 Mar 2007 11:09:09 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l2KG97Hf028226; Tue, 20 Mar 2007 11:09:08 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 09:09:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Date: Tue, 20 Mar 2007 09:09:06 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584E4C@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <618694EF0B657246A4D55A97E38274C3032CD04D@xmb-sjc-22d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted Thread-Index: AcdoBKMk4CxSVF/VRwKmI+D+3apyWQCReg0gAAqh8jAAJNAeQA== References: <474EEBD229DF754FB83D256004D0210802584E3C@XCH-NW-6V1.nw.nos.boeing.com> <618694EF0B657246A4D55A97E38274C3032CD04D@xmb-sjc-22d.amer.cisco.com> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 20 Mar 2007 16:09:07.0208 (UTC) FILETIME=[16585080:01C76B0A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Kaushik, Yes, I am aware that my suggestions for a default PKI and username/password authentication basis correlates well with a SSHv2 transport (and RADIUS) and that there are O/S implications to source code.=20 However, the itch that I want scratched is that I want ISMS to include a viable default solution to key management so that the currently onerous problem with key distribution in large SNMPv3 deployments would be solved for ISMS. It's not enough to provide RFCs offering theoretical solutions. The specs themselves need to create default interoperable products that adequately (i.e., securely, scalably) handle key distribution issues. [By "key distribution" I am not solely considering symmetric and asymmetric keys, but also include the issue of secure username/password distribution.] --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Mar 20 15:26:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTjy7-000445-CA; Tue, 20 Mar 2007 15:26:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTjy5-00043t-UI for isms@ietf.org; Tue, 20 Mar 2007 15:26:01 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTjxc-0006OO-FS for isms@ietf.org; Tue, 20 Mar 2007 15:26:01 -0400 Received: from pc6 (1Cust12.tnt5.lnd4.gbr.da.uu.net [62.188.134.12]) by galaxy.systems.pipex.net (Postfix) with SMTP id 81FBCE0002F3; Tue, 20 Mar 2007 19:25:13 +0000 (GMT) Message-ID: <012701c76b1c$c5139640$0601a8c0@pc6> From: "tom.petch" To: "Juergen Quittek" , References: Subject: Re: [Isms] working group last call ondraft-ietf-isms-transport-security-model-03 Date: Tue, 20 Mar 2007 19:19:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.1 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org I commented before that I do not find s.2 clear. I also think that this is a crucial section for the document as a whole, especially for those who have not lived with these ideas for the past two years, as it provides the framework into which the details will fit. I believe it should be explicit, as in the following, with ** marking changes, of sentences or word " The Transport Security Model is designed to fit into the RFC3411 architecture as a Security Model in the Security Subsystem, and to utilize the services of a secure Transport Model. **The secure Transport Model maintains a cache, referenced by tmStateReference, which is used to pass information between the Transport Security Model and the secure Transport Model, and vice versa. **If the Transport Security Model is used with an insecure Transport Model, then the cache is unlikely to be populated with security parameters, which will cause the Transport Security Model to return an error (see section 5.2) **If another Security Model (eg Community-based Security Model) is used with a secure Transport Model, then the cache will be populated but the other Security Model may be unaware of the cache and ignore its contents (eg deriving the securityName from the Community name in the message instead of deriving it from the cache). **When the Transport Security Model is used with a secure Transport Model, as is intended to be the case, then the information in the cache is used by the Transport Security Model to translate between the security model-independent securityName and any identity used by the secure transport; and to record the tmSecurityLevel provided for the message by the transport (a level of security which may exceed the securityLevel requested for the message by the application). To maintain the RFC3411 modularity, the Transport Model does not know which securityModel will be used for an incoming message; the Message Processing Model will determine the securityModel to be used, in a Message Processing Model dependent manner. In an SNMPv3 message [RFC3412], the Transport Security Model **s/should/can/ be specified in the message header using the object securityModel. **The use of the Transport Security Model with other message types is outside the scope of this document." This is intended to be a rewording of what has been agreed and not to introduce changes. Tom Petch ----- Original Message ----- From: "Juergen Quittek" To: Sent: Saturday, March 10, 2007 12:13 AM Subject: [Isms] working group last call ondraft-ietf-isms-transport-security-model-03 > Dear all, > > This is the working group last call on the > "Transport Security Model for SNMP" > to be found at > . > > The authors and the chairs think that this document is mature enough > for last call. > > Please do review the document and post your comments on this list until > March 25, 2007. Of course it would be great to get your comments already > before our next meeting on March 22. > > Please also post to the list if you have read the document and are fine > with it as it is. It is very useful to know how many people have read > the document. > > Thanks, > > Juergen Q. > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 > NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > Registered in England 2832014 > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Mar 21 19:37:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAN4-0006PD-7s; Wed, 21 Mar 2007 19:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDR0-0002xw-HI for isms@ietf.org; Mon, 19 Mar 2007 04:41:42 -0400 Received: from host2.marvell.com ([65.219.4.2] helo=maili.marvell.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDQv-0001Y7-SC for isms@ietf.org; Mon, 19 Mar 2007 04:41:42 -0400 Received: from rdlnexch03.marvell.com (rdlnexch03.marvell.com [10.6.1.22]) by maili.marvell.com (Postfix) with ESMTP id B63751DCEE for ; Mon, 19 Mar 2007 01:41:36 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Mar 2007 10:40:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding SNMPv3 engine-id discovery process Thread-Index: AcdqAcywUT40rzadRsusgB1gUttdawAAFqSA From: "Tammy Alper" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 X-Mailman-Approved-At: Wed, 21 Mar 2007 19:37:33 -0400 Cc: Subject: [Isms] Question regarding SNMPv3 engine-id discovery process X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2137894009==" Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2137894009== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76A02.5219A4B3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76A02.5219A4B3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Hello, I have a question regarding the SNMPv3 engine-id discovery process: Suppose an SNMP engine wants to discover a remote engine-id value, for the purpose of sending an Inform message to the remote engine. After sending the discovery packet to the requested target and upon=20 receiving an incoming packet: Should the (UDP) port also be used (in addition to IP address) for=20 matching response to the request in this case? In other words - when a cache is used to store remote engine-ids information, should the mapping be of the form: engine-id --> ip-address or=20 engine-id --> ip-address, UDP port =20 In case the SNMP engine supports second option, if the remote engine-id sends a response to the discovery packet from a port different from the port on which it got the request, the SNMP engine will ignore the response and the discovery process will fail. Hence the importance of interoperability in=20 this case.=20 =20 Thank you Tammy Alper =20 ------_=_NextPart_001_01C76A02.5219A4B3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 =

 

Hello,

I have a question regarding the SNMPv3 engine-id discovery = process:

Suppose an SNMP engine wants to discover a remote engine-id = value,

for the purpose of sending an Inform message to the remote = engine.

After sending the discovery packet to the requested target and upon =

receiving an incoming packet:

Should the (UDP) port also be used (in addition to IP address) for =

matching response to the request in this case?

In other words – when a cache is used to store remote engine-ids = information,

should the mapping be of the form:      engine-id = à ip-address        or =

    &nbs= p;            = ;            =             &= nbsp;           &n= bsp;  engine-id à ip-address, UDP port

 

In case the SNMP engine supports second option, if the remote = engine-id

sends a response to the discovery packet from a port different from the = port

on which it got the request, the SNMP engine will ignore the response = and

the discovery process will fail. Hence the importance of interoperability in =

this case. =

 

Thank = you

Tammy = Alper

 

------_=_NextPart_001_01C76A02.5219A4B3-- --===============2137894009== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============2137894009==-- From isms-bounces@lists.ietf.org Thu Mar 22 08:06:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUM3k-0000FI-Tr; Thu, 22 Mar 2007 08:06:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUM3k-0007ya-C1 for isms@ietf.org; Thu, 22 Mar 2007 08:06:24 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULyj-0002aj-Ja for isms@ietf.org; Thu, 22 Mar 2007 08:01:14 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2MC13j6019450; Thu, 22 Mar 2007 07:01:13 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 07:00:56 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 13:00:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Question regarding SNMPv3 engine-id discovery process Date: Thu, 22 Mar 2007 13:00:35 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Question regarding SNMPv3 engine-id discovery process Thread-Index: AcdqAcywUT40rzadRsusgB1gUttdawAAFqSAAJ2uMTA= References: From: "Wijnen, Bert \(Bert\)" To: "Tammy Alper" , X-OriginalArrivalTime: 22 Mar 2007 12:00:54.0665 (UTC) FILETIME=[BE861790:01C76C79] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Inline=20 > -----Original Message----- > From: Tammy Alper [mailto:tammyi@marvell.com]=20 > Sent: maandag 19 maart 2007 9:41 > To: isms@ietf.org > Subject: [Isms] Question regarding SNMPv3 engine-id discovery process >=20 > Hello, >=20 > I have a question regarding the SNMPv3 engine-id discovery process: > Suppose an SNMP engine wants to discover a remote engine-id value, > for the purpose of sending an Inform message to the remote engine. >=20 > After sending the discovery packet to the requested target and upon=20 > receiving an incoming packet: >=20 > Should the (UDP) port also be used (in addition to IP address) for=20 > matching response to the request in this case? >=20 > In other words - when a cache is used to store remote=20 > engine-ids information, >=20 > should the mapping be of the form: engine-id -> ip-address > or engine-id -> ip-address, UDP port >=20 I myself would save it WITH the UDP port included. However, and SNMP engine MIGHT be listening to multiple UDP and/or TCP ports, in which case multiple entries can be stored in your cache. > =20 >=20 > In case the SNMP engine supports second option, if the remote=20 > engine-id sends a response to the discovery packet from a port=20 > different from the port on which it got the request, the SNMP > engine will ignore the response and the discovery process will > fail. Hence the importance of interoperability in this case.=20 >=20 Yep... that is possible.=20 I don't think (but would have to go search if I am correct)=20 we have specified this detail in our documents. A possible solution is, that - you send a GET to Ipadddress, port nnn - you get response from same Ipaddress, port mmmm So you could store in your cache both port numbers. Hope this helps. Bert > =20 >=20 > Thank you >=20 > Tammy Alper >=20 Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Mar 22 09:16:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN97-0006yR-3P; Thu, 22 Mar 2007 09:16:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN96-0006pP-KG for isms@ietf.org; Thu, 22 Mar 2007 09:16:00 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMxK-0001Bq-Uj for isms@ietf.org; Thu, 22 Mar 2007 09:03:53 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2MD3MR9011981; Thu, 22 Mar 2007 08:03:28 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 08:03:22 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 14:03:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2007 14:03:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do Informs work Thread-Index: AcXKv5Lvi0oWWmkPTj+5xhkNa5y8Fmhv9bzQ From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 22 Mar 2007 13:03:20.0691 (UTC) FILETIME=[77544C30:01C76C82] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: Subject: [Isms] Do Informs work X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Juergen asked me to check if INFORMS work, since this was raised as a possible problem/issue. I have reread Jeff Case's comments a few times, but it is unclear as to where he thinks it cannot work. There are tow things I focused on, based on the Jeff's message, Jeff wrote: > 2. i mention this because the experience with the project > causes me to question one of the draft's fundamental > tenets -- that you can do what you want to do without being > forced to compromise anything in arch, v3mp, and/or usm >=20 > in particular, while your design probably works flawlessly for > gets and sets, and might work for traps as well, it would > be helpful if you could explain to me how informs work in > a way that is consistent with the above specs > (yes, i read and reread page 15 several times including the > waffle words found therein but maybe i am just dense and/or > missed something somewhere else) >=20 So the 2 things that I used as hints are: a). Can we do what we want to do without being forced to compromise anything in arch, v3mp, and/or usm b). Is page 15 causing trouble. This was page 15 in rev 05, and so I take it to be section: 3.3.1. Session Establishment Requirements W.r.t. point b), I have now also reread that secsion a few times, and indeed, I am not sure what that section is telling me. It is=20 saying things that I can't prove are wrong, but it also is not clear to me what it wants to tell me. W.r.t. point a), I went through the 3411, 3412 and 3414 documents and checked as much as I could why a GET/SET would work flawlessly and an why an INFORM would fail. I cannot find it and prove that it will not work. But I did find that the one thing that we CHANGE for INFORMs is that we are fidddling with the AUTHORITATIVE securityEngineID. In the USM model, we extract the authoritative EngineID from the securityParameters in the SNMPv3 message.=20 In the TMSM and transport-security-model, we do not extract it from the SNMPv3 message at all, we just SET it to the engineID of the receiving engine, as per sect 5.2, point 1) of draft-ietf-isms-transport-security-model-03.txt. If it is just security-model-related issue (some are claiming that we only need/use that for the time sync), then I believe our security experts have told us it is not an issue. BUT... the question still is if it is indeed ONLY a security-model related issue. After all, we do pass a securityEngineID around in the various ASIs outside of the securityModel. the ASI lists the paramter as: OUT securityEngineID -- authoritative SNMP entity so the "authoritative seems to have meaning outside of the securityModel. WE asked Steve Waldbusser (some 1.5 year ago) if he remembered why this was so important. I have included below Steve's posting about the topic from oktober 2005. Specifically the last para in his posting states: I haven't been following your discussion so I might be wrong about the=20 implications, but it seems to me that the implication is that the notion=20 of authoritative is really a snmpv3 notion and not just a USM notion. I hope this helps in our discussions this afternoon. If Steve reads this, maybe he can also chime in. If Jeff Case (or one of his employees or close friends) reads this,=20 maybe he can chime in too (or his employees/friends can motivate him to chime in). Bert -----Original Message----- From: isms-bounces@lists.ietf.org=20 [mailto:isms-bounces@lists.ietf.org]On Behalf Of Steve Waldbusser Sent: Thursday, October 06, 2005 05:13 To: isms@ietf.org Subject: Re: [Isms] authoritative =09 =09 =09 David H. and Bert asked me to give some background on this because I=20 represented one end of a long debate on this issue about 10 years ago. =09 My point back then was that it is very important for responders to be=20 authoritative (as opposed to initiators being authoritative) =09 In this type of communication, one end is deemed authoritative and=20 typically has keys stored in long-term storage. The other end either=20 gets the key from a human or has a "cached" copy of the key (I say=20 "cached" because in the event the authoritative end says the key is=20 wrong, it is simply discarded at which point the usual fallback is to=20 prompt the user for the correct key). =09 We are very accustomed to the situation where the responder is=20 authoritative and I guess we don't give it much thought. A=20 transaction=20 initiated by a user asks the user for the key and sends it. If the=20 responder says the key is wrong, the user is prompted for a=20 new one. If=20 the transaction is initiated by unattended software, the key=20 must be cached. =09 But imagine the case if the initiator was authoritative. Then the=20 responder must be the end with the human and/or the cached=20 key. When a=20 request arrives at the responder, a human can't react quickly=20 enough to=20 a prompt to type the key within the retransmit period so this doesn't=20 work (and there may not be a human or the right human sitting at the=20 responder anyway). So basically we are forced to cache the=20 key. That's=20 not so bad until we ask which keys are we going to cache?=20 Unfortunately,=20 one answer is *all of them*. If there are 1000 potential initiators each=20 with 10 users, then I have to cache all 10,000 keys because only the=20 initiators will know if they ever have any intention of sending me a=20 transaction and I need to be prepared in case they do. An=20 alternative is=20 to treat it as a provisioning task: when I configure a system to=20 initiate transactions, I must load the key into all systems=20 that I plan=20 to communicate with which is a burden best avoided. Plus it=20 seems that=20 having all of those keys floating around might not be in the best=20 interests of security. =09 To summarize, making the initiator authoritative means either: - a massive configuration of all possible initiators in all possible=20 responders; or, - an additional, expensive provisioning step for setting up a new=20 initiator (or even if I'm just adding a new communications=20 target for an=20 existing initiator). =09 Most apps (email, fileshare, web, ssh) follow the "responder is=20 authoritative" model. I can't think of any exceptions. =09 I haven't been following your discussion so I might be wrong=20 about the=20 implications, but it seems to me that the implication is that=20 the notion=20 of authoritative is really a snmpv3 notion and not just a USM notion. =09 =09 Steve =09 =09 =09 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms =09 =20 =09 =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms