From isms-bounces@lists.ietf.org Sun Jul 02 16:14:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx8Kr-0006xG-IC; Sun, 02 Jul 2006 16:14:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx8Kq-0006xB-J7 for isms@ietf.org; Sun, 02 Jul 2006 16:14:28 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx8Ko-0007bo-4q for isms@ietf.org; Sun, 02 Jul 2006 16:14:28 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id E46A555CE0 for ; Sun, 2 Jul 2006 22:14:24 +0200 (CEST) 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 04833-04; Sun, 2 Jul 2006 22:14:22 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 1B4E155D11; Sun, 2 Jul 2006 22:14:21 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id E5E6D77F5C0; Sun, 2 Jul 2006 22:14:18 +0200 (CEST) Date: Sun, 2 Jul 2006 22:14:18 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Subject: Re: [Isms] SNMP "access control" terminology Message-ID: <20060702201418.GA4772@boskop.local> Mail-Followup-To: isms@ietf.org References: <30C4DD888E6F3477C975C557@sirius.fac.cs.cmu.edu> <068601c69ae1$72d0e650$0400a8c0@china.huawei.com> <20060630221407.GA1652@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060630221407.GA1652@boskop.local> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 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 Sat, Jul 01, 2006 at 12:14:07AM +0200, Juergen Schoenwaelder wrote: > On Wed, Jun 28, 2006 at 02:34:10PM -0400, David Harrington wrote: > > > A little history: > > > > The processIncomingMsg() ASI lacks the parameters to pass the > > transportAddress information from an incoming message into the > > security model. Wonder why? It was not an oversight. > > > > During the discussions of SNMPv2 and SNMPv3 designs, there was a > > persistent request by operators for support of an approach frequently > > used as an authorization mechanism. This was the practice of only > > allowing certain IP addresses (e.g. from the NOC) to perform SNMP at a > > device. > > > > This was deliberately excluded from the design of SNMPv3. The > > authentication and the authorization aspects of that approach are much > > weaker than the authentication provided by USM and the authorization > > provided by VACM. SNMPv3 design exlicitly separates authentication of > > the principal, and authorization to perform SNMP operations. There is > > no authorization implied by the authentication of a principal. > > So how do you think snmpCommunityTransportTag as defined in RFC 3587 > fits into the picture? I believe this object does authorization by > matching IP addresses. And the way it is described, this happens in > the message processing model (processIncomingMsg ASI, see RFC 3587 > section 5.2.1). Perhaps this RFC is wrong according to the > architecture (or is the architecture wrong? ;-) > > You like to see authorization in the ACM. I think authorization does > not really exist as a concept - except perhaps in RFC 3587. I got the RFC number wrong - I was referring to RFC 3584 and not RFC 3587. Sorry for the confusion. /js -- Juergen Schoenwaelder International 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 Mon Jul 03 01:39:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxH9r-0004wM-FX; Mon, 03 Jul 2006 01:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxH9q-0004wH-E6 for isms@ietf.org; Mon, 03 Jul 2006 01:39:42 -0400 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxH9p-0006wL-7I for isms@ietf.org; Mon, 03 Jul 2006 01:39:42 -0400 Received: from h-68-166-38-64.snvacaid.dynamic.covad.net ([68.166.38.64] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FxH9o-0003h7-00 for isms@ietf.org; Mon, 03 Jul 2006 01:39:40 -0400 Message-ID: <001601c69e63$24a23940$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <30C4DD888E6F3477C975C557@sirius.fac.cs.cmu.edu><068601c69ae1$72d0e650$0400a8c0@china.huawei.com><20060630221407.GA1652@boskop.local> <20060702201418.GA4772@boskop.local> Subject: Re: [Isms] SNMP "access control" terminology Date: Sun, 2 Jul 2006 22:40:02 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 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 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Sunday, July 02, 2006 1:14 PM > Subject: Re: [Isms] SNMP "access control" terminology ... > > So how do you think snmpCommunityTransportTag as defined in RFC 3587 > > fits into the picture? I believe this object does authorization by > > matching IP addresses. And the way it is described, this happens in > > the message processing model (processIncomingMsg ASI, see RFC 3587 > > section 5.2.1). Perhaps this RFC is wrong according to the > > architecture (or is the architecture wrong? ;-) > > > > You like to see authorization in the ACM. I think authorization does > > not really exist as a concept - except perhaps in RFC 3587. > > I got the RFC number wrong - I was referring to RFC 3584 and not RFC > 3587. Sorry for the confusion. ... The function of snmpCommunityTransportTag is to to provide a bridge of sorts between the SNMPv1/SNMPv2c world and the SNMPv3 world. That it might exhibit some discrepancies from the SNMPv3 architecture is not surprising, given that it processes incompatible message wrappers. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 03 02:18:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxHlf-0002ak-P9; Mon, 03 Jul 2006 02:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxHle-0002af-SD for isms@ietf.org; Mon, 03 Jul 2006 02:18:46 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxHlc-0001mN-Cs for isms@ietf.org; Mon, 03 Jul 2006 02:18:46 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 796E655F00; Mon, 3 Jul 2006 08:18:43 +0200 (CEST) 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 30300-07; Mon, 3 Jul 2006 08:18:41 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 8A1B155EF8; Mon, 3 Jul 2006 08:18:40 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 921B677F9E0; Mon, 3 Jul 2006 08:18:38 +0200 (CEST) Date: Mon, 3 Jul 2006 08:18:38 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] SNMP "access control" terminology Message-ID: <20060703061838.GA5200@boskop.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <20060702201418.GA4772@boskop.local> <001601c69e63$24a23940$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001601c69e63$24a23940$6501a8c0@oemcomputer> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Sun, Jul 02, 2006 at 10:40:02PM -0700, Randy Presuhn wrote: > > From: "Juergen Schoenwaelder" > > To: > > Sent: Sunday, July 02, 2006 1:14 PM > > Subject: Re: [Isms] SNMP "access control" terminology > ... > > > So how do you think snmpCommunityTransportTag as defined in RFC 3587 > > > fits into the picture? I believe this object does authorization by > > > matching IP addresses. And the way it is described, this happens in > > > the message processing model (processIncomingMsg ASI, see RFC 3587 > > > section 5.2.1). Perhaps this RFC is wrong according to the > > > architecture (or is the architecture wrong? ;-) > > > > > > You like to see authorization in the ACM. I think authorization does > > > not really exist as a concept - except perhaps in RFC 3587. > > > > I got the RFC number wrong - I was referring to RFC 3584 and not RFC > > 3587. Sorry for the confusion. > ... > > The function of snmpCommunityTransportTag is to to provide a bridge > of sorts between the SNMPv1/SNMPv2c world and the SNMPv3 world. > That it might exhibit some discrepancies from the SNMPv3 architecture > is not surprising, given that it processes incompatible message wrappers. Sure. But the point is that (a) a clean architecture and the real world must align reasonably well to be useful and (b) that I consider this IP address filtering in the community-based security model as a kind of authorization step. You simply don't get into the SNMP engine if this authorization step fails, regardless what VACM later on would allow or disallow. While having no authorization and having no access right might practically mean the same thing, they are still different in terms of how far you get into the system and so far I always considered authorization as something that happens at the entrance. Once you have passed authorization and you are inside, access control controls what you can do. While I might be wrong with my world model, I see the following potential three usages of RADIUS in an ISMS environment: a) authentication backend for password/keyboard-interactive (transparent for ISMS as far as I can tell, easy) b) authorization (once authenticated) (easy when you use RADIUS for authentication, difficult when you use public keys or kerberos since in this case authorization is different from authentication and RADIUS does not seem to like it (and I still have to understand what the difference between RADIUS and DIAMETER is in this aspect since the later seems to like it better)) c) mapping of security names to group names (roles) (requires to call radius within VACM or cached information must be passed to VACM from somewhere, requires to work out how such dynamic information coexists with provisioned VACM security to group mappings) I think this is what discusses. /js -- Juergen Schoenwaelder International 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 Mon Jul 03 03:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxIel-0007vF-MY; Mon, 03 Jul 2006 03:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxIel-0007vA-2r for isms@ietf.org; Mon, 03 Jul 2006 03:15:43 -0400 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxIei-0006XR-Rb for isms@ietf.org; Mon, 03 Jul 2006 03:15:43 -0400 Received: from h-68-166-38-64.snvacaid.dynamic.covad.net ([68.166.38.64] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FxIei-0000GY-00 for isms@ietf.org; Mon, 03 Jul 2006 03:15:40 -0400 Message-ID: <000a01c69e70$96871a00$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20060702201418.GA4772@boskop.local> <001601c69e63$24a23940$6501a8c0@oemcomputer> <20060703061838.GA5200@boskop.local> Subject: Re: [Isms] SNMP "access control" terminology Date: Mon, 3 Jul 2006 00:16:21 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Sunday, July 02, 2006 11:18 PM > Subject: Re: [Isms] SNMP "access control" terminology ... > a) authentication backend for password/keyboard-interactive > (transparent for ISMS as far as I can tell, easy) > > b) authorization (once authenticated) > (easy when you use RADIUS for authentication, difficult when you > use public keys or kerberos since in this case authorization is > different from authentication and RADIUS does not seem to like > it (and I still have to understand what the difference between > RADIUS and DIAMETER is in this aspect since the later seems to > like it better)) Does the distinction between (a) and (b) matter? It's a question of what attacks would be possible by the set of users who could be authenticated but not "authorized" who would somehow be able to cause mischief despite being prevented from "doing" anything by the access control model. I think this boils down to DoS attacks, and would perhaps be more interesting than in a USM world if sessions consumed substantial resources. > c) mapping of security names to group names (roles) > (requires to call radius within VACM or cached information must be > passed to VACM from somewhere, requires to work out how such > dynamic information coexists with provisioned VACM security to > group mappings) > > I think this is what > discusses. ... Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 03 05:34:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKok-0000FA-70; Mon, 03 Jul 2006 05:34:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKoj-0000F0-6K for isms@ietf.org; Mon, 03 Jul 2006 05:34:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxJbE-00034w-HU for isms@ietf.org; Mon, 03 Jul 2006 04:16:08 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FxJQk-0008Rm-U5 for isms@ietf.org; Mon, 03 Jul 2006 04:05:21 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D2C6953F45; Mon, 3 Jul 2006 10:05:15 +0200 (CEST) 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 05389-09; Mon, 3 Jul 2006 10:05:13 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id D5B3D55BC8; Mon, 3 Jul 2006 10:05:11 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id C9B2F77FA6C; Mon, 3 Jul 2006 10:05:09 +0200 (CEST) Date: Mon, 3 Jul 2006 10:05:09 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] SNMP "access control" terminology Message-ID: <20060703080509.GA5419@boskop.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <20060702201418.GA4772@boskop.local> <001601c69e63$24a23940$6501a8c0@oemcomputer> <20060703061838.GA5200@boskop.local> <000a01c69e70$96871a00$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000a01c69e70$96871a00$6501a8c0@oemcomputer> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: -1.1 (-) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Mon, Jul 03, 2006 at 12:16:21AM -0700, Randy Presuhn wrote: > > a) authentication backend for password/keyboard-interactive > > (transparent for ISMS as far as I can tell, easy) > > > > b) authorization (once authenticated) > > (easy when you use RADIUS for authentication, difficult when you > > use public keys or kerberos since in this case authorization is > > different from authentication and RADIUS does not seem to like > > it (and I still have to understand what the difference between > > RADIUS and DIAMETER is in this aspect since the later seems to > > like it better)) > > Does the distinction between (a) and (b) matter? It's a question > of what attacks would be possible by the set of users who could > be authenticated but not "authorized" who would somehow be able > to cause mischief despite being prevented from "doing" anything by > the access control model. I think this boils down to DoS attacks, > and would perhaps be more interesting than in a USM world if > sessions consumed substantial resources. If RADIUS is used for both (a) and (b), my understanding (please correct me) is that you get a negative reponse regardless whether authentication or authorization fails. On the RADIUS server, you might however be able to authenticate the user but then decide that this user is not allowed to talk SNMP to a given router. Similarily, if you use Kerberos for authentication, then your authentication might be successful because you are a known entity in the Kerberos realm. But the fact that you are authenticated does not necessarily imply the authorization to talk to an SNMP agent on a given router. In the USM world, the underlying assumption has been that successful authentication implies authorization to talk to the managed device and you have to delete an USM user to essentially deny authorization to talk to the managed device. With RADIUS in place, you can drop the authorization without deleting the authentication for a given user which makes sense since the same user may very well be authenticated and authorized to use other services. Sure, you can try to configure the ACM to ensure that all users who can be authenticated (might be a large number) and who are not authorized to use the service can't get any service. But practically speaking from my system administration experience, I would prefer to drop unauthorized users as early as possible (and not only because of DOS attacks and resource usage but more practically speaking also for the risks associated with software bugs and not-as-good ACM configurations that might be around). Again, the text above reflects my yet limited understanding of the RADIUS world and how it fits to ISMS - so if this is not correct or nonsense, please RADIUS folks correct me. /js -- Juergen Schoenwaelder International 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 Mon Jul 03 09:36:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxObB-0000hX-N1; Mon, 03 Jul 2006 09:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyhK-0003jd-2e for isms@ietf.org; Mon, 26 Jun 2006 17:32:46 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyhH-0008Fg-3a for isms@ietf.org; Mon, 26 Jun 2006 17:32:46 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060626213235m1100au7g2e>; Mon, 26 Jun 2006 21:32:35 +0000 From: "David B Harrington" To: Date: Mon, 26 Jun 2006 17:31:21 -0400 Message-ID: <010701c69967$de66ad30$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0108_01C69946.57550D30" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaZZ3uFBTGKn+uOS8yAXwnUcowBmw== X-Spam-Score: 0.2 (/) X-Scan-Signature: 75ba89d3106c5fe46e029d70ca46d4ff X-Mailman-Approved-At: Mon, 03 Jul 2006 09:36:24 -0400 Cc: Subject: [Isms] Draft-ietf-isms-secshell-04.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 This is a multi-part message in MIME format. ------=_NextPart_000_0108_01C69946.57550D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This seems to be slow at being announced. For those that want to see it in advance, here is the latest revision of SSHSM, hopefully soon to be published by the I-D editor. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_0108_01C69946.57550D30 Content-Type: text/plain; name="draft-ietf-isms-secshell-04.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-secshell-04.txt" =0A= =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Standards Track J. Salowey=0A= Expires: December 25, 2006 Cisco Systems=0A= June 23, 2006=0A= =0A= =0A= Secure Shell Security Model for SNMP=0A= draft-ietf-isms-secshell-04.txt=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 December 25, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= This memo describes a Security Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol within a=0A= Transport Mapping.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 1]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 4=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 7=0A= 3. How SSHSM Fits into the TMSM Architecture . . . . . . . . . . 8=0A= 3.1. Security Capabilities of this Model . . . . . . . . . . . 9=0A= 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 3.1.2. SSHSM Sessions . . . . . . . . . . . . . . . . . . . . 11=0A= 3.1.3. Authentication Protocol . . . . . . . . . . . . . . . 11=0A= 3.1.4. Privacy Protocol . . . . . . . . . . . . . . . . . . . 12=0A= 3.1.5. Protection against Message Replay, Delay and=0A= Redirection . . . . . . . . . . . . . . . . . . . . . 12=0A= 3.1.6. Security Protocol Requirements . . . . . . . . . . . . 12=0A= 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 13=0A= 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14=0A= 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15=0A= 4.1. SNMPv3 Message Fields . . . . . . . . . . . . . . . . . . 15=0A= 4.1.1. msgGlobalData . . . . . . . . . . . . . . . . . . . . 17=0A= 4.1.2. msgSecurityParameters . . . . . . . . . . . . . . . . 17=0A= 4.2. Passing Security Parameters . . . . . . . . . . . . . . . 17=0A= 4.2.1. tmStateReference . . . . . . . . . . . . . . . . . . . 17=0A= 4.2.2. securityStateReference . . . . . . . . . . . . . . . . 18=0A= 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19=0A= 5.1. Generating an Outgoing SNMP Message . . . . . . . . . . . 19=0A= 5.2. MPSP for an Outgoing Message . . . . . . . . . . . . . . . 20=0A= 5.2.1. MPSP Procedures . . . . . . . . . . . . . . . . . . . 22=0A= 5.3. TMSP for an Outgoing Message . . . . . . . . . . . . . . . 23=0A= 5.3.1. TMSP Procedures . . . . . . . . . . . . . . . . . . . 23=0A= 5.4. Processing an Incoming SNMP Message . . . . . . . . . . . 24=0A= 5.4.1. TMSP for an Incoming Message . . . . . . . . . . . . . 24=0A= 5.5. Prepare Data Elements from Incoming Messages . . . . . . . 25=0A= 5.6. MPSP for an Incoming Message . . . . . . . . . . . . . . . 25=0A= 5.7. Establishing a Session . . . . . . . . . . . . . . . . . . 27=0A= 5.8. Closing a Session . . . . . . . . . . . . . . . . . . . . 29=0A= 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 29=0A= 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 30=0A= 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 30=0A= 6.3. The sshsmStats Subtree . . . . . . . . . . . . . . . . . . 30=0A= 6.4. The sshsmsSession Subtree . . . . . . . . . . . . . . . . 30=0A= 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30=0A= 6.5.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 30=0A= 6.5.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 30=0A= 6.5.3. Relationship to the TMSM-MIB . . . . . . . . . . . . . 31=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 2]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 6.5.4. MIB Modules Required for IMPORTS . . . . . . . . . . . 31=0A= 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 31=0A= 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35=0A= 8.1. noAuthPriv . . . . . . . . . . . . . . . . . . . . . . . . 35=0A= 8.2. skipping public key verification . . . . . . . . . . . . . 36=0A= 8.3. the 'none' MAC algorithm . . . . . . . . . . . . . . . . . 36=0A= 8.4. MIB module security . . . . . . . . . . . . . . . . . . . 36=0A= 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37=0A= 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38=0A= 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38=0A= 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38=0A= 11.2. Informative References . . . . . . . . . . . . . . . . . . 40=0A= Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 40=0A= A.1. Closed Issues . . . . . . . . . . . . . . . . . . . . . . 40=0A= Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 45=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 3]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo describes a Security Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol within a=0A= Transport Mapping Security Model extension [I-D.ietf-isms-tmsm]. The=0A= security model specified in this memo is referred to as the Secure=0A= Shell Security Model (SSHSM).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Security Model for SNMP.=0A= =0A= It is important to understand the SNMP architecture and the=0A= terminology of the architecture to understand where the Security=0A= Model described in this memo fits into the architecture and interacts=0A= with other subsystems within the architecture.=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= The terms "manager" and "agent" are not used in this document,=0A= because in the RFC 3411 architecture, all SNMP entities have the=0A= capability of acting as either manager or agent or both depending on=0A= the SNMP applications included in the engine. Where distinction is=0A= required, the application names of Command Generator, Command=0A= Responder, Notification Generator, Notification Responder, and Proxy=0A= Forwarder are used. See "SNMP Applications" [RFC3413] for further=0A= information.=0A= =0A= Throughout this document, the terms "client" and "server" are used to=0A= refer to the two ends of the SSH transport connection. The client=0A= actively opens the SSH connection, and the server passively listens=0A= for the incoming SSH connection. Either SNMP entity may act as=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 4]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= client or as server, as discussed further below.=0A= =0A= While SSH and USM frequently refer to a user, the terminology used in=0A= RFC3411 [RFC3411] and in this memo is "principal". A principal is=0A= the "who" on whose behalf services are provided or processing takes=0A= place. A principal can be, among other things, an individual acting=0A= in a particular role; a set of individuals, with each acting in a=0A= particular role; an application or a set of applications; and=0A= combinations thereof.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119]=0A= =0A= Sections requiring further editing are identified by [todo] markers=0A= in the text. Points requiring further WG research and discussion are=0A= identified by [discuss] markers in the text.=0A= =0A= 1.3. Modularity=0A= =0A= The reader is expected to have read and understood the description of=0A= the SNMP architecture, as defined in [RFC3411],and the TMSM=0A= architecture extension specified in "Transport Mapping Security Model=0A= (TMSM) Architectural Extension for the Simple Network Management=0A= Protocol" [I-D.ietf-isms-tmsm], which enables the use of external=0A= "lower layer" protocols to provide message security, tied into the=0A= SNMP architecture through the transport mapping subsystem. One such=0A= external protocol is the Secure Shell protocol [RFC4251].=0A= =0A= This memo describes the Secure Shell Security Model for SNMP, a=0A= specific SNMP security model to be used within the SNMP Architecture,=0A= to provide authentication, encryption, and integrity checking of SNMP=0A= messages.=0A= =0A= In keeping with the RFC 3411 design decisions to use self-contained=0A= documents, this memo includes the elements of procedure plus=0A= associated MIB objects which are needed for processing the Secure=0A= Shell Security Model for SNMP. These MIB objects SHOULD not be=0A= referenced in other documents. This allows the Secure Shell Security=0A= Model for SNMP to be designed and documented as independent and self-=0A= contained, having no direct impact on other modules, and allowing=0A= this module to be upgraded and supplemented as the need arises, and=0A= to move along the standards track on different time-lines from other=0A= modules.=0A= =0A= This modularity of specification is not meant to be interpreted as=0A= imposing any specific requirements on implementation.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 5]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 1.4. Motivation=0A= =0A= Version 3 of the Simple Network Management Protocol (SNMPv3) added=0A= security to the previous versions of the protocol. The User Security=0A= Model (USM) [RFC3414] was designed to be independent of other=0A= existing security infrastructures, to ensure it could function when=0A= third party authentication services were not available, such as in a=0A= broken network. As a result, USM typically utilizes a separate user=0A= and key management infrastructure. Operators have reported that=0A= deploying another user and key management infrastructure in order to=0A= use SNMPv3 is a reason for not deploying SNMPv3 at this point in=0A= time.=0A= =0A= This memo describes a security model that will make use of the=0A= existing and commonly deployed Secure Shell security infrastructure.=0A= It is designed to meet the security and operational needs of network=0A= administrators, maximize usability in operational environments to=0A= achieve high deployment success and at the same time minimize=0A= implementation and deployment costs to minimize the time until=0A= deployment is possible.=0A= =0A= The work will address the requirement for the SSH client to=0A= authenticate the SSH server, for the SSH server to authenticate the=0A= SSH client, and how SNMP can make use of the authenticated identities=0A= in message authentication and access control.=0A= =0A= The work will include the ability to use any of the client=0A= authentication methods described in "SSH Authentication Protocol"=0A= [RFC4252] - public key, password, and host-based. Local accounts may=0A= be supported through the use of the public key, host-based or=0A= password based mechanisms. The password based mechanism allows for=0A= integration with deployed password infrastructure such as AAA servers=0A= using the RADIUS protocol [RFC2865]. SSHSM SHOULD be able to take=0A= advantage of other defined authentication mechanism such as those=0A= defined in [RFC4462] and future mechanisms such as those that make=0A= use of X.509 certificate credentials. This will allow SSHSM to=0A= utilize client authentication and key exchange mechanisms which=0A= support different security infrastructures and provide different=0A= security properties.=0A= =0A= It is desirable to use mechanisms that could unify the approach for=0A= administrative security for SNMPv3 and Command Line interfaces (CLI)=0A= and other management interfaces. The use of security services=0A= provided by Secure Shell is the approach commonly used for the CLI,=0A= and is the approach being adopted for use with NETCONF=0A= [I-D.ietf-netconf-ssh]. This memo describes a method for invoking=0A= and running the SNMP protocol within a Secure Shell (SSH) session as=0A= an SSH subsystem.=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 6]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= This memo describes how SNMP can be used within a Secure Shell (SSH)=0A= session, using the SSH connection protocol [RFC4254] over the SSH=0A= transport protocol, using SSH user-auth [RFC4252] for authentication.=0A= =0A= There are a number of challenges to be addressed to map Secure Shell=0A= authentication method parameters into the SNMP architecture so that=0A= SNMP continues to work without any surprises. These are discussed in=0A= detail below.=0A= =0A= 1.5. Constraints=0A= =0A= The design of this SNMP Security Model is also influenced by the=0A= following constraints:=0A= 1. When the requirements of effective management in times of network=0A= stress are inconsistent with those of security, the design of=0A= this model gives preference to effective management.=0A= 2. In times of network stress, the security protocol and its=0A= underlying security mechanisms SHOULD NOT depend upon the ready=0A= availability of other network services (e.g., Network Time=0A= Protocol (NTP) or AAA protocols).=0A= 3. When the network is not under stress, the security model and its=0A= underlying security mechanisms MAY depend upon the ready=0A= availability of other network services.=0A= 4. It may not be possible for the security model to determine when=0A= the network is under stress.=0A= 5. A security model should require no changes to the SNMP=0A= architecture.=0A= 6. A security model should require no changes to the underlying=0A= security protocol.=0A= =0A= 2. The Secure Shell Protocol=0A= =0A= SSH is a protocol for secure remote login and other secure network=0A= services over an insecure network. It consists of three major=0A= components:=0A= o The Transport Layer Protocol [RFC4253] provides server=0A= authentication, and message confidentiality and integrity. It may=0A= optionally also provide compression. The transport layer will=0A= typically be run over a TCP/IP connection, but might also be used=0A= on top of any other reliable data stream.=0A= o The User Authentication Protocol [RFC4252] authenticates the=0A= client-side principal to the server. It runs over the transport=0A= layer protocol.=0A= o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel=0A= into several logical channels. It runs over the transport after=0A= successfully authenticating the principal.=0A= =0A= The client sends a service request once a secure transport layer=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 7]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= connection has been established. A second service request is sent=0A= after client authentication is complete. This allows new protocols=0A= to be defined and coexist with the protocols listed above.=0A= =0A= The connection protocol provides channels that can be used for a wide=0A= range of purposes. Standard methods are provided for setting up=0A= secure interactive shell sessions and for forwarding ("tunneling")=0A= arbitrary TCP/IP ports and X11 connections.=0A= =0A= 3. How SSHSM Fits into the TMSM Architecture=0A= =0A= SSH is a security layer which is plugged into the TMSM architecture=0A= extension between the underlying transport layer and the message=0A= dispatcher [RFC3411].=0A= =0A= The SSHSM model will establish an encrypted tunnel between the=0A= transport mappings of two SNMP engines. The sending transport=0A= mapping security model instance encrypts outgoing messages, and the=0A= receiving transport mapping security model instance decrypts the=0A= messages.=0A= =0A= After the transport layer tunnel is established, then SNMP messages=0A= can conceptually be sent through the tunnel from one SNMP message=0A= dispatcher to another SNMP message dispatcher. Once the tunnel is=0A= established, multiple SNMP messages may be able to be passed through=0A= the same tunnel.=0A= =0A= Within an engine, outgoing SNMP messages are passed unencrypted from=0A= the message dispatcher to the transport mapping, and incoming=0A= messages are passed unencrypted from the transport mapping to the=0A= message dispatcher.=0A= =0A= SSHSM follows the TMSM approach, in which the security-model has two=0A= separate areas of security processing - transport-mapping-related=0A= security processing (TMSP) within the transport mapping section of=0A= the dispatcher, and message processor security processing (MPSP)=0A= which happens within the security model subsystem of the message=0A= processor.=0A= =0A= SSHSM security processing will be called from within the Transport=0A= Mapping functionality of an SNMP engine dispatcher to perform the=0A= translation of transport security parameters to/from security-model-=0A= independent parameters. Some SSHSM security processing will also be=0A= performed within a message processing portion of the model, for=0A= compatibility with the ASIs between the RFC 3411 Security Subsystem=0A= and the Message Processing Subsystem.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 8]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 3.1. Security Capabilities of this Model=0A= =0A= 3.1.1. Threats=0A= =0A= The security protocols used in this memo are considered acceptably=0A= secure at the time of writing. However, the procedures allow for new=0A= authentication and privacy methods to be specified at a future time=0A= if the need arises.=0A= =0A= The Secure Shell Security Model provides protection against the=0A= threats identified by the RFC 3411 architecture [RFC3411]:=0A= =0A= 1. Message stream modification - SSHSM provides for verification=0A= that each received SNMP message has not been modified during its=0A= transmission through the network.=0A= 2. Information modification - SSHSM provides for verification that=0A= the contents of each received SNMP message has not been modified=0A= during its transmission through the network, data has not been=0A= altered or destroyed in an unauthorized manner, nor have data=0A= sequences been altered to an extent greater than can occur non-=0A= maliciously.=0A= 3. Masquerade - SSHSM provides for both verification of the identity=0A= of the SSH server and verification of the identity of the SSH=0A= client - the principal on whose behalf a received SNMP message=0A= claims to have been generated. It is not possible to assure the=0A= specific principal that originated a received SNMP message;=0A= rather, it is the principal on whose behalf the message was=0A= originated that is authenticated. SSH provides verification of=0A= the identity of the SSH server through the SSH Transport Protocol=0A= server authentication [RFC4253]=0A= 4. Verification of principal identity is important for use with the=0A= SNMP access control subsystem, to ensure that only authorized=0A= principals have access to potentially sensitive data. The SSH=0A= user identity will be used to map to an SNMP model-independent=0A= securityName for use with SNMP access control.=0A= 5. Authenticating both the SSH server and the SSH client ensures the=0A= authenticity of the SNMP engine that provides MIB data, whether=0A= that engine resides on the server or client side of the=0A= association. Operators or management applications might act upon=0A= the data they receive (e.g., raise an alarm for an operator,=0A= modify the configuration of the device that sent the=0A= notification, modify the configuration of other devices in the=0A= network as the result of the notification, and so on), so it is=0A= important to know that the provider of MIB data is authentic.=0A= 6. Disclosure - SSHSM provides that the contents of each received=0A= SNMP message are protected from disclosure to unauthorized=0A= persons.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 9]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 7. Replay - SSH ensures that cryptographic keys established at the=0A= beginning of the SSH session and stored in the SSH session state=0A= are fresh new session keys generated for each session. These are=0A= used to authenticate and encrypt data, and to prevent replay=0A= across sessions. SSH uses sequence information to prevent the=0A= replay and reordering of messages within a session.=0A= =0A= 3.1.1.1. Data Origin Authentication Issues=0A= =0A= The RFC 3411 architecture recognizes three levels of security:=0A= - without authentication and without privacy (noAuthNoPriv)=0A= - with authentication but without privacy (authNoPriv)=0A= - with authentication and with privacy (authPriv)=0A= =0A= The Secure Shell protocol provides support for encryption and data=0A= integrity. While it is technically possible to support no=0A= authentication and no encryption in SSH it is NOT RECOMMENDED by=0A= [RFC4253].=0A= =0A= SSHSM extracts from SSH the identity of the authenticated principal,=0A= and the type and address associated with an incoming message, and=0A= SSHSM provides this information to SSH for an outgoing message. The=0A= transport layer algorithms used to provide authentication, data=0A= integrity and encryption SHOULD NOT be exposed to the SSHSM layer.=0A= In SNMPv3, we deliberately avoided this and settled for an assertion,=0A= using msgFlags, that auth and priv were applied according to the=0A= rules of the security model. However, SSHSM has no mechanisms by=0A= which it can test whether an underlying SSH connection provides auth=0A= or priv to meet a desired msgFlags setting, so the SSHSM trusts that=0A= the underlying SSH connection has been properly configured to support=0A= security characteristics at least as strong as requested in msgFlags.=0A= =0A= SSH does not understand msgFlags, and SSHSM does not know about the=0A= algorithms or options for the SSH session to open SSH sessions that=0A= match different securityLevels. For interoperability of the trust=0A= assumptions between SNMP engines, an SSHSM-compliant implementation=0A= MUST use an SSH connection that provides authentication, data=0A= integrity and encryption that meets the highest level of SNMP=0A= security (authPriv). Outgoing messages requested by SNMP=0A= applications and specified with a lesser securityLevel (noAuthNoPriv=0A= or authNoPriv) are sent by SSHSM as authPriv securityLevel. Other=0A= security models, where the actual securityLevel applied to the=0A= connection can be determined or controlled, can be used when a lesser=0A= level of security is desired.=0A= =0A= Implementations SHOULD support whatever authentications are provided=0A= by SSH. The security protocols used in [RFC4253] are considered=0A= acceptably secure at the time of writing. However, the procedures=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 10]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= allow for new authentication and privacy methods to be specified at a=0A= future time if the need arises.=0A= =0A= 3.1.2. SSHSM Sessions=0A= =0A= The Secure Shell security model will utilize TMSM sessions, with a=0A= single combination of transportAddress, engineID, securityName,=0A= securityModel, and securityLevel associated with each session. A=0A= TMSM session is associated with state information that is maintained=0A= for its lifetime. All SSHSM sessions will utilize the authPriv=0A= securityLevel, and all incoming SSHSM messages will be treated as=0A= having been delivered through authenticated, integrity-checked, and=0A= encrypted connections.=0A= =0A= SSHSM sessions are opened during the elements of procedure for an=0A= outgoing SNMP message, never during the elements of procedure for an=0A= incoming message. Implementations MAY choose to instantiate sessions=0A= in anticipation of outgoing messages.=0A= =0A= 3.1.2.1. Message security versus session security=0A= =0A= As part of session creation, the client and server entities are=0A= authenticated and authorized access to the session. In addition, as=0A= part of session establishment, cryptographic key material is=0A= exchanged and is then used to control access to the session on a=0A= message by message basis. Messages that fail the basic data origin=0A= authenticaiton/ data integrity checks will be rejected.=0A= =0A= 3.1.3. Authentication Protocol=0A= =0A= SSHSM should support any client authentication mechanism supported by=0A= SSH. This includes the three authentication methods described in the=0A= SSH Authentication Protocol document [RFC4252] - publickey, password,=0A= and host-based.=0A= =0A= The password authentication mechanism allows for integration with=0A= deployed password based infrastructure. It is possible to hand a=0A= password to a service such as RADIUS [RFC2865] or Diameter [RFC3588]=0A= for validation. The validation could be done using the user-name and=0A= user-password attributes. It is also possible to use a different=0A= password validation protocol such as CHAP [RFC1994] or digest=0A= authentication [RFC 2617, draft-ietf-radext-digest-auth-04] to=0A= integrate with RADIUS or Diameter. These mechanisms leave the=0A= password in the clear on the device that is authenticating the=0A= password which introduces threats to the authentication=0A= infrastructure.=0A= =0A= GSSKeyex [RFC4462] provides a framework for the addition of client=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 11]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= authentication mechanisms which support different security=0A= infrastructures and provide different security properties.=0A= Additional authentication mechanisms, such as one that supports X.509=0A= certificates, may be added to SSH in the future.=0A= =0A= 3.1.4. Privacy Protocol=0A= =0A= The Secure Shell Security Model uses the SSH transport layer=0A= protocol, which provides strong encryption, server authentication,=0A= and integrity protection.=0A= =0A= 3.1.5. Protection against Message Replay, Delay and Redirection=0A= =0A= The Secure Shell Security Model uses the SSH transport layer=0A= protocol. SSH uses sequence numbers and integrity checks to protect=0A= against replay and reordering of messages within a connection.=0A= =0A= SSH also provides protection against replay of entire sessions. In a=0A= properly-implemented DH exchange, both sides will generate new random=0A= numbers for each exchange, which means the exchange hash and thus the=0A= encryption and integrity keys will be distinct for every session.=0A= This would prevent capturing an SNMP message and redirecting it to=0A= another SNMP engine.=0A= =0A= Message delay is not as important an issue with SSH as it is with=0A= USM. USM checks the timeliness of messages because it does not=0A= provide session protection or message sequence ordering. The only=0A= delay that would seem to be possible would be to delay the=0A= transmission of all packets from a particular point in a session=0A= since SSH protects the ordering of packets.=0A= =0A= 3.1.6. Security Protocol Requirements=0A= =0A= Modifying the Secure Shell protocol, or configuring it in a=0A= particular manner, may change its security characteristics in ways=0A= that would impact other existing usages. If a change is necessary,=0A= the change should be an extension that has no impact on the existing=0A= usages. This document will describe the use of an SSH subsystem for=0A= SNMP to make SNMP usage distinct from other usages.=0A= =0A= 3.1.6.1. Troubleshooting=0A= =0A= SSHSM will likely not work in conditions where access to the CLI has=0A= stopped working. In situations where SNMP access has to work when=0A= the CLI has stopped working, the use of USM should be considered=0A= instead of SSHSM.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 12]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 3.1.6.2. Coexistence=0A= =0A= The Secure Shell security model can coexist with the USM security=0A= model, the only other currently defined security model.=0A= =0A= RFC3584 describes how to transfer fields between SNMPv3 and SNMPv1/=0A= v2c messages. If necessary, the coexistence of SSHSM with v1/v2c can=0A= be described in a different document. The translation of fields from=0A= SNMPv3 messages will need detailed analysis, since SSHSM does not=0A= fill the msgSecurityParameters the same way as USM.=0A= =0A= 3.1.6.3. Mapping SSH to EngineID=0A= =0A= In the RFC3411 architecture, there are three use cases for an=0A= engineID:=0A= snmpEngineID - RFC3411 includes the SNMP-FRAMEWORK-MIB, which=0A= defines a snmpEngineID object. An snmpEngineID is the unique and=0A= unambiguous identifier of an SNMP engine. Since there is a one-=0A= to-one association between SNMP engines and SNMP entities, it also=0A= uniquely and unambiguously identifies the SNMP entity within an=0A= administrative domain.=0A= contextEngineID - Management information resides at an SNMP entity=0A= where a Command Responder Application has local access to=0A= potentially multiple contexts. A Command Responder application=0A= uses a contextEngineID equal to the snmpEngineID of its associated=0A= SNMP engine, and the contextEngineID is included in a scopedPDU to=0A= identify the engine associated with the data contained in the PDU.=0A= securityEngineID - The securityEngineID is used by USM when=0A= performing integrity checking and authentication, to look up=0A= values in the USM tables, and to synchronize "clocks". The=0A= securityEngineID is not needed by SSHSM, since integrity checking=0A= and authentication are handled outside the SNMP engine. The=0A= RFC3411 architecture defines ASIs that include a securityEngineID;=0A= SSHSM should always set the securityEngineID equal to the local=0A= value of snmpEngineID.0 to satisfy the elements of procedure for=0A= generateRequestMsg() defined in RFC3412.=0A= =0A= 3.2. Security Parameter Passing=0A= =0A= Security-model-specific parameters for an incoming message are=0A= determined from the SSH layer by the transport mapping security=0A= processor (TMSP), before the message processing begins. The TMSP=0A= accepts (decrypted) messages from the SSH subsystem, and records the=0A= transport-related information and the security-related information,=0A= including authenticated identity, in a cache referenced by=0A= tmSessionReference, and passes the WholeMsg and the=0A= tmSessionReference to the MPSP (via the dispatcher).=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 13]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= For outgoing messages, the security-model-specific parameters are=0A= gathered by the messaging-security-processor (MPSP) and passed with=0A= the outgoing message to the transport mapping. The MPSP portion of=0A= the security model creates the WholeMsg from its component parts. In=0A= the SSHSM model, an SNMPv3 message is built without any content in=0A= the SecurityParameters field of the message, and the WholeMsg is=0A= passed unencrypted back to the Message Processing Model for=0A= forwarding to the Transport Mapping. The MPSP takes input provided=0A= by the SNMP application, converts that information into suitable=0A= security parameters for SSHSM, and passes these in a cache referenced=0A= by tmSessionReference to the TMSP (via the dispatcher). The TMSP=0A= establishes sessions as needed and passes messages to the SSH=0A= subsystem for processing.=0A= =0A= The cache reference is an additional parameter in the ASIs between=0A= the transport mapping and the messaging security model.=0A= =0A= This approach does create dependencies between a model-specific TMSP=0A= and a corresponding specific MPSP. Passing a model-independent cache=0A= reference as a parameter in an ASI is consistent with the=0A= securityStateReference cache already being passed around in the ASI.=0A= =0A= 3.3. Notifications and Proxy=0A= =0A= SSH connections may be initiated by command generators or by=0A= notification originators. Command generators are frequently operated=0A= by a human, but notification originators frequently are unmanned=0A= automated processes. As a result, it usually will be necessary to=0A= provision authentication credentials on the SNMP engine containing=0A= the notification originator, or use a third party key provider such=0A= as Kerberos, so the engine can successfully authenticate to an engine=0A= containing a notification receiver.=0A= =0A= The SNMP-TARGET-MIB module [RFC3413] contains objects for defining=0A= management targets, including transport domains and addresses and=0A= security parameters, for applications such as notifications and=0A= proxy.=0A= =0A= For SSHSM, transport type and address are configured in the=0A= snmpTargetAddrTable, and the securityModel, securityName, and=0A= securityLevel parameters are configured in the snmpTargetParamsTable.=0A= The default approach is for an administrator to statically=0A= preconfigure this information to identify the targets authorized to=0A= receive notifications or perform proxy.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 14]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 4. Message Formats=0A= =0A= The syntax of an SNMP message using this Security Model adheres to=0A= the message format defined in the version-specific Message Processing=0A= Model document (for example [RFC3412]). At the time of this writing,=0A= there are three defined message formats - SNMPv1, SNMPv2c, and=0A= SNMPv3. SNMPv1 and SNMPv2c have been declared Historic, so this memo=0A= only deals with SNMPv3 messages.=0A= =0A= The processing is compatible with the RFC 3412 primitives,=0A= generateRequestMsg() and processIncomingMsg(), that show the data=0A= flow between the Message Processor and the MPSP.=0A= =0A= 4.1. SNMPv3 Message Fields=0A= =0A= The SNMPv3Message SEQUENCE is defined in [RFC3412] and [RFC3416].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 15]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::=3D BEGIN=0A= =0A= SNMPv3Message ::=3D SEQUENCE {=0A= -- identify the layout of the SNMPv3Message=0A= -- this element is in same position as in SNMPv1=0A= -- and SNMPv2c, allowing recognition=0A= -- the value 3 is used for snmpv3=0A= msgVersion INTEGER ( 0 .. 2147483647 ),=0A= -- administrative parameters=0A= msgGlobalData HeaderData,=0A= -- security model-specific parameters=0A= -- format defined by Security Model=0A= msgSecurityParameters OCTET STRING,=0A= msgData ScopedPduData=0A= }=0A= =0A= HeaderData ::=3D SEQUENCE {=0A= msgID INTEGER (0..2147483647),=0A= msgMaxSize INTEGER (484..2147483647),=0A= =0A= msgFlags OCTET STRING (SIZE(1)),=0A= -- .... ...1 authFlag=0A= -- .... ..1. privFlag=0A= -- .... .1.. reportableFlag=0A= -- Please observe:=0A= -- .... ..00 is OK, means noAuthNoPriv=0A= -- .... ..01 is OK, means authNoPriv=0A= -- .... ..10 reserved, MUST NOT be used.=0A= -- .... ..11 is OK, means authPriv=0A= =0A= msgSecurityModel INTEGER (1..2147483647)=0A= }=0A= =0A= ScopedPduData ::=3D CHOICE {=0A= plaintext ScopedPDU,=0A= encryptedPDU OCTET STRING -- encrypted scopedPDU value=0A= }=0A= =0A= ScopedPDU ::=3D SEQUENCE {=0A= contextEngineID OCTET STRING,=0A= contextName OCTET STRING,=0A= data ANY -- e.g., PDUs as defined in [RFC3416]=0A= }=0A= END=0A= =0A= =0A= The following describes how SSHSM treats certain fields in the=0A= message:=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 16]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 4.1.1. msgGlobalData=0A= =0A= msgGlobalData is opaque to SSHSM. The values are set by the Message=0A= Processing model (e.g., SNMPv3 Message Processing), and are not=0A= modified by SSHSM.=0A= =0A= msgMaxSize is determined by the implementation.=0A= =0A= To avoid the need to mess with the ASN.1 encoding, msgGlobalData=0A= contains the value of msgFlags set by the Message Processing model=0A= (e.g., SNMPv3 Message Processing), not the actual (authPriv)=0A= securityLevel applied to the message by SSHSM.=0A= =0A= msgSecurityModel is set by the Message Processing model (e.g.,=0A= SNMPv3) to the IANA-assigned value for the Secure Shell Security=0A= Model. See http://www.iana.org/assignments/snmp-number-spaces.=0A= =0A= 4.1.2. msgSecurityParameters=0A= =0A= Since message security is provided by a "lower layer", and the=0A= securityName parameter is always determined from the SSH=0A= authentication method, the SNMP message does not need to carry=0A= message security parameters within the msgSecurityParameters field.=0A= =0A= The field msgSecurityParameters in SNMPv3 messages has a data type of=0A= OCTET STRING. To prevent its being used in a manner that could be=0A= damaging, such as for carrying a virus or worm, when used with SSHSM=0A= its value MUST be the BER serialization of a zero-length OCTET=0A= STRING.=0A= =0A= SSHSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::=3D BEGIN=0A= =0A= SSHsmSecurityParameters ::=3D=0A= SEQUENCE {=0A= OCTET STRING=0A= }=0A= END=0A= =0A= 4.2. Passing Security Parameters=0A= =0A= For SSHSM, there are two levels of state that need to be maintained:=0A= the session state, and the message state.=0A= =0A= 4.2.1. tmStateReference=0A= =0A= For each session, SSHSM stores information about the session in the=0A= Local Configuration Datastore, supplemented with a cache to store=0A= model- and mechanism-specific parameters.=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 17]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= Upon opening an SSH connection, the TMSP will store the transport=0A= parameters in the tmSessionTable of the TMSM-MIB [I-D.ietf-isms-tmsm]=0A= for subsequent usage.=0A= =0A= tmsmSessionID =3D a unique local identifier=0A= tmsmTransport =3D transportDomainSSH=0A= tmsmSessionAddress =3D a TransportAddressSSH=0A= tmsmSessionSecurityModel - SSHSM=0A= tmsmSessionSecurityLevel =3D "authPriv"=0A= tmsmSessionSecurityName =3D the principal name authenticated by = SSH.=0A= How this data is extracted from the SSH environment and how it is=0A= translated into a securityName is implementation-dependent. By=0A= default, the tmSecurityName is the name that has been successfully=0A= authenticated by SSH, from the user name field of the=0A= SSH_MSG_USERAUTH_REQUEST message.=0A= tmsmSessionEngineID =3D if known, the value of the remote engine's=0A= snmpEngineID.=0A= =0A= How the SSH identity is extracted from the SSH layer, and how the SSH=0A= identity is mapped to a securityName for storage in tmsmSessionTable=0A= is implementation-dependent. Additional information may be stored in=0A= a local datastore (such as a preconfigured mapping table) or in a=0A= cache, such as the value of an SSH session identifier (as distinct=0A= from the tmsmSessionID).=0A= =0A= The tmSessionReference is used to pass references to the appropriate=0A= session information between the TMSP and MPSP through the ASIs.=0A= =0A= The SSHSM has the responsibility for explicitly releasing the=0A= complete tmSessionReference and deleting the associated=0A= tmsmSessionEntry in the tmsmSessionTable when the session is=0A= destroyed.=0A= =0A= 4.2.2. securityStateReference=0A= =0A= For each message received, SSHSM caches message-specific security=0A= information such that a Response message can be generated using the=0A= same security information, even if the Configuration Datastore is=0A= altered between the time of the incoming request and the outgoing=0A= response. The securityStateReference is used to preserve the data=0A= needed to generate a Response message with the same security=0A= information. This information includes the model-independent=0A= parameters (securityName, securityLevel, transport address, and=0A= transport type). The Message Processing Model has the responsibility=0A= for explicitly releasing the securityStateReference when such data is=0A= no longer needed. The securityStateReference cached data may be=0A= implicitly released via the generation of a response, or explicitly=0A= released by using the stateRelease primitive, as described in RFC=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 18]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 3411 section 4.5.1."=0A= =0A= The SSH standard does not require that a session be maintained nor=0A= that it be closed when the keys associated with the host or client=0A= associated with the session are changed. Some SSH implementations=0A= might close an existing session if the keys associated with the=0A= session change. For SSHSM, if the session is closed between the time=0A= a Request is received and a Response message is being prepared, then=0A= the Response should be discarded.=0A= =0A= The parameters associated with an incoming request message to be=0A= applied to the outgoing response.=0A= messageProcessingModel =3D SNMPv3=0A= securityModel =3D SSHSM=0A= sessionID =3D tmSessionID=0A= =0A= 5. Elements of Procedure=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. The Secure Shell Security Model uses some of these=0A= conceptual data flows when communicating between subsystems, such as=0A= the dispatcher and the Message Processing Subsystem. These RFC 3411-=0A= defined data flows are referred to here as public interfaces.=0A= =0A= To simplify the elements of procedure, the release of state=0A= information is not always explicitly specified. As a general rule,=0A= if state information is available when a message gets discarded, the=0A= message-state information should also be released, and if state=0A= information is available when a session is closed, the session state=0A= information should also be released.=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected.=0A= =0A= 5.1. Generating an Outgoing SNMP Message=0A= =0A= This section describes the procedure followed by an RFC3411-=0A= compatible system whenever it generates a message containing a=0A= management operation (such as a request, a response, a notification,=0A= or a report) on behalf of a user.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 19]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =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= )=0A= =0A= The IN parameters of the prepareOutgoingMessage() ASI are used to=0A= pass information from the dispatcher (for the application subsystem)=0A= to the message processing subsystem.=0A= =0A= The abstract service primitive from a Message Processing Model to a=0A= Security Model to generate the components of a Request message is=0A= generateRequestMsg(), as described in Section 5.2.=0A= =0A= The abstract service primitive from a Message Processing Model to a=0A= Security Model to generate the components of a Response message is=0A= generateResponseMsg(), as described in Section 5.2.:=0A= =0A= Upon completion of the MPSP processing, the SSH Security module=0A= returns statusInformation. If the process was successful, the=0A= completed message is returned, without the privacy and authentication=0A= applied yet. If the process was not successful, then an=0A= errorIndication is returned.=0A= =0A= The OUT parameters are used to pass information from the message=0A= processing subsystem to the dispatcher and on to the transport=0A= mapping:=0A= =0A= 5.2. MPSP for an Outgoing Message=0A= =0A= This section describes the procedure followed by the Secure Shell=0A= Security Model.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 20]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= The parameters needed for generating a message are supplied to the=0A= MPSP by the Message Processing Model via the generateRequestMsg() or=0A= the generateResponseMsg() ASI. The TMSM architectural extension has=0A= added the transportDomain, transportAddress, and tmSessionReference=0A= parameters to the original RFC3411 ASIs.=0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateRequestMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- as specified by application=0A= IN transportAddress -- as specified by application=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmSessionReference -- reference to session info=0A= )=0A= =0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateResponseMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- as specified by application=0A= IN transportAddress -- as specified by application=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= IN securityStateReference -- reference to security state=0A= -- information from original=0A= -- request=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmSessionReference -- reference to session info=0A= )=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 21]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= o statusInformation - An indication of whether the construction of=0A= the message was successful. If not it contains an indication of=0A= the problem.=0A= o messageProcessingModel - The SNMP version number for the message=0A= to be generated.=0A= o globalData - The message header (i.e., its administrative=0A= information). This data is opaque to SSHSM.=0A= o maxMessageSize - The maximum message size as included in the=0A= message. This data is not used by SSHSM.=0A= o transportDomain - as specified by the application.=0A= o transportAddress - as specified by the application.=0A= o securityModel - The securityModel in use. In this case, the SSH=0A= Security Model.=0A= o securityEngineID - SSHSM always sets this to the snmpEngineID of=0A= the sending SNMP engine.=0A= o securityName - identifies a principal to be used for securing an=0A= outgoing message. The securityName has a format that is=0A= independent of the Security Model. In case of a response this=0A= parameter is ignored and the value from the securityStateReference=0A= cache is used.=0A= o securityLevel - Ignored by SSHSM, which always uses an authPriv=0A= securityLevel.=0A= o scopedPDU - The message payload. The scopedPDU is opaque to=0A= SSHSM.=0A= o securityStateReference - A handle/reference to cachedSecurityData=0A= that is used when sending an outgoing Response message. This is=0A= the exact same securityStateReference as was generated by the SSH=0A= Security module when processing the incoming Request message to=0A= which this is the Response message.=0A= o securityParameters - Always set to empty by SSHSM.=0A= o wholeMsg - The fully encoded SNMP message ready for sending on the=0A= wire.=0A= o wholeMsgLength - The length of the encoded SNMP message=0A= (wholeMsg).=0A= o tmSessionReference - a handle/reference to the session information=0A= to be passed to the TMSP portion of the SSH Security Model.=0A= Note that SSHSM adds transportDomain, transportAddress, and=0A= tmSessionReference have been added to these ASIs.=0A= =0A= 5.2.1. MPSP Procedures=0A= =0A= 1) verify that securityModel is sshsmSecurityModel. If not, then=0A= an error indication is returned to the calling message model, and=0A= MPSP processing stops for this message.=0A= 2) If there is a securityStateReference, then extract the=0A= tmSessionReference from the cachedSecurityData. At this point,=0A= the SecurityDataCache can now be released.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 22]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 2b) If the session referenced by securityStateReference does not=0A= still exist (i.e., the session used to receive the request is no=0A= longer available to send the corresponding response) then the=0A= tmsmSessionNoAvailableSessions counter is incremented, an error=0A= indication is returned to the calling module, the message is=0A= discarded, and MPSP processing stops for this message.=0A= 3) If there is no securityStateReference, then find or create an=0A= entry in a Local Configuration Datastore containing the provided=0A= transportDomain, transportAddress, securityName, securityLevel,=0A= and securityModel, and create a tmSessionReference to reference=0A= the entry.=0A= 4) fill in the securityParameters with the serialization of a=0A= zero-length OCTET STRING.=0A= 5) Combine the message parts into a wholeMsg and calculate=0A= wholeMsgLength.=0A= 6) The completed message (wholeMsg) with its length=0A= (wholeMsgLength) and securityParameters (a zero-length octet=0A= string) and tmSessionReference is returned to the calling module=0A= with the statusInformation set to success.=0A= =0A= The Message Processing Model then passes information to the=0A= disptacher for forwarding to the Transport Mapping.=0A= =0A= 5.3. TMSP for an Outgoing Message=0A= =0A= The Dispatcher passes the information to the Transport Mapping using=0A= the ASI defined in the TMSM extension:=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 tmSessionReference=0A= )=0A= =0A= The TMSP portion of the SSHSM performs the following tasks:=0A= =0A= 5.3.1. TMSP Procedures=0A= =0A= 7) Lookup the session in the Local Configuration Datastore using=0A= the transportDomain, transportAddress, securityName,=0A= securityLevel, and securityModel from the tmSessionReference.=0A= Extract any implementation-specific parameters from the LCD.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 23]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 8) If there is no session open associated with the=0A= transportDomain, transportAddress, securityName, securityLevel,=0A= and securityModel, then call openSession(). If an error is=0A= returned from OpenSession(), then discard the message and return=0A= the error indication in the statusInformation.=0A= 9) Store any implementation-specific information in the LCD for=0A= subsequent use.=0A= 10) Pass the wholeMessage to SSH for encapsulation in an=0A= SSH_MSG_CHANNEL_DATA message.=0A= =0A= 5.4. Processing an Incoming SNMP Message=0A= =0A= 5.4.1. TMSP for an Incoming Message=0A= =0A= For an incoming message, the TMSP will need to put information from=0A= the SSH layer into a Local Configuration Datastore referenced by=0A= tmSessionReference.=0A= =0A= 1) The SSHSM queries the associated SSH engine, in an=0A= implementation-dependent manner, to determine the transport and=0A= security parameters for the received message.=0A= =0A= transportDomain =3D transportDomainSSH=0A= transportAddress =3D a TransportAddressSSH=0A= tmsmSecurityModel - SSHSM=0A= tmsmSecurityLevel =3D "authPriv"=0A= tmsmSecurityName =3D the principal name authenticated by SSH.=0A= How this data is extracted from the SSH environment and how it=0A= is translated into a securityName is implementation-dependent.=0A= By default, the tmSecurityName is the name that has been=0A= successfully authenticated by SSH, from the user name field of=0A= the SSH_MSG_USERAUTH_REQUEST message.=0A= 2) If one does not exist, the TMSP creates an entry in a Local=0A= Configuration Datastore, in an implementation-dependent format,=0A= containing the information and any implementation-specific=0A= parameters desired, and creates a tmSessionReference for=0A= subsequent reference to the information.=0A= =0A= Then the Transport mapping passes the message to the Dispatcher using=0A= the following primitive:=0A= statusInformation =3D=0A= recvMessage(=0A= OUT transportDomain -- domain for the received message=0A= OUT transportAddress -- address for the received message=0A= OUT wholeMessage -- the whole SNMP message from SSH=0A= OUT wholeMessageLength -- the length of the SNMP message=0A= OUT tmSessionReference=0A= )=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 24]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 5.5. Prepare Data Elements from Incoming Messages=0A= =0A= The abstract service primitive from the Dispatcher to a Message=0A= Processing Model for a received message is:=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 tmSessionReference -- from the transport mapping=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= Note that tmSessionReference has been added to this ASI.=0A= =0A= 5.6. MPSP for an Incoming Message=0A= =0A= This section describes the procedure followed by the MPSP whenever it=0A= receives an incoming message containing a management operation on=0A= behalf of a user from a Message Processing model.=0A= =0A= The Message Processing Model extracts some information from the=0A= wholeMsg. The abstract service primitive from a Message Processing=0A= Model to the Security Subsystem for a received message is::=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 25]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=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 tmSessionReference -- from the transport mapping=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= 1) The securityEngineID is set to the local snmpEngineID, to satisfy=0A= the SNMPv3 message processing model in RFC 3412 section 7.2 13a).=0A= =0A= 2) Extract the value of securityName from the Local Configuration=0A= Datastore entry referenced by tmSessionReference.=0A= =0A= 3) The scopedPDU component is extracted from the wholeMsg.=0A= =0A= 4) The maxSizeResponseScopedPDU is calculated. This is the maximum=0A= size allowed for a scopedPDU for a possible Response message.=0A= =0A= 5)The security data is cached as cachedSecurityData, so that a=0A= possible response to this message can and will use the same security=0A= parameters. Then securityStateReference is set for subsequent=0A= reference to this cached data. For SSHSM, the securityStateReference=0A= should include a reference to the tmSessionReference.=0A= =0A= 3) If the received securityParameters is not the serialization of an=0A= OCTET STRING formatted according to the SSHsmSecurityParameters, and=0A= the contained OCTET STRING is not empty, then the snmpInASNParseErrs=0A= counter [RFC3418] is incremented, and an error indication=0A= (parseError) is returned to the calling module.=0A= =0A= 4) The statusInformation is set to success and a return is made to=0A= the calling module passing back the OUT parameters as specified in=0A= the processIncomingMsg primitive.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 26]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 5.7. Establishing a Session=0A= =0A= The Secure Shell Security Model provides the following primitive to=0A= pass data back and forth between the Transport Mapping portion of the=0A= Security Model and the SSH service:=0A= =0A= statusInformation =3D=0A= openSession(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN securityModel -- Security Model to use=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= OUT tmSessionReference=0A= )=0A= =0A= =0A= The following describes the procedure to follow to establish a=0A= session between a client and server to run SNMP over SSH. This=0A= process is followed by any SNMP engine establishing a session for=0A= subsequent use.=0A= =0A= This will be done automatically for an SNMP application that=0A= initiates a transaction, such as a Command Generator or a=0A= Notification Originator or a Proxy Forwarder. It is never triggered=0A= by an application preparing a response message, such as a Command=0A= Responder or Notification Receiver, because securityStateReference=0A= will always have the session information for a response message=0A= =0A= 1) Using destTransportDomain and destTransportAddress, the client=0A= will establish an SSH transport connection using the SSH transport=0A= protocol, authenticate the server, and exchange keys for message=0A= integrity and encryption. The parameters of the transport connection=0A= and the credentials used to authenticate are provided in an=0A= implementation-dependent manner.=0A= =0A= If the attempt to establish a connection is unsuccessful, or server=0A= authentication fails, then an error indication is returned, and=0A= openSession processing stops.=0A= =0A= 2) The provided transport domain, transport address, securityModel,=0A= securityName and securityLevel are used to lookup an associated entry=0A= in the Local Configuration Datastore (LCD). Any model-specific=0A= information concerning the principal at the destination is extracted.=0A= This step allows preconfiguration of model-specific principals mapped=0A= to the transport/name/level, for example, for sending notifications.=0A= Set the username in the SSH_MSG_USERAUTH_REQUEST to the username=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 27]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= extracted from the LCD.=0A= =0A= If information about the principal is absent from the LCD, then set=0A= the username in the SSH_MSG_USERAUTH_REQUEST to the value of=0A= securityName. This allows a deployment without preconfigured=0A= mappings between model-specific and model-independent names, but the=0A= securityName will need to contain a username recognized by the=0A= authentication mechanism.=0A= =0A= 3)The client will then invoke the "ssh-userauth" service to=0A= authenticate the user, as described in the SSH authentication=0A= protocol [RFC4252].=0A= =0A= If the authentication is unsuccessful, then the transport connection=0A= is closed, tmSessionReference is released, the message is discarded,=0A= an error indication (unknownSecurityName) is returned to the calling=0A= module, and processing stops for this message.=0A= =0A= 4) Once the principal has been successfully authenticated, the client=0A= will invoke the "ssh- connection" service, also known as the SSH=0A= connection protocol [RFC4254].=0A= =0A= 5) After the ssh-connection service is established, the client will=0A= use an SSH_MSG_CHANNEL_OPEN message to open a channel of type=0A= "session", providing a selected sender channel number, and a maximum=0A= packet size calculated from the SNMP maxMessageSize.=0A= =0A= 6) If successful, this will result in an SSH session. The=0A= destTransportDomain and the destTransportAddress, plus the "recipient=0A= channel" and "sender channel" and other relevant data from the=0A= SSH_MSG_CHANNEL_OPEN_CONFIRMATION should be retained so they can be=0A= added to the LCD for subsequent use.=0A= =0A= 7) Once the SSH session has been established, the client will invoke=0A= SNMP as an SSH subsystem, as indicated in the "subsystem" parameter.=0A= =0A= In order to allow SNMP traffic to be easily identified and filtered=0A= by firewalls and other network devices, servers associated with SNMP=0A= entities using the Secure Shell Security Model MUST default to=0A= providing access to the "SNMP" SSH subsystem only when the SSH=0A= session is established using the IANA-assigned TCP port (TBD by=0A= IANA). Servers SHOULD be configurable to allow access to the SNMP=0A= SSH subsystem over other ports.=0A= =0A= 8) Create an entry in a Local Configuration Datastore containing the=0A= provided transportDomain, transportAddress, securityName,=0A= securityLevel, and securityModel, and SSH-speciifc parameters and=0A= create a tmSessionReference to reference the entry.=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 28]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 9) At this point an implementation MAY perform some type of engineID=0A= discovery to determine a mapping between the remote transport=0A= address, SSH session, TMSM session, and a contextEngineID.=0A= =0A= The contextEngineID of a remote engine needs to be "discovered" for=0A= use in request messages. USM, the mandatory-to-implement security=0A= model, can perform discovery of the snmpEngineIDs of adjacent engines=0A= using Reports (see [RFC3414] section 3.2 3b). Then the discovered=0A= snmpEngineID for the remote engine can be used as the contextEngineID=0A= in requests passed using the SSH security model.=0A= =0A= 10) The Local Configuration Datastore may also record implement-=0A= specific information, such as recording the following information:=0A= the remote engine's snmpEngineID=0A= the recipient and sender channels from the=0A= SSH_MSG_CHANNEL_OPEN_CONFIRMATION message=0A= the IP address corresponding to the hostname=0A= The SSH subsystem that was opened for this session for Request/=0A= Responses ("SNMP"), or for Notifications ("SNMPNotification").=0A= =0A= Return the tmSessionReference to the calling module.=0A= =0A= 5.8. Closing a Session=0A= =0A= The Secure Shell Security Model provides the following primitive to=0A= pass data back and forth between the Security Model and the SSH=0A= service:=0A= =0A= statusInformation =3D=0A= closeSession(=0A= IN tmSessionReference=0A= )=0A= =0A= =0A= =0A= The following describes the procedure to follow to close a session=0A= between a client and sever to run SNMP over SSH. This process is=0A= followed by any SNMP engine closing the corresponding SNMP session.=0A= =0A= The Secure Shell Security Model identifies which session should be=0A= closed to the SSH client code, using the closeSession() ASI.=0A= =0A= 6. Overview=0A= =0A= This MIB module provides management of the Secure Shell Security=0A= Model. It defines some needed textual conventions, and some=0A= statistics.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 29]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 6.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= 6.2. Textual Conventions=0A= =0A= Generic and Common Textual Conventions used in this document can be=0A= found summarized at http://www.ops.ietf.org/mib-common-tcs.html=0A= =0A= 6.3. The sshsmStats Subtree=0A= =0A= This subtree contains SSHSM security-model-dependent counters.=0A= =0A= This subtree provides information for identifying fault conditions=0A= and performance degradation.=0A= =0A= 6.4. The sshsmsSession Subtree=0A= =0A= This subtree contains SSHSM security-model-dependent information=0A= about sessions.=0A= =0A= 6.5. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing SSHSM. In particular, it is assumed that=0A= an entity implementing SSHSM will implement the SNMPv2-MIB [RFC3418],=0A= the SNMP-FRAMEWORK-MIB [RFC3411] and the TMSM-MIB=0A= [I-D.ietf-isms-tmsm].=0A= =0A= This MIB module is for managing SSHSM-specific information.=0A= =0A= 6.5.1. Relationship to the SNMPv2-MIB=0A= =0A= The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being=0A= mandatory for all systems, and the objects apply to the entity as a=0A= whole. The 'system' group provides identification of the management=0A= entity and certain other system-wide data. The SSHSM-MIB does not=0A= duplicate those objects.=0A= =0A= 6.5.2. Relationship to the SNMP-FRAMEWORK-MIB=0A= =0A= [todo] if the SSHSM-MIB does not actually have dependencies on SNMP-=0A= FRAMEWORK-MIB other than imports, then remove this paragraph.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 30]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 6.5.3. Relationship to the TMSM-MIB=0A= =0A= The 'tmsmSession' group in the TMSM-MIB [I-D.ietf-isms-tmsm] is=0A= defined as being applicable to all Transport-Mapping Security Models=0A= that use sessions. [todo] if the SSHSM-MIB does not actually have=0A= dependencies on TMSM-MIB other than imports, then remove this=0A= paragraph.=0A= =0A= 6.5.4. MIB Modules Required for IMPORTS=0A= =0A= The following MIB module imports items from [RFC2578], [RFC2579],=0A= [RFC2580], [RFC3411], [RFC3419], and [I-D.ietf-isms-tmsm]=0A= =0A= This MIB module also references [RFC3490]=0A= =0A= 7. MIB module definition=0A= =0A= ** Is AES the only officially required to support SSH encryption **=0A= mechanisms? It seems RFC 4344 has much more to offer. BTW, is it **=0A= useful to export all this information in an SSHSM MIB module? Some=0A= ** of the stuff seems generic SSH...=0A= =0A= SSHSM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= OBJECT-IDENTITY, mib-2, Counter32, Integer32=0A= FROM SNMPv2-SMI=0A= TestAndIncr, AutonomousType=0A= FROM SNMPv2-TC=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= SnmpAdminString, SnmpSecurityLevel, SnmpEngineID=0A= FROM SNMP-FRAMEWORK-MIB=0A= TransportAddress, TransportAddressType=0A= FROM TRANSPORT-ADDRESS-MIB=0A= ;=0A= =0A= sshsmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200509020000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 31]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= quittek@netlab.nec.de=0A= =0A= Juergen Schoenwaelder=0A= International University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Co-editors:=0A= David Harrington=0A= Effective Software=0A= 50 Harding Rd=0A= Portsmouth, New Hampshire 03801=0A= USA=0A= +1 603-436-8634=0A= ietfdbh@comcast.net=0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= jsalowey@cisco.com=0A= "=0A= DESCRIPTION "The Secure Shell Security Model MIB=0A= =0A= Copyright (C) The Internet Society (2006). This=0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200509020000Z" -- 02 September 2005=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 32]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= -- ---------------------------------------------------------- --=0A= -- subtrees in the SSHSM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= sshsmNotifications OBJECT IDENTIFIER ::=3D { sshsmMIB 0 }=0A= sshsmObjects OBJECT IDENTIFIER ::=3D { sshsmMIB 1 }=0A= sshsmConformance OBJECT IDENTIFIER ::=3D { sshsmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= TransportAddressSSH ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "1a"=0A= STATUS current=0A= DESCRIPTION=0A= "Represents either a hostname encoded in ASCII=0A= using the IDNA protocol, as specified in RFC3490, followed by=0A= a colon ':' (ASCII character 0x3A) and a decimal port number=0A= in ASCII, or an IP address followed by a colon ':'=0A= (ASCII character 0x3A) and a decimal port number in ASCII.=0A= The name SHOULD be fully qualified whenever possible.=0A= =0A= Values of this textual convention are not directly useable=0A= as transport-layer addressing information, and require=0A= runtime resolution. As such, applications that write them=0A= must be prepared for handling errors if such values are=0A= not supported, or cannot be resolved (if resolution occurs=0A= at the time of the management operation).=0A= =0A= The DESCRIPTION clause of TransportAddress objects that may=0A= have TransportAddressSSH values must fully describe how (and=0A= when) such names are to be resolved to IP addresses and vice=0A= versa.=0A= =0A= This textual convention SHOULD NOT be used directly in=0A= object definitions since it restricts addresses to a=0A= specific format. However, if it is used, it MAY be used=0A= either on its own or in conjunction with=0A= TransportAddressType or TransportDomain as a pair.=0A= =0A= When this textual convention is used as a syntax of an=0A= index object, there may be issues with the limit of 128=0A= sub-identifiers specified in SMIv2, STD 58. In this case,=0A= the OBJECT-TYPE declaration MUST include a 'SIZE' clause=0A= to limit the number of potential instance sub-identifiers."=0A= SYNTAX OCTET STRING (SIZE (1..255))=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 33]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= transportDomainSSH OBJECT-IDENTITY=0A= STATUS current=0A= DESCRIPTION=0A= "The SSH transport domain. The corresponding transport=0A= address is of type TransportAddressSSH.=0A= =0A= When an SNMP entity uses the transportDomainSSH transport=0A= mapping, it must be capable of accepting messages up to=0A= and including 8192 octets in size. Implementation of=0A= larger values is encouraged whenever possible."=0A= ::=3D { snmpDomains xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= =0A= =0A= -- Statistics for the Secure Shell Security Model=0A= =0A= =0A= sshsmStats OBJECT IDENTIFIER ::=3D { sshsmObjects 1 }=0A= =0A= -- [todo] do we need any stats?=0A= =0A= =0A= -- -------------------------------------------------------------=0A= -- sshsmMIB - Conformance Information=0A= -- -------------------------------------------------------------=0A= =0A= sshsmGroups OBJECT IDENTIFIER ::=3D { sshsmConformance 1 }=0A= =0A= sshsmCompliances OBJECT IDENTIFIER ::=3D { sshsmConformance 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Units of conformance=0A= -- -------------------------------------------------------------=0A= sshsmGroup OBJECT-GROUP=0A= OBJECTS {=0A= =0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining=0A= information of an SNMP engine which implements the=0A= SNMP Secure Shell Security Model.=0A= "=0A= =0A= ::=3D { sshsmGroups 2 }=0A= =0A= -- -------------------------------------------------------------=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 34]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= -- Compliance statements=0A= -- -------------------------------------------------------------=0A= =0A= sshsmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for SNMP engines that support the=0A= SSHSM-MIB"=0A= MODULE=0A= MANDATORY-GROUPS { sshsmGroup }=0A= ::=3D { sshsmCompliances 1 }=0A= =0A= END=0A= =0A= =0A= 8. Security Considerations=0A= =0A= This document describes a security model that would permit SNMP to=0A= utilize SSH security services. The security threats and how SSHSM=0A= mitigates those threats is covered in detail throughout this memo.=0A= =0A= SSHSM relies on SSH mutual authentication, binding of keys,=0A= confidentiality and integrity. Any authentication method that meets=0A= the requirements of the SSH architecture will provide the properties=0A= of mutual authentication and binding of keys. While SSH does support=0A= turning off confidentiality and integrity, they SHOULD NOT be turned=0A= off when used with SSHSM.=0A= =0A= SSHv2 provides Perfect Forward Security (PFS) for encryption keys.=0A= PFS is a major design goal of SSH, and any well-designed keyex=0A= algorithm will provide it.=0A= =0A= The security implications of using SSH are covered in [RFC4251].=0A= =0A= SSHSM has no way to verify that server authentication was performed,=0A= to learn the host's public key in advance, or verify that the correct=0A= key is being used. SSHSM simply trusts that these are properly=0A= cvonfigured by the implementer and deployer.=0A= =0A= 8.1. noAuthPriv=0A= =0A= SSH provides the "none" userauth method, which is normally rejected=0A= by servers and used only to find out what userauth methods are=0A= supported. However, it is legal for a server to accept this method,=0A= which has the effect of not authenticating the ssh client to the ssh=0A= server. Doing this does not compromise authentication of the ssh=0A= server to the ssh client, nor does it compromise data confidentiality=0A= or data integrity.=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 35]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= SSH supports anonymous access. If SSHSM can extract from SSH an=0A= authenticated principal to map to securityName, then anonymous access=0A= SHOULD be supported. It is possible for SSH to skip entity=0A= authentication of the client through the "none" authentication method=0A= to support anonymous clients, however in this case an implementation=0A= MUST still support data integrity within the SSH transport protocol=0A= and provide an authenticated principal for mapping to securityName=0A= for access control purposes.=0A= =0A= The RFC 3411 architecture does not permit noAuthPriv. SSHSM should=0A= not be used with an SSH connection with the "none" userauth method.=0A= =0A= 8.2. skipping public key verification=0A= =0A= Most key exchange algorithms are able to authenticate the SSH=0A= server's identity to the client. However, for the common case of DH=0A= signed by public keys, this requires the client to know the host's=0A= public key a priori and to verify that the correct key is being used.=0A= If this step is skipped, then authentication of the ssh server to the=0A= ssh client is not done. Data confidentiality and data integrity=0A= protection to the server still exist, but these are of dubious value=0A= when an attacker can insert himself between the client and the real=0A= ssh server. Note that some userauth methods may defend against this=0A= situation, but many of the common ones (including password and=0A= keyboard-interactive) do not, and in fact depend on the fact that the=0A= server's identity has been verified (so passwords are not disclosed=0A= to an attacker).=0A= =0A= SSH MUST NOT be configured to skip public key verification for use=0A= with the SSHSM security model.=0A= =0A= 8.3. the 'none' MAC algorithm=0A= =0A= SSH provides the "none" MAC algorithm, which would allow you to turn=0A= off data integrity while maintaining confidentiality. However, if=0A= you do this, then an attacker may be able to modify the data in=0A= flight, which means you effectively have no authentication.=0A= =0A= SSH MUST NOT be configured using the "none" MAC algorithm for use=0A= with the SSHSM security model.=0A= =0A= 8.4. MIB module security=0A= =0A= There are a number of management objects defined in this MIB module=0A= with a MAX-ACCESS clause of read-write and/or read-create. Such=0A= objects may be considered sensitive or vulnerable in some network=0A= environments. The support for SET operations in a non-secure=0A= environment without proper protection can have a negative effect on=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 36]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= network operations. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= o [todo]=0A= =0A= There are no management objects defined in this MIB module that have=0A= a MAX-ACCESS clause of read-write and/or read-create. So, if this=0A= MIB module is implemented correctly, then there is no risk that an=0A= intruder can alter or create any management objects of this MIB=0A= module via direct SNMP SET operations.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= o [todo]=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPSec or=0A= SSH), even then, there is no control as to who on the secure network=0A= is allowed to access and GET/SET (read/change/create/delete) the=0A= objects in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410] section 8), including=0A= full support for the USM and SSHSM cryptographic mechanisms (for=0A= authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= 9. IANA Considerations=0A= =0A= IANA is requested to assign:=0A= 1. a TCP port number in the range 1..1023 in the=0A= http://www.iana.org/assignments/port-numbers registry which will=0A= be the default port for SNMP over SSH sessions as defined in this=0A= document,=0A= 2. an SMI number under mib-2, for the MIB module in this document,=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 37]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 3. an SnmpSecurityModel for the Secure Shell Security Model, as=0A= documented in the MIB module in this document,=0A= 4. "snmp" as an SSH Service Name in the=0A= http://www.iana.org/assignments/ssh-parameters registry.=0A= =0A= 10. Acknowledgements=0A= =0A= The editors would like to thank Jeffrey Hutzelman for sharing his SSH=0A= insights.=0A= =0A= 11. References=0A= =0A= 11.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to=0A= Indicate Requirement Levels", BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Structure of Management=0A= Information Version 2 (SMIv2)", STD 58,=0A= RFC 2578, April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Textual Conventions for=0A= SMIv2", STD 58, RFC 2579, April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins, D., and J.=0A= Schoenwaelder, "Conformance Statements for=0A= SMIv2", STD 58, RFC 2580, April 1999.=0A= =0A= [RFC2865] Rigney, C., Willens, S., Rubens, A., and W.=0A= Simpson, "Remote Authentication Dial In User=0A= Service (RADIUS)", RFC 2865, June 2000.=0A= =0A= [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An=0A= Architecture for Describing Simple Network=0A= Management Protocol (SNMP) Management=0A= Frameworks", STD 62, RFC 3411, December 2002.=0A= =0A= [RFC3412] Case, J., Harrington, D., Presuhn, R., and B.=0A= Wijnen, "Message Processing and Dispatching for=0A= the Simple Network Management Protocol (SNMP)",=0A= STD 62, RFC 3412, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple=0A= Network Management Protocol (SNMP)=0A= Applications", STD 62, RFC 3413, December 2002.=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 38]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= [RFC3414] Blumenthal, U. and B. Wijnen, "User-based=0A= Security Model (USM) for version 3 of the=0A= Simple Network Management Protocol (SNMPv3)",=0A= STD 62, RFC 3414, December 2002.=0A= =0A= [RFC3416] Presuhn, R., "Version 2 of the Protocol=0A= Operations for the Simple Network Management=0A= Protocol (SNMP)", STD 62, RFC 3416,=0A= December 2002.=0A= =0A= [RFC3418] Presuhn, R., "Management Information Base (MIB)=0A= for the Simple Network Management Protocol=0A= (SNMP)", STD 62, RFC 3418, December 2002.=0A= =0A= [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual=0A= Conventions for Transport Addresses", RFC 3419,=0A= December 2002.=0A= =0A= [RFC3430] Schoenwaelder, J., "Simple Network Management=0A= Protocol Over Transmission Control Protocol=0A= Transport Mapping", RFC 3430, December 2002.=0A= =0A= [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,=0A= "Internationalizing Domain Names in=0A= Applications (IDNA)", RFC 3490, March 2003.=0A= =0A= [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Protocol Architecture", RFC 4251,=0A= January 2006.=0A= =0A= [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Authentication Protocol", RFC 4252,=0A= January 2006.=0A= =0A= [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Transport Layer Protocol", RFC 4253,=0A= January 2006.=0A= =0A= [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Connection Protocol", RFC 4254,=0A= January 2006.=0A= =0A= [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport=0A= Mapping Security Model (TMSM) Architectural=0A= Extension for the Simple Network Management=0A= Protocol (SNMP)", draft-ietf-isms-tmsm-02 (work=0A= in progress), May 2006.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 39]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= 11.2. Informative References=0A= =0A= [RFC1994] Simpson, W., "PPP Challenge Handshake=0A= Authentication Protocol (CHAP)", RFC 1994,=0A= August 1996.=0A= =0A= [RFC3410] Case, J., Mundy, R., Partain, D., and B.=0A= Stewart, "Introduction and Applicability=0A= Statements for Internet-Standard Management=0A= Framework", RFC 3410, December 2002.=0A= =0A= [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn,=0A= G., and J. Arkko, "Diameter Base Protocol",=0A= RFC 3588, September 2003.=0A= =0A= [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J.,=0A= and V. Welch, "Generic Security Service=0A= Application Program Interface (GSS-API)=0A= Authentication and Key Exchange for the=0A= Secure Shell (SSH) Protocol", RFC 4462,=0A= May 2006.=0A= =0A= [I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the=0A= NETCONF Configuration Protocol over Secure=0A= Shell (SSH)", draft-ietf-netconf-ssh-06 (work=0A= in progress), March 2006.=0A= =0A= Appendix A. Open Issues=0A= =0A= We need to reach consensus on some issues.=0A= =0A= Here is the current list of issues from the SSHSM document where we=0A= need to reach consensus.=0A= =0A= o The MIB module needs to be defined.=0A= o Consistency with TMSM needs to be done (TMSM needs some changes=0A= due to changes in SSHSM)=0A= o ssh transport domain and transport address definitions -=0A= consistency across WGs=0A= o=0A= =0A= A.1. Closed Issues=0A= =0A= #1: is it important to support anonymous user access to SNMP?=0A= Resolution: We should support whatever authorizations are provided by=0A= SSH; if SSH supports anonymous access, and SSHSM can extract a=0A= username, then it should be supported.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 40]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= #2: a) is server authentication a requirement that SNMP will require=0A= of the client? yes. b) how can we verify that server authentication=0A= was performed, or do we take simply trust the SSH client layer to=0A= perform such authentication? we trust the SSH layer to provide such=0A= auithentication. c) for the common case of DH signed by public keys,=0A= how does the client learn the host's public key in advance, and=0A= verify that the correct key is being used? this is out of scope for=0A= this document=0A= =0A= #3: we need some text contributed to discuss the implications of=0A= sessions on SNMP. See TMSM.=0A= =0A= #4: Should the SSHSM document include a discussion of the operational=0A= expectations of this model for use in troubleshooting a broken=0A= network, or can this be covered in the TMSM document? (Either way,=0A= we could use some contributed text on the topic). See TMSM.=0A= =0A= #5: Should the SSHSM document include a discussion of ways SNMP could=0A= be extended to better support management/monitoring needs when a=0A= network is running just fine, or can this be covered in the TMSM=0A= document, or in an applicability document? Out of scope for this=0A= document.=0A= =0A= #6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM?=0A= =0A= #7: is there still a need for an "authoritative SNMP engine"? No.=0A= =0A= #8: Do we need a mapping between the SSH key (or other SSH engine=0A= identifier) and SNMP engineID? No. What happens if an agent=0A= "spoofs" another engineID, and an NMS perfoms a SET of sensitive=0A= parameters to the agent? Resolution: we do not need to address this=0A= for local SSH and local snmpEngineID, unless smebody can show a use=0A= case requirement. There is likely to be a need to map, in an=0A= implementation-dependent manner, the remote engineIDs with the=0A= associated SSH host (mapping of engineID/transport address/host key).=0A= =0A= #9: Can an existing R/R session be reused for notifications? Yes.=0A= =0A= #10: a) which securityparameters must be supported for the SSHSM=0A= model? b) Which services provided in USM are needed in TMSM/SSHSM?=0A= C) How does the Message Processing model provide this information to=0A= the security model via generateRequestMsg() and processIncomingMsg()=0A= primitives?=0A= =0A= #11: If we eliminate all msgSecurityParameters, should the=0A= msgSecurityParameters field in the SNMPv3 message simply be a zero-=0A= length OCTET STRING, or should it be an ASN.1 NULL? It MUST be a=0A= BER-encoded OCTET STRING=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 41]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= #12: a) how does SSHSM determine whether SSH can provide the security=0A= services requested in msgFlags? It doesn't. B) There were=0A= discussions about whether it was acceptable for a transport-mapping-=0A= model to provide stronger security than requested. Does this need to=0A= be discussed in the SSHSM document, or should we discuss this in the=0A= TMSM document? Both. c) when sending a message into an environment=0A= where encryption is not legal, how do we ensure that encryption is=0A= not provided? The Danvers Doctrine seems to indicate this in not=0A= necessary to discuss.=0A= =0A= #13: will SSHSM be impacted by keychanges to the SSH local datastore?=0A= Resolution: if the session is closed while the Response is being=0A= prepared, discard the Response.=0A= =0A= #14: MUST the SSHSM model provide mutual authentication of the client=0A= and server, and MUST it authenticate, integrity-check, and encrypt=0A= the messages? Resolution: yes.=0A= =0A= #15: What data needs to be stored in the tmSessionReference, and how=0A= does SSHSM get the information from SSH, for the various=0A= authentication and transport options?=0A= =0A= #16: The SSH server doesn't necessarily authorize the name carried in=0A= the SSH_MSG_USERAUTH_REQUEST message, but may return a different name=0A= or list of names that are authorized to be used given the=0A= authentication of the provided username. Resolution: this is=0A= mistaken; the username from the SSH_MSG_USERAUTH_REQUEST SHOULD be=0A= used. A) What should be the source of the SSHSM mechanism-specific=0A= username for mapping to securityname? Resolution: the username from=0A= the SSH_MSG_USERAUTH_REQUEST SHOULD be used.=0A= =0A= #16 B) passing a securityName might be useful for passing as a hint=0A= to RADIUS or other authorization mechanism to indicate which identity=0A= we want to use when doing access control, and RADIUS,etc. can tell us=0A= whether the username being authenticated is allowed to be mapped to=0A= that authorization/accounting identity. Should we provide=0A= securityName when establishing a session, so the authentication=0A= machanisms can use it as a hint? SSHSM provides securityName/Model/=0A= Level and tranport; whether SSH passes this to RADIUS is out of scope=0A= for this document.=0A= =0A= #17: I believe somebody suggested we require mutual authentication.=0A= I'm not sure I understand the edits. Done.=0A= =0A= #18: I currently have multiple sections, one for each known auth=0A= mechanism. We need to discuss the parameters that need to be cached=0A= for each, and determine whether we can collapse this into one=0A= section. a) Using Passwords to Authenticate SNMP Principals B) Using=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 42]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= Public keys to Authenticate SNMP Principals C) Using Host-based=0A= Authentication of SNMP Principals Resolution: I will collapse this=0A= later, after we have verified we have considered all current/likely=0A= scenarios. Done.=0A= =0A= #19: RADIUS is just an instance of the password authentication=0A= protocol. The details of RADIUS are within the SSH layer. I don't=0A= think it is a good idea to expose this outside of SSH. Resolution:=0A= If possible, the details of RADIUS should not be exposed in SSHSM.=0A= There may be an issue with receiving authorization without exposing=0A= the details.=0A= =0A= #20: How do we get the mapping from model-specific identity to a=0A= model independent securityName?. Resolution: Implementation-=0A= dependent, both in the case of extracting tmSecurityname from SSH for=0A= an incoming message, and for providing an LCD mapping.=0A= =0A= #21: we need to determine what data should be persistent and stored=0A= in the LCD for notification purposes.=0A= =0A= #22: Joe: There are a significant number of security problems=0A= associated with mapping to a transport address which may need to be=0A= discussed in the security considerations section. Resolution: add a=0A= transporttype for hostname.=0A= =0A= #23: We need to discuss the circumstances under which a session=0A= should be closed, and how an SNMP engine should determine if, and=0A= respond if the SSH session is closed by other means, See TMSM, and=0A= implementation-dependent.=0A= =0A= #24: How should we enable auto-discovery?=0A= =0A= #25: Where is the best place to call openSession()? Note that the=0A= whole message is completely put together within the message-=0A= processing portion of the security model, in the hopes that a session=0A= will be able to be established when the message gets to the transport=0A= mapping portion of the architecture. It is done this way because the=0A= RFC3411 arcitecture doesn't pass the transport addressing info into=0A= the security model via messaging model. It would seem a much more=0A= efficient approach to verify that the session can be established,=0A= while still in the security model portion of the messaging model. If=0A= we don't establish the session until we get to the transport mapping,=0A= we've done a lot of work for nothing. And thus far, there is no=0A= place to record failed attempts to establish a session, so an engine=0A= doesn't learn to not try to open a session. In an environment where=0A= the SNMP engine might be a daemon used by multiple applications, an=0A= attacker could use this to cause a denial of service attack at the=0A= NMS. This would likely occur on the NMS side. I don't know if=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 43]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= there's any way to cause it to happen on the agent side. I suppose a=0A= rogue agent with callhome functionality might be able to cause a=0A= denial of service for an NMS by repeatedly requesting callhome and=0A= then refusing the connections. Resolution: called from TMSP.=0A= =0A= #26: According to RFC 3411, section 4.1.1, the application provides=0A= the transportDomain and transportAddress to the PDU dispatcher via=0A= the sendPDU() primitive. If we permit multiple sessions per=0A= transportAddress, then we would need to define how session=0A= identifiers get passed from the application to the PDU dispatcher=0A= (and then to the MP model).Resolution: applications do not know about=0A= sessions.=0A= =0A= #27: The SNMP over TCP Transport Mapping document [RFC3430] says that=0A= TCP connections can be recreated dynamically or kept for future use=0A= and actually leaves all that to the transport mapping. Do we need to=0A= discuss these issues? Where? in the security considerations? See=0A= TMSM.=0A= =0A= #28: For notification tables, how do we predefine the dynamic session=0A= identifiers? We might have a MIB module that records the session=0A= information for subsequent use by the applications and other=0A= subsytems, or it might be passed in the tmSessionReference cache.=0A= For notifications, I assume the SNMPv3 notification tables would be a=0A= place to find the address, but I'm not sure how to identify the=0A= presumably-dynamic session identifiers. The MIB module could=0A= identify whether the session was initiated by the remote engine or=0A= initiated by the current engine, and possibly assigned a purpose=0A= (incoming request/response or outgoing notifications).. Resolution:=0A= applications do not know about sessions, only transport and=0A= securityN/M/L; if separate sessions are desired, then they can be=0A= differentiated by transport and securityN/M/L parameters.=0A= =0A= #29: do we need to support reports? For what purpose? Yes, reports=0A= are used from application processing and for contextEngine discovery.=0A= =0A= #30: If we actually do not extract anything from securityParameters,=0A= do we need to check whether this field parses correctly? It=0A= apparently parsed well enough to pass the parse test in the messaging=0A= model. Could we simply ignore the securityParameters being passed=0A= in? The only argument I see for checking to ensure this is empty is=0A= to ensure somebody isn't using the filed for non-standard purposes,=0A= such as passing a virus in the field. If we do check it, do we need=0A= to report it through Reports? Resolution: yes; it won't hurt to=0A= check it.=0A= =0A= #32: For an incoming message (Processing an Incoming Message section=0A= 10), is using a default securityName mapping the right thing to do?=0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 44]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= Resolution: Yes, it is the right thing to do.=0A= =0A= #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once=0A= for the session? Do we need to take into consideration the SSH=0A= window size? Resolution: It can probably be calculated once per=0A= session.=0A= =0A= #33: does the mib need to be writable, so sessions can be=0A= preconfigured, such as for callhome, or would it be populated at=0A= creation time by the underlying instrumentation, and not writable by=0A= SNMP? This is about the session table, which has been moved to TMSM.=0A= =0A= [discuss] #34 - how do we determine whether a PDU contains a Request=0A= /Response or a Notification? By configuring the securityName or the=0A= transport parameters.=0A= =0A= [discuss] #35 - which subsystem is used for Reports? ** Reports are a=0A= reaction to a previously received message and thus they go wherever=0A= the previous message triggering the report came from.=0A= =0A= Appendix B. Change Log=0A= =0A= "From -03- to -04-"=0A= =0A= o changed tmStateReference to tmSessionReference=0A= o=0A= =0A= "From -02- to -03-"=0A= =0A= rewrote almost all sections=0A= merged ASI section and Elements of Procedure sections=0A= removed references to the SSH user, in preference to SSH client=0A= updated references=0A= creayted a conventions section to identify common terminology.=0A= rewrote sections on how SSH addresses threats=0A= rewrote mapping SSH to engineID=0A= eliminated discovery section=0A= detailed the Elements of Procedure=0A= eliminated secrtions on msgFlags, transport parameters=0A= resolved issues of opening notifications=0A= eliminated sessionID (TMSM needs to be updated to match)=0A= eliminated use of tmsmSessiontable except as an example=0A= updated Security Considerations=0A= =0A= "From -01- to -02-"=0A= Added TransportDomainSSH and Address=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 45]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= Removed implementation considerations=0A= Changed all "user auth" to "client auth"=0A= Removed unnecessary MIB module objects=0A= updated references=0A= improved consistency of references to TMSM as architecural=0A= extension=0A= updated conventions=0A= updated threats to be more consistent with RFC3552=0A= discussion of specific SSH mechanism configurations moved to=0A= security considerations=0A= modified session discussions to reference TMSM sessions=0A= expanded discussion of engineIDs=0A= wrote text to clarify the roles of MPSP and TMSP=0A= clarified how snmpv3 message parts are ised by SSHSM=0A= modified nesting of subsections as needed=0A= securityLevel used by SSHSM always equals authpriv=0A= removed discussion of using SSHSM with SNMPv1/v2c=0A= started updating Elements of Procedure, but realized missing info=0A= needs discussion.=0A= updated MIB module relationship to other MIB modules=0A= =0A= "From -00- to -01-"=0A= -00- initial draft as ISMS work product:=0A= updated references to SecSH RFCs=0A= Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19,=0A= 20, 29, 30, and 32.=0A= updated security considerations=0A= removed Juergen Schoenwaelder from authors, at his request=0A= ran the mib module through smilint=0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 46]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= =0A= EMail: jsalowey@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires December 25, 2006 [Page 47]=0A= =0C=0A= Internet-Draft Secure Shell Security Model for SNMP June 2006=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2006).=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 AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= 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 & Salowey Expires December 25, 2006 [Page 48]=0A= =0C=0A= =0A= ------=_NextPart_000_0108_01C69946.57550D30 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_0108_01C69946.57550D30-- From isms-bounces@lists.ietf.org Mon Jul 03 09:36:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxObB-0000hd-Tg; Mon, 03 Jul 2006 09:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuymG-0007Lq-BC for isms@ietf.org; Mon, 26 Jun 2006 17:37:52 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuymC-0000HD-Jc for isms@ietf.org; Mon, 26 Jun 2006 17:37:52 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc14) with SMTP id <20060626213743m1400o07dre>; Mon, 26 Jun 2006 21:37:44 +0000 From: "David B Harrington" To: Date: Mon, 26 Jun 2006 17:36:29 -0400 Message-ID: <010b01c69968$964a7b70$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_010C_01C69947.0F38DB70" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaZZ+ScTYnFmkwfQ8eWDOi4GQZ6aw== X-Spam-Score: 0.2 (/) X-Scan-Signature: 77c3d50a139881edb673e56787e000fd X-Mailman-Approved-At: Mon, 03 Jul 2006 09:36:24 -0400 Cc: Subject: [Isms] Draft-ietf-isms-tmsm-03.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 This is a multi-part message in MIME format. ------=_NextPart_000_010C_01C69947.0F38DB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The TMSM -03- draft is slow in coming. Here it is if anybody wants to review it before it is posted in the ID repository. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_010C_01C69947.0F38DB70 Content-Type: text/plain; name="draft-ietf-isms-tmsm-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-tmsm-03.txt" =0A= =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Informational J. Schoenwaelder=0A= Expires: December 25, 2006 International University Bremen=0A= June 23, 2006=0A= =0A= =0A= Transport Mapping Security Model (TMSM) Architectural Extension for the=0A= Simple Network Management Protocol (SNMP)=0A= draft-ietf-isms-tmsm-03.txt=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 December 25, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= This document describes a Transport Mapping Security Model (TMSM)=0A= extension for the Simple Network Management Protocol (SNMP)=0A= architecture defined in RFC 3411. This document identifies and=0A= discusses some key aspects that need to be considered for any=0A= transport-mapping-based security model for SNMP.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 1]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for managing sessions in the Transport Mapping Security Model=0A= extension.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 4=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 2. Requirements of a Transport Mapping Security Model . . . . . . 6=0A= 2.1. Message Security Requirements . . . . . . . . . . . . . . 6=0A= 2.1.1. Security Protocol Requirements . . . . . . . . . . . . 7=0A= 2.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 7=0A= 2.2.1. Architectural Modularity Requirements . . . . . . . . 7=0A= 2.2.2. Access Control Requirements . . . . . . . . . . . . . 14=0A= 2.2.3. Security Parameter Passing Requirements . . . . . . . 16=0A= 2.3. Session Requirements . . . . . . . . . . . . . . . . . . . 17=0A= 2.3.1. Session Establishment Requirements . . . . . . . . . . 18=0A= 2.3.2. Session Maintenance Requirements . . . . . . . . . . . 19=0A= 2.3.3. Message security versus session security . . . . . . . 19=0A= 3. Scenario Diagrams for TMSM . . . . . . . . . . . . . . . . . . 21=0A= 3.1. Command Generator or Notification Originator . . . . . . . 21=0A= 3.2. Command Responder . . . . . . . . . . . . . . . . . . . . 22=0A= 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 23=0A= 4.1. SNMPv3 Message Fields . . . . . . . . . . . . . . . . . . 24=0A= 4.1.1. msgGlobalData . . . . . . . . . . . . . . . . . . . . 26=0A= 4.1.2. msgSecurityParameters . . . . . . . . . . . . . . . . 27=0A= 5. Cached Information and References . . . . . . . . . . . . . . 27=0A= 5.1. tmSessionReference Cached Session Data . . . . . . . . . . 27=0A= 5.2. securityStateReference Cached Security Data . . . . . . . 27=0A= 6. Abstract Service Interfaces for TMSM . . . . . . . . . . . . . 28=0A= 6.1. Generating an Outgoing SNMP Message . . . . . . . . . . . 29=0A= 6.2. TMSP for an Outgoing Message . . . . . . . . . . . . . . . 30=0A= 6.3. Processing an Incoming SNMP Message . . . . . . . . . . . 30=0A= 6.3.1. TMSP for an Incoming Message . . . . . . . . . . . . . 30=0A= 6.3.2. Prepare Data Elements from Incoming Messages . . . . . 31=0A= 6.3.3. MPSP for an Incoming Message . . . . . . . . . . . . . 32=0A= 7. The TMSM MIB Module . . . . . . . . . . . . . . . . . . . . . 33=0A= 7.1. Structure of the MIB Module . . . . . . . . . . . . . . . 33=0A= 7.1.1. The tmsmStats Subtree . . . . . . . . . . . . . . . . 33=0A= 7.2. Relationship to Other MIB Modules . . . . . . . . . . . . 33=0A= 7.2.1. Textual Conventions . . . . . . . . . . . . . . . . . 33=0A= 7.2.2. MIB Modules Required for IMPORTS . . . . . . . . . . . 33=0A= 7.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 33=0A= 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38=0A= 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 2]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39=0A= 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39=0A= 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39=0A= 11.2. Informative References . . . . . . . . . . . . . . . . . . 40=0A= Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 41=0A= A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 41=0A= Appendix B. Why tmSessionReference? . . . . . . . . . . . . . . . 42=0A= B.1. Define an Abstract Service Interface . . . . . . . . . . . 43=0A= B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 43=0A= B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 43=0A= B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 44=0A= Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 44=0A= Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 44=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 3]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= This document describes a Transport Mapping Security Model (TMSM)=0A= extension for the Simple Network Management Protocol (SNMP)=0A= architecture defined in [RFC3411]. This document identifies and=0A= discusses some key aspects that need to be considered for any=0A= transport-mapping-based security 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= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= 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= Some points requiring further WG research and discussion are=0A= identified by [discuss] markers in the text. Some points requiring=0A= further editing by the editors are marked [todo] in the text.=0A= =0A= 1.3. Acronyms=0A= =0A= This section contains a list of acronyms used within the document and=0A= references to where in the document the acronym is defined, for easy=0A= lookup.=0A= o TMSM - a Transport Mapping Security Model=0A= o SMSP - a Security Model Security Processor, the portion of a TMSM=0A= security model that resides in the Message Processing subsystem of=0A= an SNMPv3 engine. See Section 2.2.1=0A= o TMSP - the Transport Mapping Security Processor, the portion of a=0A= TMSM security model that resides in the Transport Mapping section=0A= of the Dispatcher of an SNMPv3 engine. See Section 2.2.1=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 4]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 1.4. Motivation=0A= =0A= There are multiple ways to secure one's home or business, in a=0A= continuum of alternatives. Let's consider three general approaches.=0A= In the first approach, an individual could buy a gun, learn to use=0A= it, and sit on your front porch waiting for intruders. In the second=0A= approach, one could hire an employee with a gun, schedule the=0A= employee, position the employee to guard what you want protected,=0A= hire a second guard to cover if the first gets sick, and so on. In=0A= the third approach, you could hire a security company, tell them what=0A= you want protected, and they could hire employees, train them, buy=0A= the guns, position the guards, schedule the guards, send a=0A= replacement when a guard cannot make it, etc., thus providing the=0A= security you want, with no significant effort on your 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 (MD5=3Dthe gun), 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 but=0A= difficult to define external mechanisms that handle the distribution=0A= of keys for use by the USM approach.=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= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 5]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =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 [I-D.ietf-netconf-ssh].=0A= =0A= This document proposes a Transport Mapping Security Model (TMSM)=0A= extension to the RFC3411 architecture, that allows security to be=0A= provided by an external protocol connected to the SNMP engine through=0A= an SNMP transport-mapping [RFC3417]. Such a TMSM would then enable=0A= the use of existing security mechanisms such as (TLS) [RFC4366] or=0A= SSH [RFC4251] 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 TMSM is to leverage these protocols=0A= where it seems useful.=0A= =0A= There are a number of challenges to be addressed to map the security=0A= provided by a secure transport into the SNMP architecture so that=0A= SNMP continues to work without any surprises. These challenges are=0A= discussed in detail in this document. For some key issues, design=0A= choices are discussed that may be made to provide a workable solution=0A= that meets operational requirements and fits into the SNMP=0A= architecture defined in [RFC3411].=0A= =0A= 2. Requirements of a Transport Mapping Security Model=0A= =0A= 2.1. Message Security Requirements=0A= =0A= Transport mapping security protocols SHOULD ideally provide the=0A= protection against the following message-oriented threats [RFC3411]:=0A= =0A= 1. modification of information=0A= 2. masquerade=0A= 3. message stream modification=0A= 4. disclosure=0A= =0A= According to [RFC3411], it is not required to protect against denial=0A= of service or traffic analysis.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 6]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 2.1.1. Security Protocol Requirements=0A= =0A= There are a number of standard protocols that could be proposed as=0A= possible solutions within the TMSM framework. Some factors should be=0A= considered when selecting a protocol for use within this framework.=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 may depend on its being used as designed; when used in other=0A= ways, it may not deliver the expected security characteristics. It=0A= is recommended that any proposed model include a discussion of the=0A= applicability statement of the protocols to be used.=0A= =0A= A protocol used for the TMSM framework should ideally require no=0A= modifications to the protocol. Modifying the protocol may change its=0A= security characteristics in ways that would impact other existing=0A= usages. If a change is necessary, the change should be an extension=0A= that has no impact on the existing usages. It is recommended that=0A= any proposed model include a discussion of potential impact on other=0A= usages of the protocol.=0A= =0A= It has been a long-standing requirement that SNMP be able to work=0A= when the network is unstable, to enable network troubleshooting and=0A= repair. The UDP approach has been considered to meet that need well,=0A= with an assumption that getting small messages through, even if out=0A= of order, is better than getting no messages through. There has been=0A= a long debate about whether UDP actually offers better support than=0A= TCP when the underlying IP or lower layers are unstable. There has=0A= been recent discussion of whether operators actually use SNMP to=0A= troubleshoot and repair unstable networks.=0A= =0A= There has been discussion of ways SNMP could be extended to better=0A= support management/monitoring needs when a network is running just=0A= fine. Use of a TCP transport, for example, could enable larger=0A= message sizes and more efficient table retrievals.=0A= =0A= TMSM models MUST be able to coexist with other protocol models, and=0A= may be designed to utilize either TCP or UDP, depending on the=0A= transport.=0A= =0A= 2.2. SNMP Requirements=0A= =0A= 2.2.1. Architectural Modularity Requirements=0A= =0A= SNMP version 3 (SNMPv3) is based on a modular architecture (described=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. The architecture includes a Security=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 7]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= Subsystem which is responsible for realizing security services.=0A= =0A= In SNMPv2, there were many problems of side effects between=0A= subsystems caused by the manipulation of MIB objects, especially=0A= those related to authentication and authorization, because many of=0A= the parameters were stored in shared MIB objects, and different=0A= models and protocols could assign different values to the objects.=0A= Contributors assumed slightly different shades of meaning depending=0A= on the models and protocols being used. As the shared MIB module=0A= design was modified to accommodate a specific model, other models=0A= which used the same MIB objects were broken.=0A= =0A= Abstract Service Interfaces (ASIs) were developed to pass model-=0A= independent parameters. The models were required to translate from=0A= their model-dependent formats into a model-independent format,=0A= defined using model-independent semantics, which would not impact=0A= other models.=0A= =0A= Parameters have been provided in the ASIs to pass model-independent=0A= information about the authentication that has been provided. These=0A= parameters include a model-independent identifier of the security=0A= "principal", the security model used to perform the authentication,=0A= and which SNMP-specific security features were applied to the message=0A= (authentication and/or privacy).=0A= =0A= Parameters have been provided in the ASIs to pass model-independent=0A= transport address information. These parameters utilize the=0A= TransportType and TransportAddress=0A= =0A= The design of a transport mapping security model must abide the goals=0A= of the RFC3411 architecture defined in [RFC3411]. To that end, this=0A= transport mapping security model proposal uses a modular design that=0A= can be advanced through the standards process independently of other=0A= proposals, and independent of other modular components as much as=0A= possible.=0A= =0A= IETF standards typically require one mandatory to implement solution,=0A= with the capability of adding new security mechanisms in the future.=0A= Any transport mapping security model should define one minimum-=0A= compliance mechanism, preferably one which is already widely deployed=0A= within the transport layer security protocol used.=0A= =0A= The TMSM architectural extension permits additional transport=0A= security protocols to be "plugged into" the RFC3411 architecture,=0A= supported by corresponding transport-security-aware transport mapping=0A= models.=0A= =0A= The RFC3411 architecture, and the USM approach, assume that a=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 8]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= security model is called by a message-processing model and will=0A= perform multiple security functions. The TMSM approach performs=0A= similar functions but performs them in different places within the=0A= architecture, so we need to distinguish the two locations for=0A= security processing.=0A= =0A= Transport mapping security is by its very nature a security layer=0A= which is plugged into the RFC3411 architecture between the transport=0A= layer and the message dispatcher. Conceptually, transport mapping=0A= security processing will be called from within the Transport Mapping=0A= functionality of an SNMP engine dispatcher to perform the translation=0A= of transport security parameters to/from security-model-independent=0A= parameters. This transport mapping security processor will be=0A= referred to in this document as TMSP.=0A= =0A= Additional functionality may be performed as part of the message=0A= processing function, i.e., in the security subsystem of the RFC3411=0A= architecture. This document will refer to security model's security=0A= processor as the SMSP.=0A= =0A= Thus a TMSM is composed of both a TMSP and an SMSP.=0A= =0A= =0A= +------------------------------+=0A= | Network |=0A= +------------------------------+=0A= ^ ^ ^=0A= | | |=0A= v v v=0A= +-----+ +-----+ +-------+=0A= | UDP | | TCP | . . . | other |=0A= +-----+ +-----+ +-------+=0A= ^ ^ ^=0A= | | |=0A= v v v=0A= +-----+ +-----+ +-------+=0A= | SSH | | TLS | . . . | other |=0A= +-----+ +-----+ +-------+ (traditional SNMP agent)=0A= +-------------------------------------------------------------------+=0A= | ^ |=0A= | | |=0A= | Dispatcher v |=0A= | +-------------------+ |=0A= | | Transport | +--------------+ |=0A= | | Mapping |<---> | TMSM | |=0A= | | (e.g., RFC 3417) | | TMSP | |=0A= | | | +--------------+ |=0A= | | | |=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 9]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= | | | +---------------------+ +----------------+ |=0A= | | | | Message Processing | | Security | |=0A= | | | | Subsystem | | Subsystem | |=0A= | | | | +------------+ | | | |=0A= | | | | +->| v1MP * |<--->| +------------+ | |=0A= | | | | | +------------+ | | | Other | | |=0A= | | | | | +------------+ | | | Security | | |=0A= | | | | +->| v2cMP * |<--->| | Model | | |=0A= | | Message | | | +------------+ | | +------------+ | |=0A= | | Dispatcher <--------->| +------------+ | | +------------+ | |=0A= | | | | +->| v3MP * |<--->| | TMSM | | |=0A= | | | | | +------------+ | | | SMSP | | |=0A= | | PDU Dispatcher | | | +------------+ | | | | | |=0A= | +-------------------+ | +->| otherMP * |<--->| +------------+ | |=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= 2.2.1.1. USM and the RFC3411 Architecture=0A= =0A= The following diagrams illustrate the difference in the security=0A= processing done by the USM model and the security processing done by=0A= a TMSM model.=0A= =0A= The USM security model is encapsulated by the messaging model,=0A= because the messaging model needs to perform the following steps (for=0A= incoming messages)=0A= 1) decode the ASN.1 (messaging model)=0A= 2) determine the SNMP security model and parameters (messaging model)=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 10]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 3) decrypt the encrypted portions of the message (security model)=0A= 4) translate parameters to model-independent parameters (security=0A= model)=0A= 5) determine which application should get the decrypted portions=0A= (messaging model), and=0A= 6) pass on the decrypted portions with model-independent parameters.=0A= =0A= The USM approach uses SNMP-specific message security and parameters.=0A= =0A= =0A= | -----------------------------------------------|=0A= | transport layer |=0A= | -----------------------------------------------|=0A= ^=0A= |=0A= v=0A= --------------------------------------------------=0A= | -----------------------------------------------|=0A= | | transport mapping |=0A= | -----------------------------------------------|=0A= | ^=0A= | |=0A= | v=0A= | --------------------------------------------- |=0A= | --------------------- ------------------ |=0A= | SNMP messaging <--> | decryption + | |=0A= | | translation | |=0A= | --------------------- ------------------ |=0A= | ^=0A= | |=0A= | v=0A= | --------------------- ------------------ |=0A= | | SNMP applications | <--> | access control | |=0A= | --------------------- ------------------ |=0A= =0A= | --------------------------------------------- |=0A= =0A= =0A= =0A= 2.2.1.2. TMSM and the RFC3411 Architecture=0A= =0A= In the TMSM approach, the order of the steps differ and may be=0A= handled by different subsystems:=0A= 1) decrypt the encrypted portions of the message (transport layer)=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 11]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 2) determine the SNMP security model and parameters (transport=0A= mapping)=0A= 3*) translate parameters to model-independent parameters (transport=0A= mapping)=0A= 4) decode the ASN.1 (messaging model)=0A= 5) determine which application should get the decrypted portions=0A= (messaging model)=0A= 6*) translate parameters to model-independent parameters (security=0A= model)=0A= 7) pass on the decrypted portions with model-independent security=0A= parameters=0A= =0A= This is largely based on having non-SNMP-specific message security=0A= and parameters. The transport mapping model might provide the=0A= translation from e.g., an SSH user name to the securityName in step=0A= 3, OR the SSH user might be passed to the messaging model to pass to=0A= a TMSM security model to do the translation in step 6, if the WG=0A= decides all translations should use the same translation table (e.g.,=0A= the USM MIB).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 12]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= | -----------------------------------------------|=0A= | ------------------ |=0A= | transport layer <--> | decryption | |=0A= | ------------------ |=0A= | -----------------------------------------------|=0A= ^=0A= |=0A= v=0A= --------------------------------------------------=0A= | -----------------------------------------------|=0A= | ------------------ |=0A= | transport mapping <--> | translation* | |=0A= | ------------------ |=0A= | -----------------------------------------------|=0A= | ^=0A= | |=0A= | v=0A= | --------------------------------------------- |=0A= | ------------------ |=0A= | SNMP messaging <--> | translation* | |=0A= | ------------------ |=0A= | --------------------- ------------------ |=0A= | ^=0A= | |=0A= | v=0A= | --------------------- ------------------ |=0A= | | SNMP applications | <--> | access control | |=0A= | --------------------- ------------------ |=0A= =0A= | --------------------------------------------- |=0A= =0A= =0A= =0A= 2.2.1.3. Passing Information between Engines=0A= =0A= A TMSM model will establish an encrypted tunnel between the transport=0A= mappings of two SNMP engines. One transport mapping security model=0A= instance encrypts all messages, and the other transport mapping=0A= security model instance decrypts the messages.=0A= =0A= After the transport layer tunnel is established, then SNMP messages=0A= can conceptually be sent through the tunnel from one SNMP message=0A= dispatcher to another SNMP message dispatcher. Once the tunnel is=0A= established, multiple SNMP messages may be able to be passed through=0A= the same tunnel.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 13]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 2.2.2. Access Control Requirements=0A= =0A= 2.2.2.1. securityName Binding=0A= =0A= For SNMP access control to function properly, the security mechanism=0A= must establish a securityModel identifier, a securityLevel, and a=0A= securityName, which is the security model independent identifier for=0A= a principal. The SNMPv3 message processing architecture subsystem=0A= relies on a security model, such as USM, to play a role in security=0A= that goes beyond protecting the message - it provides a mapping=0A= between the USM-specific principal to a security-model independent=0A= securityName which can be used for subsequent processing, such as for=0A= access control.=0A= =0A= The TMSM is a two-stage security model, with a transport mapping=0A= security process (TMSP) and a security model security process (SMSP).=0A= Depending on the design of the specific TMSM model, i.e., which=0A= transport layer protocol is used, different features might be=0A= provided by the TMSP or by the SMSP. For example, the translation=0A= from a mechanism-specific authenticated identity to a securityName=0A= might be done by the TMSP or by the SMSP.=0A= =0A= The securityName MUST be bound to the mechanism-specific=0A= authenticated identity, and this mapping MUST be done before the SMSP=0A= portion of the model passes securityName to the message processing=0A= model via the processIncoming() ASI.=0A= =0A= The SNMP architecture distinguishes between messages with no=0A= authentication and no privacy (noAuthNoPriv), authentication without=0A= privacy (authNoPriv) and authentication with privacy (authPriv).=0A= Hence, the authentication of a transport layer identity plays an=0A= important role and must be considered by any TMSM, and principal=0A= authentication must be available via the transport layer security=0A= protocol.=0A= =0A= If the type of authentication provided by the transport layer (e.g.=0A= TLS) is considered adequate to secure and/or encrypt the message, but=0A= inadequate to provide the desired granularity of access control (e.g.=0A= user-based), then a second authentication (e.g., one provided by a=0A= RADIUS server) may be used to provide the authentication identity=0A= which is bound to the securityName. This approach would require a=0A= good analysis of the potential for man-in-the-middle attacks or=0A= masquerade possibilities.=0A= =0A= 2.2.2.2. Separation of Authentication and Authorization=0A= =0A= A TMSM security model should take care to not violate the separation=0A= of authentication and authorization in the RFC3411 architecture. The=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 14]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= isAccessAllowed() primitive is used for passing security-model=0A= independent parameters between the subsystems of the architecture.=0A= =0A= Mapping of (securityModel, securityName) to an access control policy=0A= should be handled within the access control subsystem, not the=0A= security subsystem, to be consistent with the modularity of the=0A= RFC3411 architecture. This separation was a deliberate decision of=0A= the SNMPv3 WG, to allow support for authentication protocols which=0A= did not provide authorization capabilities, and to support=0A= authorization schemes, such as VACM, that do not perform their own=0A= authentication.=0A= =0A= An authorization model MAY require authentication by certain=0A= securityModels and a minimum securityLevel to allow access to the=0A= data.=0A= =0A= TMSM is an enhancement for the SNMPv3 privacy and authentication=0A= provisions, but it is not a significant improvement for the=0A= authorization needs of SNMPv3. TMSM provides all the model-=0A= independent parameters for the isAccessAllowed() primitive [RFC3411].=0A= =0A= TMSM does not specify how the securityModel and securityName could be=0A= dynamically mapped to a VACM-style groupName. The mapping of=0A= (securityModel, securityName) to a groupName is a VACM-specific=0A= mechanism for naming an access control policy, and for tying the=0A= named policy to the addressing capabilities of the data modeling=0A= language (e.g. SMIv2 [RFC2578]), the operations supported, and other=0A= factors. Providing a binding outside the Access Control subsystem=0A= might create dependencies that could make it harder to develop=0A= alternate models of access control, such as one built on UNIX groups=0A= or Windows domains. The preferred approach is to pass the model-=0A= independent security parameters via the isAccessAllowed() ASI, and=0A= perform the mapping within the access control model.=0A= =0A= To provide support for protocols which simultaneously send=0A= information for authentication and authorization, such as RADIUS=0A= [RFC2865], model-specific authorization information MAY be cached or=0A= otherwise made available to the access control subsystem, e.g., via a=0A= MIB table similar to the vacmSecurityToGroupTable, so the access=0A= control subsystem can create an appropriate binding between the=0A= model-independent securityModel and securityName and a model-specific=0A= access control policy. This may be highly undesirable, however, if=0A= it creates a dependency between a security model and an access=0A= control model, just as it is undesirable that the TMSM approach=0A= creates a dependency between an SNMP message version and the security=0A= provided by a transport mapping.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 15]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 2.2.3. Security Parameter Passing Requirements=0A= =0A= RFC3411 section 4 describes primitives to describe the abstract data=0A= flows between the various subsystems, models and applications within=0A= the architecture. Abstract Service Interfaces describe the flow of=0A= data between subsystems within an engine. The ASIs generally pass=0A= model-independent information.=0A= =0A= Within an engine using a TMSM-based security model, outgoing SNMP=0A= messages are passed unencrypted from the message dispatcher to the=0A= transport mapping, and incoming messages are passed unencrypted from=0A= the transport mapping to the message dispatcher.=0A= =0A= The security parameters include a model-independent identifier of the=0A= security "principal", the security model used to perform the=0A= authentication, and which SNMP-specific security services were=0A= (should be) applied to the message (authentication and/or privacy).=0A= =0A= In the RFC3411 architecture, which reflects the USM security model=0A= design, the messaging model must 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 model-specific security=0A= parameters into model-independent parameters.=0A= =0A= In the TMSM approach, the security-model specific parameters are not=0A= carried in the SNMP message. The parameters are provided by SNMP=0A= applications for outgoing messages, and the parameters for incoming=0A= messages are extracted from the transport layer by the security-=0A= model-specific transport mapping before the message is passed to the=0A= message processing subsystem.=0A= =0A= For outgoing messages, it is necessary to have an SMSP because it is=0A= the SMSP that actually creates the message from its component parts.=0A= Whether there are any security services provided by the SMSP for an=0A= outgoing message is model-dependent.=0A= =0A= For incoming messages, there might be security functionality that can=0A= only be handled after the message version is known. The message=0A= version is determined by the Message Processing model and passed to=0A= the SMSP via the processIncoming() ASI.=0A= =0A= The RFC3411 architecture has no ASI parameters for passing security=0A= information between the transport mapping and the dispatcher, and=0A= between the dispatcher and the message processing model. If there is=0A= a need to have an SMSP called from the message processing model to,=0A= for example, verify that msgFlags and the transport security are=0A= consistent, then it will be necessary to pass the model-dependent=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 16]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= security parameters from the TMSP through to the SMSP.=0A= =0A= This document describes a cache, into which the TMSP puts information=0A= about the security applied to an incoming message, and an SMSP=0A= extracts that information from the cache. Given that there may be=0A= multiple TM-security caches, a tmSessionReference is passed as an=0A= extra parameter in the ASIs between the transport mapping and the=0A= messaging security model, so the SMSP knows which cache of=0A= information to consult.=0A= =0A= This approach does create dependencies between a model-specific TMSP=0A= and a corresponding specific SMSP. This approach of passing a model-=0A= independent reference is consistent with the securityStateReference=0A= cache already being passed around in the RFC3411 ASIs.=0A= =0A= 2.3. Session Requirements=0A= =0A= Throughout this document, the term session is used. Some underlying=0A= secure transports will have a notion of session. Some underlying=0A= secure transports might enable the use of channels or other session-=0A= like thing. In this document the term session refers to an=0A= association between two SNMP engines that permits the secure=0A= transmission of one or more SNMP messages within the lifetime of the=0A= session. How the session is actually established, opened, closed, or=0A= maintained is specific to a particular security model.=0A= =0A= Sessions are not part of the SNMP architecture described in=0A= [RFC3411], but are considered desirable because the cost of=0A= authentication can be amortized over potentially many transactions.=0A= =0A= It is important to note that the architecture described in [RFC3411]=0A= does not include a session selector in the Abstract Service=0A= Interfaces, and neither is that done for this architectural=0A= extension, so an SNMP application cannot select the session except by=0A= passing a unique combination of transport address, securityName,=0A= securityModel, and securityLevel.=0A= =0A= All TMSM-based security models should discuss the impact of sessions=0A= on SNMP usage, including how to establish/open a TMSM session (i.e.,=0A= how it maps to the concepts of session-like things of the underlying=0A= protocol), how to behave when a TMSM session cannot be established,=0A= how to close a TMSM session (and the underlying protocol equivalent)=0A= properly, how to behave when a TMSM session is closed improperly, the=0A= session security properties, session establishment overhead, and=0A= session maintenance overhead.=0A= =0A= To reduce redundancy, this document will discuss aspects that are=0A= expected to be common to all TMSM-based security model sessions.=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 17]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 2.3.1. Session Establishment Requirements=0A= =0A= SNMP applications must provide the transport address, securityName,=0A= securityModel, and securityLevel to be used for a session.=0A= =0A= SNMP Applications typically have no knowledge of whether the session=0A= that will be used to carry commands was initially established as a=0A= notification session, or a request-response session, and SHOULD NOT=0A= make any assumptions based on knowing the direction of the session.=0A= If an administrator or security model designer wants to differentiate=0A= a session established for different purposes, such as a notification=0A= session versus a request-response session, the application can use=0A= different securityNames or transport addresses (e.g., port 161 vs.=0A= port 162) for different purposes.=0A= =0A= An SNMP engine containing an application that initiates=0A= communication, e.g., a Command Generator or Notification Originator,=0A= MUST be able to attempt to establish a session for delivery if a=0A= session does not yet exist. If a session cannot be established then=0A= the message is discarded.=0A= =0A= Sessions are usually established by the transport mapping security=0A= processor when no appropriate session is found for an outgoing=0A= message, but sessions may be established in advance to support=0A= features such as notifications and call-home. How sessions are=0A= established in advance is beyond the scope of this document.=0A= =0A= Sessions are initiated by notification originators when there is no=0A= currently established connection that can be used to send the=0A= notification. For a client-server security protocol, this may=0A= require provisioning authentication credentials on the agent, either=0A= statically or dynamically, so the client/agent can successfully=0A= authenticate to a notification receiver.=0A= =0A= A TMSM-based security model must be able to determine whether a=0A= session does or does not exist, and must be able to determine which=0A= session has the appropriate security characteristics (transport=0A= address, securityName, securityModel, and securityLevel) for an=0A= outgoing message.=0A= =0A= A TMSM security model implementation MAY reuse an already established=0A= session with the appropriate transport address, securityName,=0A= securityModel, and securityLevel characteristics for delivery of a=0A= message originated by a different type of application than originally=0A= caused the session to be created. For example, an implementation=0A= that has an existing session originally established to receive a=0A= request may use that session to send an outgoing notification, and=0A= may use a session that was originally established to send a=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 18]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= notification to send a request. Responses are expected to be=0A= returned using the same session that carried the corresponding=0A= request message. Reuse is not required for conformance.=0A= =0A= If a session can be reused for a different type of message, but a=0A= receiver is not prepared to accept different message types over the=0A= same session, then the message MAY be dropped by the manager.=0A= =0A= 2.3.2. Session Maintenance Requirements=0A= =0A= A TMSM-based security model can tear down sessions as needed. It may=0A= be 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= Implementations should be careful to not tear down a session between=0A= the time a request is received and the time the response is sent.=0A= The elements of procedure for TMSM-based security models should be=0A= sure to describe the expected behavior when no session exists for a=0A= response.=0A= =0A= The elements of procedure may discuss when cached information can be=0A= discarded, and the timing of cache cleanup may have security=0A= implications, but cache memory management is an implementation issue.=0A= =0A= If a security model defines MIB module objects to maintain session=0A= state information, then the security model MUST describe what happens=0A= to the objects when a related session is torn down, since this will=0A= impact interoperability of the MIB module.=0A= =0A= 2.3.3. Message security versus session security=0A= =0A= A TMSM session is associated with state information that is=0A= maintained for its lifetime. This state information allows for the=0A= application of various security services to TMSM-based security=0A= models. Cryptographic keys established at the beginning of the=0A= session SHOULD be used to provide authentication, integrity checking,=0A= and encryption services for data that is communicated during the=0A= session. The cryptographic protocols used to establish keys for a=0A= TMSM-based security model session SHOULD ensure that fresh new=0A= session keys are generated for each session. If each session uses=0A= new session keys, then messages cannot be replayed from one session=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 19]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= to another. In addition sequence information MAY be maintained in=0A= the session which can be used to prevent the replay and reordering of=0A= messages within a session.=0A= =0A= A TMSM session will typically have a single transport address,=0A= securityName and securityLevel associated with it. If an exchange=0A= between communicating engines would require a different securityLevel=0A= or would be on behalf of a different securityName, then another=0A= session would be needed. An immediate consequence of this is that=0A= implementations should be able to maintain some reasonable number of=0A= concurrent sessions.=0A= =0A= For TMSM models, securityName is typically 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= there is not much value in using encryption for a Commander Generator=0A= to poll for non-sensitive performance data on thousands of interfaces=0A= every ten minutes; the encryption adds significant overhead to=0A= processing of the messages.=0A= =0A= Some TMSM-based security models MAY support only specific=0A= authentication and encryption services, such as requiring all=0A= messages to be carried using both authentication and encryption,=0A= regardless of the security level requested by an SNMP application.=0A= =0A= Some security models may use an underlying transport that provides a=0A= per-message requested level of authentication and encryption=0A= services. For example, if a session is created as 'authPriv', then=0A= keys for encryption could still be negotiated once at the beginning=0A= of the session. But if a message is presented to the session with a=0A= security level of authNoPriv, then that message could simply be=0A= authenticated and not encrypted within the same transport session.=0A= Whether this is possible depends on the security model and the secure=0A= transport used.=0A= =0A= If the underlying transport layer security was configurable on a per-=0A= message basis, a TMSM-based security model could have a security-=0A= model-specific MIB module with configurable maxSecurityLevel and a=0A= minSecurityLevel objects to identify the range of possible levels. A=0A= session's maxSecurityLevel would identify the maximum security it=0A= could provide, and a session created with a minSecurityLevel of=0A= authPriv would reject an attempt to send an authNoPriv message. The=0A= elements of procedure of the security model would need to describe=0A= the procedures to enable this determination.=0A= =0A= For security models that do not support variable security services in=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 20]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= one session, multiple sessions could be established with different=0A= security levels, and for every packet the SNMP engine could select=0A= the appropriate session based on the requested securityLevel. Some=0A= SNMP entities are resource-constrained. Adding sessions increases=0A= the need for resources, but so does encrypting unnecessarily.=0A= Designers of security models should consider the trade offs for=0A= resource-constrained devices.=0A= =0A= 3. Scenario Diagrams for TMSM=0A= =0A= RFC3411 section 4.6 provides scenario diagrams to illustrate how an=0A= outgoing message is created, and how an incoming message is=0A= processed. Both diagrams are incomplete, however. In section 4.6.1,=0A= the diagram doesn't show the ASI for sending an SNMP request to the=0A= network or receiving an SNMP response message from the network. In=0A= section 4.6.2, the diagram doesn't illustrate the interfaces required=0A= to receive an SNMP message from the network, or to send an SNMP=0A= message to the network.=0A= =0A= 3.1. Command Generator or Notification Originator=0A= =0A= This diagram from RFC3411 4.6.1 shows how a Command Generator or=0A= Notification Originator application [RFC3413] requests that a PDU be=0A= sent, and how the response is returned (asynchronously) to that=0A= application.=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 December 25, 2006 [Page 21]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= Command Dispatcher Message Security=0A= Generator | Processing Model=0A= | | Model |=0A= | sendPdu | | |=0A= |------------------->| | |=0A= | | prepareOutgoingMessage | |=0A= : |----------------------->| |=0A= : | | generateRequestMsg |=0A= : | |-------------------->|=0A= : | | |=0A= : | |<--------------------|=0A= : | | |=0A= : |<-----------------------| |=0A= : | | |=0A= : |------------------+ | |=0A= : | Send SNMP | | |=0A= : | Request Message | | |=0A= : | to Network | | |=0A= : | v | |=0A= : : : : :=0A= : : : : :=0A= : : : : :=0A= : | | | |=0A= : | Receive SNMP | | |=0A= : | Response Message | | |=0A= : | from Network | | |=0A= : |<-----------------+ | |=0A= : | | |=0A= : | prepareDataElements | |=0A= : |----------------------->| |=0A= : | | processIncomingMsg |=0A= : | |-------------------->|=0A= : | | |=0A= : | |<--------------------|=0A= : | | |=0A= : |<-----------------------| |=0A= | processResponsePdu | | |=0A= |<-------------------| | |=0A= | | | |=0A= =0A= =0A= =0A= 3.2. Command Responder=0A= =0A= This diagram shows how a Command Responder or Notification Receiver=0A= application registers for handling a pduType, how a PDU is dispatched=0A= to the application after an SNMP message is received, and how the=0A= Response is (asynchronously) send back to the network.=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 22]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= Command Dispatcher Message Security=0A= Responder | Processing Model=0A= | | Model |=0A= | | | |=0A= | registerContextEngineID | | |=0A= |------------------------>| | |=0A= |<------------------------| | | |=0A= | | Receive SNMP | | |=0A= : | Message | | |=0A= : | from Network | | |=0A= : |<-------------+ | |=0A= : | | |=0A= : |prepareDataElements | |=0A= : |------------------->| |=0A= : | | processIncomingMsg |=0A= : | |------------------->|=0A= : | | |=0A= : | |<-------------------|=0A= : | | |=0A= : |<-------------------| |=0A= | processPdu | | |=0A= |<------------------------| | |=0A= | | | |=0A= : : : :=0A= : : : :=0A= | returnResponsePdu | | |=0A= |------------------------>| | |=0A= : | prepareResponseMsg | |=0A= : |------------------->| |=0A= : | |generateResponseMsg |=0A= : | |------------------->|=0A= : | | |=0A= : | |<-------------------|=0A= : | | |=0A= : |<-------------------| |=0A= : | | |=0A= : |--------------+ | |=0A= : | Send SNMP | | |=0A= : | Message | | |=0A= : | to Network | | |=0A= : | v | |=0A= =0A= =0A= 4. Message Formats=0A= =0A= The syntax of an SNMP message using this Security Model adheres to=0A= the message format defined in the version-specific Message Processing=0A= Model document (for example [RFC3412]). At the time of this writing,=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 23]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= there are three defined message formats - SNMPv1, SNMPv2c, and=0A= SNMPv3. SNMPv1 and SNMPv2c have been declared Historic, so this memo=0A= only deals with SNMPv3 messages.=0A= =0A= The processing is compatible with the RFC 3412 primitives,=0A= generateRequestMsg() and processIncomingMsg(), that show the data=0A= flow between the Message Processor and the SMSP.=0A= =0A= 4.1. SNMPv3 Message Fields=0A= =0A= The SNMPv3Message SEQUENCE is defined in [RFC3412] and [RFC3416].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 24]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::=3D BEGIN=0A= =0A= SNMPv3Message ::=3D SEQUENCE {=0A= -- identify the layout of the SNMPv3Message=0A= -- this element is in same position as in SNMPv1=0A= -- and SNMPv2c, allowing recognition=0A= -- the value 3 is used for snmpv3=0A= msgVersion INTEGER ( 0 .. 2147483647 ),=0A= -- administrative parameters=0A= msgGlobalData HeaderData,=0A= -- security model-specific parameters=0A= -- format defined by Security Model=0A= msgSecurityParameters OCTET STRING,=0A= msgData ScopedPduData=0A= }=0A= =0A= HeaderData ::=3D SEQUENCE {=0A= msgID INTEGER (0..2147483647),=0A= msgMaxSize INTEGER (484..2147483647),=0A= =0A= msgFlags OCTET STRING (SIZE(1)),=0A= -- .... ...1 authFlag=0A= -- .... ..1. privFlag=0A= -- .... .1.. reportableFlag=0A= -- Please observe:=0A= -- .... ..00 is OK, means noAuthNoPriv=0A= -- .... ..01 is OK, means authNoPriv=0A= -- .... ..10 reserved, MUST NOT be used.=0A= -- .... ..11 is OK, means authPriv=0A= =0A= msgSecurityModel INTEGER (1..2147483647)=0A= }=0A= =0A= ScopedPduData ::=3D CHOICE {=0A= plaintext ScopedPDU,=0A= encryptedPDU OCTET STRING -- encrypted scopedPDU value=0A= }=0A= =0A= ScopedPDU ::=3D SEQUENCE {=0A= contextEngineID OCTET STRING,=0A= contextName OCTET STRING,=0A= data ANY -- e.g., PDUs as defined in [RFC3416]=0A= }=0A= END=0A= =0A= =0A= The following describes how any TMSM model SHOULD treat certain=0A= fields in the message:=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 25]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 4.1.1. msgGlobalData=0A= =0A= msgGlobalData is opaque to a TMSM security model. The values are set=0A= by the Message Processing model (e.g., SNMPv3 Message Processing),=0A= and SHOULD NOT be modified by a TMSM security model.=0A= =0A= The msgSecurityModel field should be set by the Message Processing=0A= model to a value from the SnmpSecurityModel enumeration [RFC3411] to=0A= identify the specific TMSM model. Each standards-track TMSM model=0A= should have an enumeration assigned by IANA. Each enterprise-=0A= specific security model should have an enumeration assigned following=0A= instructions in the description of the SnmpSecurityModel TEXTUAL-=0A= CONVENTION from RFC3411.=0A= =0A= The msgFlags have the same values for a TMSM model as for the USM=0A= model.=0A= =0A= 4.1.1.1. securityLevel and msgFlags=0A= =0A= For an outgoing message, msgFlags is the requested security for the=0A= message; if a TMSM cannot provide the requested securityLevel, the=0A= model MUST describe a standard behavior that is followed for that=0A= situation. If the TMSM cannot provide at least the requested level=0A= of security, the TMSM MUST discard the request and SHOULD notify the=0A= message processing model that the request failed.=0A= =0A= For an outgoing message, if the TMSM is able to provide stronger than=0A= requested security, that may be acceptable. The transport layer=0A= protocol would need to indicate to the receiver what security has=0A= been applied to the actual message. To avoid the need to mess with=0A= the ASN.1 encoding, the SNMPv3 message carries the requested=0A= msgFlags, not the actual securityLevel applied to the message. If a=0A= message format other than SNMPv3 is used, then the new message may=0A= carry the more accurate securityLevel in the SNMP message.=0A= =0A= For an incoming message, the receiving TMSM knows what must be done=0A= to process the message based on the transport layer mechanisms. If=0A= the underlying transport security mechanisms for the receiver cannot=0A= provide the matching securityLevel, then the message should follow=0A= the standard behaviors for the transport security mechanism, or be=0A= discarded silently.=0A= =0A= Part of the responsibility of the TMSM is to ensure that the actual=0A= security provided by the underlying transport layer security=0A= mechanisms is configured to meet or exceed the securityLevel required=0A= by the msgFlags in the SNMP message. When the SMSP processes the=0A= incoming message, it should compare the msgFlags field to the=0A= securityLevel actually provided for the message by the transport=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 26]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= layer security. If they differ, the SMSP should determine whether=0A= the changed securityLevel is acceptable. If not, it should discard=0A= the message. Depending on the model, the SMSP may issue a reportPDU=0A= with a model-specific counter.=0A= =0A= 4.1.2. msgSecurityParameters=0A= =0A= The field msgSecurityParameters carries model-dependent security=0A= information between engines. When a security model does not utilize=0A= this field, its value MUST be the BER serialization of a zero-length=0A= OCTET STRING, to prevent its being used in a manner that could be=0A= damaging, such as for carrying a virus or worm.=0A= =0A= RFC3412 defines two primitives, generateRequestMsg() and=0A= processIncomingMsg() which require the specification of an=0A= authoritative SNMP entity. The meaning of authoritative is model=0A= dependent.=0A= =0A= 5. Cached Information and References=0A= =0A= he 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 must flow between=0A= subsystems. For most TMSM models, there are two levels of state that=0A= need to be maintained: the session state, and the message security=0A= state.=0A= =0A= 5.1. tmSessionReference Cached Session Data=0A= =0A= The tmSessionReference is used to pass references to the appropriate=0A= session information between the TMSP and SMSP through the ASIs.=0A= =0A= The TMSP may provide only some aspects of security, and leave some=0A= aspects to the SMSP. tmSessionReference should be used to pass any=0A= parameters, in a model- and mechanism-specific format, that will be=0A= needed to coordinate the activities of the TMSP and SMSP, plus the=0A= parameters subsequently passed in securityStateReference.=0A= =0A= The security model has the responsibility for explicitly releasing=0A= the complete tmSessionReference and possibly deleting the associated=0A= LCD information when the session is destroyed.=0A= =0A= 5.2. securityStateReference Cached Security Data=0A= =0A= From RFC3411: "For each message received, the Security Model caches=0A= the state information such that a Response message can be generated=0A= using the same security information, even if the Local Configuration=0A= Datastore is altered between the time of the incoming request and the=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 27]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= outgoing response.=0A= =0A= A Message Processing Model has the responsibility for explicitly=0A= releasing the cached data if such data is no longer needed. To=0A= enable this, an abstract securityStateReference data element is=0A= passed from the Security Model to the Message Processing Model. The=0A= cached security data may be implicitly released via the generation of=0A= a response, or explicitly released by using the stateRelease=0A= primitive, as described in RFC3411 section 4.5.1."=0A= =0A= For the TMSM approach, the TMSP may need to provide the information=0A= to be stored in the securityStateReference to the message processing=0A= model. such as the security-model-independent securityName,=0A= securityLevel, and securityModel parameters, and the transport=0A= address, and transport type. For responses, the messaging model may=0A= need to pass the parameters back to the TMSP.=0A= =0A= This document will differentiate the tmSessionReference provided by=0A= the TMSP to the SMSP, from the securityStateReference provided by the=0A= SMSP to the Dispatcher. This document does not specify an=0A= implementation strategy, only an abstract discussion of the data that=0A= must flow between subsystems. An implementation MAY 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 the transport mapping has had an opportunity to=0A= extract the information it needs.=0A= =0A= 6. Abstract Service Interfaces for TMSM=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. TMSM security models use some of these conceptual data=0A= flows when communicating between subsystems, such as the dispatcher=0A= and the Message Processing Subsystem.=0A= =0A= To simplify the elements of procedure, the release of state=0A= information is not always explicitly specified. As a general rule,=0A= if state information is available when a message gets discarded, the=0A= message-state information should also be released, and if state=0A= information is available when a session is closed, the session state=0A= information should also be released.=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 28]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 6.1. Generating an Outgoing SNMP Message=0A= =0A= This section describes the procedure followed by an RFC3411-=0A= compatible system whenever it generates a message containing a=0A= management operation (such as a request, a response, a notification,=0A= or a report) on behalf of a user.=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 tmSessionReference=0A= )=0A= =0A= Note that tmSessionReference has been added to this ASI.=0A= =0A= The IN parameters of the prepareOutgoingMessage() ASI are used to=0A= pass information from the dispatcher (for the application subsystem)=0A= to the message processing subsystem.=0A= =0A= The abstract service primitive from a Message Processing Model to a=0A= Security Model to generate the components of a Request message is=0A= generateRequestMsg().=0A= =0A= The abstract service primitive from a Message Processing Model to a=0A= Security Model to generate the components of a Response message is=0A= generateResponseMsg().=0A= =0A= Upon completion of the SMSP processing, the Security model returns=0A= statusInformation. If the process was successful, the completed=0A= message is returned. If the process was not successful, then an=0A= errorIndication is returned.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 29]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= The OUT parameters of the prepareOutgoingMessage() ASI are used to=0A= pass information from the message processing model to the dispatcher=0A= and on to the transport mapping:=0A= =0A= 6.2. TMSP for an Outgoing Message=0A= =0A= The sendMessage ASI is used to pass a message from the Dispatcher to=0A= the appropriate transport mapping for sending.=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 tmSessionReference=0A= )=0A= =0A= The Transport Mapping Security Model provides the following=0A= primitives to pass data back and forth between the TMSM and specific=0A= TMSM-based security models, which provide the interface to the=0A= underlying secure transport service. Each TMSM-based security model=0A= should define the security-model-specific elements of procedure for=0A= the openSession() and closeSession() interfaces.=0A= =0A= statusInformation =3D=0A= openSession(=0A= IN transportDomain -- transport domain to be used=0A= IN transportAddress -- transport address to be used=0A= IN tmSessionReference=0A= )=0A= =0A= =0A= statusInformation =3D=0A= closeSession(=0A= IN tmSessionReference=0A= )=0A= =0A= =0A= 6.3. Processing an Incoming SNMP Message=0A= =0A= 6.3.1. TMSP for an Incoming Message=0A= =0A= If one does not exist, the TMSP will need to create an entry in a=0A= Local Configuration Datastore referenced by tmSessionReference. This=0A= information will include transportDomain, transportAddress, the=0A= securityModel, the securityLevel, and the securityName, plus any=0A= model or mechanism-specific details. How this information is=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 30]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= determined is model-specific.=0A= =0A= The recvMessage ASI is used to pass a message from the transport=0A= mapping to the Dispatcher.=0A= =0A= statusInformation =3D=0A= recvMessage(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN incomingMessage -- the message received=0A= IN incomingMessageLength -- its length=0A= IN tmSessionReference=0A= )=0A= =0A= 6.3.2. Prepare Data Elements from Incoming Messages=0A= =0A= The abstract service primitive from the Dispatcher to a Message=0A= Processing Model for a received message is:=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 tmSessionReference -- from the transport mapping=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= Note that tmSessionReference has been added to this ASI.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 31]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 6.3.3. MPSP for an Incoming Message=0A= =0A= This section describes the procedure followed by the SMSP whenever it=0A= receives an incoming message containing a management operation on=0A= behalf of a user from a Message Processing model.=0A= =0A= The Message Processing Model extracts some information from the=0A= wholeMsg. The abstract service primitive from a Message Processing=0A= Model to the Security Subsystem for a received message is::=0A= =0A= statusInformation =3D -- errorIndication or success=0A= -- error counter OID/value if error=0A= processIncomingMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN maxMessageSize -- 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 tmSessionReference -- from the transport mapping=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= 1) The securityEngineID is set to a value in a model-specific manner.=0A= If the securityEngineID is not utilized by the specific model, then=0A= it should be set to the local snmpEngineID, to satisfy the SNMPv3=0A= message processing model in RFC 3412 section 7.2 13a).=0A= =0A= 2) Extract the value of securityName from the Local Configuration=0A= Datastore entry referenced by tmSessionReference.=0A= =0A= 3) The scopedPDU component is extracted from the wholeMsg.=0A= =0A= 4) The maxSizeResponseScopedPDU is calculated. This is the maximum=0A= size allowed for a scopedPDU for a possible Response message.=0A= =0A= 5)The security data is cached as cachedSecurityData, so that a=0A= possible response to this message can and will use the same security=0A= parameters. Then securityStateReference is set for subsequent=0A= reference to this cached data.=0A= =0A= 4) The statusInformation is set to success and a return is made to=0A= the calling module passing back the OUT parameters as specified in=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 32]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= the processIncomingMsg primitive.=0A= =0A= 7. The TMSM MIB Module=0A= =0A= This memo defines a portion of the Management Information Base (MIB)=0A= for statistics in the Transport Mapping Security Model extension.=0A= =0A= 7.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= 7.1.1. The tmsmStats Subtree=0A= =0A= This subtree contains security-model-independent counters which are=0A= applicable to all security models based on the .Transport Mapping=0A= Security Model extension. This subtree provides information for=0A= identifying fault conditions and performance degradation.=0A= =0A= 7.2. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing this MIB. In particular, it is assumed=0A= that an entity implementing the TMSM-MIB module will also implement=0A= the SNMPv2-MIB [RFC3418].=0A= =0A= This MIB module is expected to be used with the MIB modules defined=0A= for managing specific security models that are based on the TMSM=0A= extension. This MIB module is designed to be security-model=0A= independent, and contains objects useful for managing common aspects=0A= of any TMSM-based security model. Specific security models may=0A= define a MIB module to contain security-model-dependent information.=0A= =0A= 7.2.1. Textual Conventions=0A= =0A= Generic and Common Textual Conventions used in this document can be=0A= found summarized at http://www.ops.ietf.org/mib-common-tcs.html=0A= =0A= 7.2.2. MIB Modules Required for IMPORTS=0A= =0A= The. following MIB module imports items from [RFC2578], [RFC2579],=0A= [RFC2580], [RFC3411], and [RFC3419]=0A= =0A= 7.3. Definitions=0A= =0A= TMSM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 33]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= mib-2, Integer32, Unsigned32, Gauge32=0A= FROM SNMPv2-SMI=0A= TestAndIncr, StorageType, RowStatus=0A= FROM SNMPv2-TC=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= SnmpSecurityModel,=0A= SnmpAdminString, SnmpSecurityLevel, SnmpEngineID=0A= FROM SNMP-FRAMEWORK-MIB=0A= TransportAddress, TransportAddressType=0A= FROM TRANSPORT-ADDRESS-MIB=0A= ;=0A= =0A= tmsmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200604200000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= quittek@netlab.nec.de=0A= =0A= Juergen Schoenwaelder=0A= International University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Editor:=0A= David Harrington=0A= FutureWei Technologies=0A= 1700 Alma Drive, Suite 100=0A= Plano, Texas 75075=0A= USA=0A= +1 603-436-8634=0A= dharrington@huawei.com=0A= "=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 34]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= DESCRIPTION "The Transport Mapping Security Model=0A= MIB Module=0A= =0A= Copyright (C) The Internet Society (2006). This=0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200604200000Z" -- 20 April 2006=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- ---------------------------------------------------------- --=0A= -- subtrees in the TMSM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= tmsmNotifications OBJECT IDENTIFIER ::=3D { tmsmMIB 0 }=0A= tmsmObjects OBJECT IDENTIFIER ::=3D { tmsmMIB 1 }=0A= tmsmConformance OBJECT IDENTIFIER ::=3D { tmsmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= -- Textual Conventions=0A= =0A= -- Notifications for the Transport Model Security Model extension=0A= =0A= -- Statistics for the Transport Model Security Model extension=0A= =0A= =0A= tmsmStats OBJECT IDENTIFIER ::=3D { tmsmObjects 1 }=0A= =0A= tmsmSessionOpenErrors OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a Session.=0A= "=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 35]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= ::=3D { tmsmStats 1 }=0A= =0A= tmsmSessionNoAvailableSessions OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times a Response message=0A= was dropped because the corresponding=0A= session was no longer available.=0A= "=0A= ::=3D { tmsmStats 2 }=0A= =0A= -- The tmsmSession Group=0A= =0A= tmsmSession OBJECT IDENTIFIER ::=3D { tmsmObjects 2 }=0A= =0A= tmsmSessionCurrent OBJECT-TYPE=0A= SYNTAX Gauge32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The current number of open sessions.=0A= "=0A= ::=3D { tmsmSession 1 }=0A= =0A= tmsmSessionMaxSupported OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The maximum number of open sessions supported.=0A= The value zero indicates the maximum is dynamic.=0A= "=0A= ::=3D { tmsmSession 2 }=0A= =0A= tmsmSessionOpenErrors OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a Session.=0A= "=0A= ::=3D { tmsmSession 3 }=0A= =0A= tmsmSessionSecurityLevelNotAvailableErrors OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an outgoing message was=0A= discarded because a requested securityLevel could not=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 36]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= provided.=0A= "=0A= ::=3D { tmsmSession 4 }=0A= =0A= =0A= -- -------------------------------------------------------------=0A= -- tmsmMIB - Conformance Information=0A= -- -------------------------------------------------------------=0A= =0A= tmsmGroups OBJECT IDENTIFIER ::=3D { tmsmConformance 1 }=0A= =0A= tmsmCompliances OBJECT IDENTIFIER ::=3D { tmsmConformance 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Units of conformance=0A= -- -------------------------------------------------------------=0A= tmsmGroup OBJECT-GROUP=0A= OBJECTS {=0A= tmsmSessionOpenErrors,=0A= tmsmSessionSecurityLevelNotAvailableErrors,=0A= tmsmSessionCurrent,=0A= tmsmSessionMaxSupported,=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining session=0A= information of an SNMP engine which implements the=0A= TMSM architectural extension.=0A= "=0A= =0A= ::=3D { tmsmGroups 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Compliance statements=0A= -- -------------------------------------------------------------=0A= =0A= tmsmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for SNMP engines that support the=0A= TMSM-MIB"=0A= MODULE=0A= MANDATORY-GROUPS { tmsmGroup }=0A= ::=3D { tmsmCompliances 1 }=0A= =0A= END=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 37]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 8. Security Considerations=0A= =0A= This document describes an architectural approach and multiple=0A= proposed configurations that would permit SNMP to utilize transport=0A= layer security services. Each section containing a proposal should=0A= discuss the security considerations of that approach.=0A= =0A= It is considered desirable by some industry segments that SNMP=0A= security 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.=0A= =0A= There are no management objects defined in this MIB module that have=0A= a MAX-ACCESS clause of read-write and/or read-create. So, if this=0A= MIB module is implemented correctly, then there is no risk that an=0A= intruder can alter or create any management objects of this MIB=0A= module via direct SNMP SET operations.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= o [todo] list the tables and objects and state why they are=0A= sensitive.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPSec),=0A= even then, there is no control as to who on the secure network is=0A= allowed to access and GET/SET (read/change/create/delete) the objects=0A= in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410], section 8),=0A= including full support for the SNMPv3 cryptographic mechanisms (for=0A= authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 38]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 9. IANA Considerations=0A= =0A= The MIB module in this document uses the following IANA-assigned=0A= OBJECT IDENTIFIER values recorded in the SMI Numbers registry:=0A= =0A= =0A= Descriptor OBJECT IDENTIFIER value=0A= ---------- -----------------------=0A= =0A= tmsmMIB { mib-2 XXXX }=0A= =0A= Editor's Note (to be removed prior to publication): the IANA is=0A= requested to assign a value for "XXXX" under the 'mib-2' subtree=0A= and to record the assignment in the SMI Numbers registry. When=0A= the assignment has been made, the RFC Editor is asked to replace=0A= "XXXX" (here and in the MIB module) with the assigned value and to=0A= remove this note.=0A= =0A= 10. 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, Dave Harrington, Keith McCloghrie, Kaushik Narayan, Dave=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= 11. References=0A= =0A= 11.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,=0A= and T. Wright, "Transport Layer Security (TLS)=0A= Extensions", RFC 4366, April 2006.=0A= =0A= [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Structure of Management Information=0A= Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 39]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Textual Conventions for SMIv2",=0A= STD 58, RFC 2579, April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,=0A= "Conformance Statements for SMIv2", STD 58, RFC 2580,=0A= April 1999.=0A= =0A= [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,=0A= "Remote Authentication Dial In User Service (RADIUS)",=0A= RFC 2865, June 2000.=0A= =0A= [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An=0A= Architecture for Describing Simple Network Management=0A= Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,=0A= December 2002.=0A= =0A= [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,=0A= "Message Processing and Dispatching for the Simple Network=0A= Management Protocol (SNMP)", STD 62, RFC 3412,=0A= December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model=0A= (USM) for version 3 of the Simple Network Management=0A= Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.=0A= =0A= [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the=0A= Simple Network Management Protocol (SNMP)", STD 62,=0A= RFC 3416, December 2002.=0A= =0A= [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network=0A= Management Protocol (SNMP)", STD 62, RFC 3417,=0A= December 2002.=0A= =0A= [RFC3418] Presuhn, R., "Management Information Base (MIB) for the=0A= Simple Network Management Protocol (SNMP)", STD 62,=0A= RFC 3418, December 2002.=0A= =0A= [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for=0A= Transport Addresses", RFC 3419, December 2002.=0A= =0A= [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)=0A= Protocol Architecture", RFC 4251, January 2006.=0A= =0A= 11.2. Informative References=0A= =0A= [RFC3410] Case, J., Mundy, R., Partain, D., and B.=0A= Stewart, "Introduction and Applicability=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 40]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= Statements for Internet-Standard Management=0A= Framework", RFC 3410, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple=0A= Network Management Protocol (SNMP)=0A= Applications", STD 62, RFC 3413,=0A= December 2002.=0A= =0A= [RFC4422] Melnikov, A. and K. Zeilenga, "Simple=0A= Authentication and Security Layer (SASL)",=0A= RFC 4422, June 2006.=0A= =0A= [I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the=0A= NETCONF Configuration Protocol over Secure=0A= Shell (SSH)", draft-ietf-netconf-ssh-06 (work=0A= in progress), March 2006.=0A= =0A= Appendix A. Parameter Table=0A= =0A= Following is a CSV formatted matrix useful for tracking data flows=0A= into and out of the dispatcher, message, and security subsystems.=0A= Import this into your favorite spreadsheet or other CSV compatible=0A= application. You will need to remove lines feeds from the second and=0A= third lines, which needed to be wrapped to fit into RFC limits.=0A= =0A= A.1. ParameterList.csv=0A= =0A= ,Dispatcher,,,,Messaging,,,Security,,=0A= =0A= ,sendPdu,returnResponse,processPdu,processResponse=0A= ,prepareOutgoingMessage,prepareResponseMessage,prepareDataElements=0A= ,generateRequest,processIncoming,generateResponse=0A= =0A= transportDomain,In,,,,In,,In,,,=0A= =0A= transportAddress,In,,,,In,,In,,,=0A= =0A= destTransportDomain,,,,,Out,Out,,,,=0A= =0A= destTransportAddress,,,,,Out,Out,,,,=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= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 41]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =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,,Out,In,Out=0A= =0A= messageLength,,,,,Out,Out,,Out,In,Out=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,,Out=0A= =0A= securityStateReference,,,,,,,,,Out,In=0A= =0A= pduType,,,,,,,Out,,,=0A= =0A= tmSessionReference,,,,,,Out,In,,In,=0A= =0A= Appendix B. Why tmSessionReference?=0A= =0A= This appendix considers why a cache-based approach was selected for=0A= passing parameters. This section may be removed from subsequent=0A= revisions of the document.=0A= =0A= There are four approaches that could be used for passing information=0A= between the TMSP and an SMSP.=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 42]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= 1. one could define an ASI to supplement the existing ASIs, or=0A= 2. the TMSM could add a header to encapsulate the SNMP message,=0A= 3. the TMSM could utilize fields already defined in the existing=0A= SNMPv3 message, or=0A= 4. the TMSM 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) [RFC3411] are defined by a set of=0A= primitives that specify the services provided and the abstract data=0A= elements that are to be passed when the services are invoked.=0A= Defining additional ASIs to pass the security and transport=0A= information from the transport mapping to a messaging security model=0A= has the advantage of being consistent with existing RFC3411/3412=0A= practice, and helps to ensure that any TMSM proposals pass the=0A= necessary data, and do not cause side effects by creating model-=0A= specific dependencies between itself and other models or other=0A= subsystems other than those 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 TMSP to the dispatcher and then to a messaging=0A= security model. The message header would be included in the=0A= wholeMessage ASI parameter, and would be removed by a corresponding=0A= messaging model. This would imply the (one and only) messaging=0A= dispatcher would need to be modified to determine which SNMP message=0A= version was involved, and a new message processing model would need=0A= to be developed that knew how to extract the header from the message=0A= and pass it to the SMSP.=0A= =0A= B.3. Modifying Existing Fields in an SNMP Message=0A= =0A= [RFC3412] describes the SNMPv3 message, which contains fields to pass=0A= security related parameters. The TMSM could use these fields in an=0A= SNMPv3 message, or comparable fields in other message formats to pass=0A= information between transport mapping security models in different=0A= SNMP engines, and to pass information between a transport mapping=0A= security model and a corresponding messaging security model.=0A= =0A= If the fields in an incoming SNMPv3 message are changed by the TMSP=0A= before passing it to the SMSP, then the TMSP will need to decode the=0A= ASN.1 message, modify the fields, and re-encode the message in ASN.1=0A= before passing the message on to the message dispatcher or to the=0A= transport layer. This would require an intimate knowledge of the=0A= message format and message versions so the TMSP knew which fields=0A= could be modified. This would seriously violate the modularity of=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 43]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= the architecture.=0A= =0A= B.4. Using a Cache=0A= =0A= This document describes a cache, into which the TMSP puts information=0A= about the security applied to an incoming message, and an SMSP=0A= extracts that information from the cache. Given that there may be=0A= multiple TM-security caches, a tmSessionReference is passed as an=0A= extra parameter in the ASIs between the transport mapping and the=0A= messaging security model, so the SMSP knows which cache of=0A= information to consult.=0A= =0A= This approach does create dependencies between a model-specific TMSP=0A= and a corresponding specific SMSP. This approach of passing a model-=0A= independent reference is consistent with the securityStateReference=0A= cache already being passed around in the RFC3411 ASIs.=0A= =0A= Appendix C. Open Issues=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 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= * 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= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 44]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =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 TMSM 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 TMSM-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= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 45]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=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= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires December 25, 2006 [Page 46]=0A= =0C=0A= Internet-Draft SNMP Transport Mapping Security Model June 2006=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2006).=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 AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= 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 December 25, 2006 [Page 47]=0A= =0C=0A= =0A= ------=_NextPart_000_010C_01C69947.0F38DB70 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_010C_01C69947.0F38DB70-- From isms-bounces@lists.ietf.org Mon Jul 03 18:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWxr-0008Ke-OB; Mon, 03 Jul 2006 18:32:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWxr-0008KZ-8T for isms@ietf.org; Mon, 03 Jul 2006 18:32:23 -0400 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxWxq-0003Be-14 for isms@ietf.org; Mon, 03 Jul 2006 18:32:23 -0400 Received: from h-68-166-188-226.snvacaid.dynamic.covad.net ([68.166.188.226] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FxWxp-00030f-00 for isms@ietf.org; Mon, 03 Jul 2006 18:32:21 -0400 Message-ID: <000401c69ef0$9d3d0780$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20060702201418.GA4772@boskop.local> <001601c69e63$24a23940$6501a8c0@oemcomputer> <20060703061838.GA5200@boskop.local> <000a01c69e70$96871a00$6501a8c0@oemcomputer> <20060703080509.GA5419@boskop.local> Subject: Re: [Isms] SNMP "access control" terminology Date: Mon, 3 Jul 2006 15:32:48 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Monday, July 03, 2006 1:05 AM > Subject: Re: [Isms] SNMP "access control" terminology ... > In the USM world, the underlying assumption has been that successful > authentication implies authorization to talk to the managed device and > you have to delete an USM user to essentially deny authorization to > talk to the managed device. With RADIUS in place, you can drop the > authorization without deleting the authentication for a given user > which makes sense since the same user may very well be authenticated > and authorized to use other services. Sure, you can try to configure > the ACM to ensure that all users who can be authenticated (might be a > large number) and who are not authorized to use the service can't get > any service. But practically speaking from my system administration > experience, I would prefer to drop unauthorized users as early as > possible (and not only because of DOS attacks and resource usage but > more practically speaking also for the risks associated with software > bugs and not-as-good ACM configurations that might be around). ... It's important to remember that in VACM, the only access control model we have, if a user has no entry in the vacmSecurityToGroupTable [RFC 3415], then no operations of any kind are permitted. I haven't been able to think of a reason why one might want to create VACM entries for users who have no access rights to a system. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 06 07:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySLq-0001L0-IQ; Thu, 06 Jul 2006 07:48:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySLq-0001Kv-87 for isms@ietf.org; Thu, 06 Jul 2006 07:48:58 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FySLo-00080i-Pm for isms@ietf.org; Thu, 06 Jul 2006 07:48:58 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A7C9B55F56; Thu, 6 Jul 2006 13:48:55 +0200 (CEST) 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 31885-01; Thu, 6 Jul 2006 13:48:53 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id ADE5455F83; Thu, 6 Jul 2006 13:48:51 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id EFC3D7821EE; Thu, 6 Jul 2006 13:48:49 +0200 (CEST) Date: Thu, 6 Jul 2006 13:48:49 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] SNMP "access control" terminology Message-ID: <20060706114849.GB10556@boskop.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <20060702201418.GA4772@boskop.local> <001601c69e63$24a23940$6501a8c0@oemcomputer> <20060703061838.GA5200@boskop.local> <000a01c69e70$96871a00$6501a8c0@oemcomputer> <20060703080509.GA5419@boskop.local> <000401c69ef0$9d3d0780$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401c69ef0$9d3d0780$6501a8c0@oemcomputer> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Mon, Jul 03, 2006 at 03:32:48PM -0700, Randy Presuhn wrote: > It's important to remember that in VACM, the only access control model > we have, if a user has no entry in the vacmSecurityToGroupTable [RFC 3415], > then no operations of any kind are permitted. Why should a user who is not authorized to use the system be allowed to create and keep an open SSH session? And why should such a user be allowed to send SNMP packets even if they will return just exceptions? I consider an SSH connection establishment failure a clearer signal that someone is not authorized to talk to a system than letting the establishment of the secure channel succeed and then get just application layer access exceptions. > I haven't been able to think of a reason why one might want to > create VACM entries for users who have no access rights to a system. You might have VACM entries for users which currently do not have authorization to access the agents but which had authorization in the past (and which might get it again in the future - e.g. a third party company helping an organization to manage boxes). But yes, there are surely different approaches to deal with this today. (Either you change the security name to group name mapping or you change the USM password, which means to deny authentication and entrance into the system - it might be interesting to find out what operators actually do in such cases - or whether such cases exist at all in reality). The motivation for RADIUS is to be able to control from a centralized system which authenticated user has the right to manage a device. Another motivation was to be able to control from a centralized system which role an authenticated user has once he is allowed to access a device. Both are related in the sense that being able to map an authenticated user into a "noaccess" role/group may achieve the first requirement but I think both share the same fundamental problem that we would need to get information from RADIUS for already authenticated users if we consider the case where authentication is not done via RADIUS. I also believe that the desire to get centralized authorization information is actually not limited to ISMS but equally applies to NETCONF and other protocols that are able to authenticate users via backend systems that do not provide authorization information. Since an authorize only solution requires support from RADEXT, I would prefer to not get ISMS blocked due to this particular feature. Still, I think we should try to find agreement what authorization means architecturally in the context of SNMP and TMSM next week. /js -- Juergen Schoenwaelder International 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 Thu Jul 06 08:13:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySjp-00088y-85; Thu, 06 Jul 2006 08:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySjo-00088t-6V for isms@ietf.org; Thu, 06 Jul 2006 08:13:44 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FySjl-0001av-TS for isms@ietf.org; Thu, 06 Jul 2006 08:13:44 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2006 05:13:41 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k66CDfLT013120; Thu, 6 Jul 2006 05:13:41 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k66CDeke028171; Thu, 6 Jul 2006 05:13:41 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp473.cisco.com [10.61.65.217]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k66C85Wj004735; Thu, 6 Jul 2006 05:08:06 -0700 Message-ID: <44ACFE72.3090203@cisco.com> Date: Thu, 06 Jul 2006 14:13:38 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Randy Presuhn , isms@ietf.org Subject: Re: [Isms] SNMP "access control" terminology References: <20060702201418.GA4772@boskop.local> <001601c69e63$24a23940$6501a8c0@oemcomputer> <20060703061838.GA5200@boskop.local> <000a01c69e70$96871a00$6501a8c0@oemcomputer> <20060703080509.GA5419@boskop.local> <000401c69ef0$9d3d0780$6501a8c0@oemcomputer> <20060706114849.GB10556@boskop.local> In-Reply-To: <20060706114849.GB10556@boskop.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1700; t=1152188021; x=1153052021; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Isms]=20SNMP=20=22access=20control=22=20terminology; X=v=3Dcisco.com=3B=20h=3Dic+XAnccSdyxfLPf2nUnBtcpd5M=3D; b=YYV8eLKU28Pi7uRU2K5yCknDN9voQrrFCuUCpiNsy80Y6VrXWSU+juae7AApAsf9wO/iLlZK 6V3umEcXkSDIdhlBmg2RP1Ns/RUS0ZBYJM7m0jWv20ppF8GquocydGw/; X-Spam-Score: 0.0 (/) 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 Juergen Schoenwaelder wrote: > Why should a user who is not authorized to use the system be allowed > to create and keep an open SSH session? And why should such a user be > allowed to send SNMP packets even if they will return just exceptions? > Right. > I consider an SSH connection establishment failure a clearer signal > that someone is not authorized to talk to a system than letting the > establishment of the secure channel succeed and then get just > application layer access exceptions. > There are two analogies that can be applied, each of them to some degree or another valid: 1. The UNIX "Permission Denied" error, which doesn't tell you why permission was denied, but simply that it was. This is very similar to USM, and has the benefit of not providing many clues to a potential attacker, in and of itself. 2. The dual model of a session and an action, where someone is authenticated and authorized for two-way communications and is separately authenticated for specific actions. A level of trust is associated with this that someone who is authenticating will not try to do bad things. That trust only has to extend so far, however, because actions can be audited. To get to (1) one needs to take the intersection of sets of those allowed to login, in this case held in an external database, and those authorized to access certain objects, still held in VACM. That would require some sort of callout to the SNMP subsystem from the SSH subsystem that assuredly does not exist today. Moreover it shouldn't. It's simple enough to indicate by port and authentication attribute or server the use of the connection. Eliot > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 06 09:55:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUKM-00073P-SC; Thu, 06 Jul 2006 09:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUKL-00073B-AO for isms@ietf.org; Thu, 06 Jul 2006 09:55:33 -0400 Received: from mga03.intel.com ([143.182.124.21] helo=azsmga101-1.ch.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyUKI-0005gb-RS for isms@ietf.org; Thu, 06 Jul 2006 09:55:33 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 06 Jul 2006 06:55:30 -0700 Received: from fmsmsx331.fm.intel.com (HELO fmsmsx331.amr.corp.intel.com) ([132.233.42.156]) by azsmga001.ch.intel.com with ESMTP; 06 Jul 2006 06:54:41 -0700 X-IronPort-AV: i="4.06,213,1149490800"; d="scan'208"; a="62077568:sNHT2394375865" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 06:54:40 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 06:54:40 -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] SNMP "access control" terminology Date: Thu, 6 Jul 2006 09:54:31 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E70405641B18F@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] SNMP "access control" terminology thread-index: Acag8i8KazP7Bi2SRlu8oHRGqBKoCgAEMdLw From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 06 Jul 2006 13:54:40.0578 (UTC) FILETIME=[BA188220:01C6A103] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 >> It's important to remember that in VACM, the only access control model >> we have, if a user has no entry in the vacmSecurityToGroupTable [RFC 3415], >> then no operations of any kind are permitted. > >Why should a user who is not authorized to use the system be allowed >to create and keep an open SSH session? And why should such a user be >allowed to send SNMP packets even if they will return just exceptions? Because he is allowed to login as a system user, and you opted for a common auth strategy? So he's perfectly OK to login via SSH, but not OK to use SNMP? >I consider an SSH connection establishment failure a clearer signal >that someone is not authorized to talk to a system than letting the >establishment of the secure channel succeed and then get just >application layer access exceptions. If you aren't allowed SSH - clearly you aren't allowed SSH-based SNMP. The reverse isn't true. >> I haven't been able to think of a reason why one might want to >> create VACM entries for users who have no access rights to a system. > >You might have VACM entries for users which currently do not have >authorization to access the agents but which had authorization in the >past (and which might get it again in the future - e.g. a third party >company helping an organization to manage boxes). No. Such users would be removed as their authorization expires. It is *extremely* poor security to leave the credentials (access rights) in, and just "turn the login off". >The motivation for RADIUS is to be able to control from a centralized >system which authenticated user has the right to manage a device. The danger is - local and central repositories of users diverging.=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 06 10:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUpV-0000xo-Fy; Thu, 06 Jul 2006 10:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUpU-0000xj-BN for isms@ietf.org; Thu, 06 Jul 2006 10:27:44 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyUpO-0007II-1t for isms@ietf.org; Thu, 06 Jul 2006 10:27:44 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:27:37 -0400 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] SNMP "access control" terminology Date: Thu, 6 Jul 2006 10:27:36 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021932D@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] SNMP "access control" terminology Thread-Index: Acag8i8KazP7Bi2SRlu8oHRGqBKoCgAEMdLwAAEpgqA= From: "Nelson, David" To: X-OriginalArrivalTime: 06 Jul 2006 14:27:37.0514 (UTC) FILETIME=[547100A0:01C6A108] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Uri Blumenthal writes... > >The motivation for RADIUS is to be able to control from a centralized > >system which authenticated user has the right to manage a device. >=20 > The danger is - local and central repositories of users diverging. How is this different from NIS vs. /etc/passwd? My experience in enterprise environments is that the "real" users exist in NIS, and /etc/passwd contains root and sysadm accounts for "emergency" access to the system by the administrators when NIS is broken. I haven't seen any environments where organizations try to maintaining *both* centralized and distributed (local store) user credentials. I agree that would be a Bad Idea (tm). _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 06 11:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyVmC-0007qV-EG; Thu, 06 Jul 2006 11:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyVmB-0007qQ-IS for isms@ietf.org; Thu, 06 Jul 2006 11:28:23 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyVmA-0001Cn-9U for isms@ietf.org; Thu, 06 Jul 2006 11:28:23 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc12) with SMTP id <20060706152820m120006bi6e>; Thu, 6 Jul 2006 15:28:21 +0000 From: "David Harrington" To: "'Nelson, David'" , Date: Thu, 6 Jul 2006 11:27:06 -0400 Message-ID: <00d801c6a110$a466ff80$0400a8c0@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: <3CFB564E055A594B82C4FE89D215656021932D@MABOSEVS2.ets.enterasys.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acag8i8KazP7Bi2SRlu8oHRGqBKoCgAEMdLwAAEpgqAAAhNS0A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Isms] Local vs centralized users 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 Note that I changed the subject line, since it is not abuot "access control" terminology. I agree with this comparison, and recommend that the RADIUS draft security considerations make the point that there should be a very limited set of local users for emergency access to supplement the RADIUS approach for emergency plus others. dbh > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Thursday, July 06, 2006 10:28 AM > To: isms@ietf.org > Subject: RE: [Isms] SNMP "access control" terminology > > Uri Blumenthal writes... > > >The motivation for RADIUS is to be able to control from a > centralized > > >system which authenticated user has the right to manage a device. > > > > The danger is - local and central repositories of users diverging. > > How is this different from NIS vs. /etc/passwd? My experience in > enterprise environments is that the "real" users exist in NIS, and > /etc/passwd contains root and sysadm accounts for "emergency" > access to > the system by the administrators when NIS is broken. I > haven't seen any > environments where organizations try to maintaining *both* centralized > and distributed (local store) user credentials. I agree that > would be a > Bad Idea (tm). > > > _______________________________________________ > 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 Jul 06 12:20:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWaZ-0007Tm-Jr; Thu, 06 Jul 2006 12:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWaY-0007Tc-D8 for isms@ietf.org; Thu, 06 Jul 2006 12:20:26 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWaW-00030D-Tq for isms@ietf.org; Thu, 06 Jul 2006 12:20:26 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060706162023m1100i6hr2e>; Thu, 6 Jul 2006 16:20:24 +0000 From: "David Harrington" To: , "'Randy Presuhn'" Subject: RE: [Isms] SNMP "access control" terminology Date: Thu, 6 Jul 2006 12:19:09 -0400 Message-ID: <00e801c6a117$e9b99050$0400a8c0@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: <20060706114849.GB10556@boskop.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acag8ir3I3GmcsIFR/yn2HyEIkZX8wAH+Gjg X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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, I suggest we all step back from this discussion. We obviously have issues with terminology here. The overlap of terminology for the different pieces is causing a lot of confusion. Let's approach this proactively. I recommend that the document be modified to better distinguish the functionality provided by the different pieces and the terminology. In particular, I sugggest that the first three chapters introduce the technologies that will be integrated, and set the terminology that will be used when referring to similar concepts while discussiing specific portions of the integration: 1. Introduction 1.1 An introduction to RADIUS functionality (with no mention of SSH or SNMP) identify the terms that will be used to reference the functionality of RADIUS 1.2 An introduction to SSH functionality (with no mention of RADIUS or SNMP) identify the terms that will be used to reference the functionality of SSH 1.3 An introduction to SNMP transport security (with no mention of SSH, RADIUS, or VACM) identify the terms that will be used to reference the functionality of SNMP transport security 1.4 An introduction to SNMP operations access control identify the terms that will be used to reference the functionality of SNMP operations access control 2. Integration for transport security why integration for transport security is desired 2.1 How SNMP will use SSH to provide transport security (with no mention of RADIUS) to authenticate clients to establish a session-level subsystem for SNMP message security 2.2 How SSH frequently uses RADIUS (with no mention of SNMP) to suthenticate clients to authorize an SSH subsystem 2.3 How SSH can use RADIUS when SSH is providing transport security for SNMP to authenticate clients to authorize an SSH subsystem called "snmp" 3. Integration for SNMP operations access control why integration for SNMP operations access control is desired two main ways to approach getting the information from RADIUS: 3.1 using an ACM subsystem add-on to act as a RADIUS client directly contact the RADIUS server (without using SSHSM) 3.2 using SSH to gather and cache RADIUS attributes 3.2.1 attributes to specify SNMP operations access control parameters 3.2.2 having SSH or SSHSM cache the information 3.2.3 subsequent use of the cached attributes by an ACM subsystem add-on. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Thursday, July 06, 2006 7:49 AM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] SNMP "access control" terminology > > On Mon, Jul 03, 2006 at 03:32:48PM -0700, Randy Presuhn wrote: > > > It's important to remember that in VACM, the only access > control model > > we have, if a user has no entry in the > vacmSecurityToGroupTable [RFC 3415], > > then no operations of any kind are permitted. > > Why should a user who is not authorized to use the system be allowed > to create and keep an open SSH session? And why should such a user be > allowed to send SNMP packets even if they will return just exceptions? > > I consider an SSH connection establishment failure a clearer signal > that someone is not authorized to talk to a system than letting the > establishment of the secure channel succeed and then get just > application layer access exceptions. > > > I haven't been able to think of a reason why one might want to > > create VACM entries for users who have no access rights to a system. > > You might have VACM entries for users which currently do not have > authorization to access the agents but which had authorization in the > past (and which might get it again in the future - e.g. a third party > company helping an organization to manage boxes). But yes, there are > surely different approaches to deal with this today. (Either you > change the security name to group name mapping or you change the USM > password, which means to deny authentication and entrance into the > system - it might be interesting to find out what operators actually > do in such cases - or whether such cases exist at all in reality). > > The motivation for RADIUS is to be able to control from a centralized > system which authenticated user has the right to manage a device. > > Another motivation was to be able to control from a centralized system > which role an authenticated user has once he is allowed to access a > device. > > Both are related in the sense that being able to map an authenticated > user into a "noaccess" role/group may achieve the first requirement > but I think both share the same fundamental problem that we would need > to get information from RADIUS for already authenticated users if we > consider the case where authentication is not done via RADIUS. > > I also believe that the desire to get centralized authorization > information is actually not limited to ISMS but equally applies to > NETCONF and other protocols that are able to authenticate users via > backend systems that do not provide authorization information. > > Since an authorize only solution requires support from RADEXT, I would > prefer to not get ISMS blocked due to this particular feature. Still, > I think we should try to find agreement what authorization means > architecturally in the context of SNMP and TMSM next week. > > /js > > -- > Juergen Schoenwaelder International 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 Thu Jul 06 13:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXUz-0003Jr-Cu; Thu, 06 Jul 2006 13:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXUx-0003Jm-Q0 for isms@ietf.org; Thu, 06 Jul 2006 13:18:43 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXUw-0006CM-C5 for isms@ietf.org; Thu, 06 Jul 2006 13:18:43 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A127955E59; Thu, 6 Jul 2006 19:18:41 +0200 (CEST) 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 25892-08; Thu, 6 Jul 2006 19:18:39 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E531255CCC; Thu, 6 Jul 2006 19:18:38 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 805557825C0; Thu, 6 Jul 2006 19:18:36 +0200 (CEST) Date: Thu, 6 Jul 2006 19:18:36 +0200 From: Juergen Schoenwaelder To: "Blumenthal, Uri" Subject: Re: [Isms] SNMP "access control" terminology Message-ID: <20060706171836.GA11112@boskop.local> Mail-Followup-To: "Blumenthal, Uri" , isms@ietf.org References: <279DDDAFA85EC74C9300A0598E70405641B18F@hdsmsx412.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <279DDDAFA85EC74C9300A0598E70405641B18F@hdsmsx412.amr.corp.intel.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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, Jul 06, 2006 at 09:54:31AM -0400, Blumenthal, Uri wrote: > >Why should a user who is not authorized to use the system be allowed > >to create and keep an open SSH session? And why should such a user be > >allowed to send SNMP packets even if they will return just exceptions? > > Because he is allowed to login as a system user, and you opted for a > common auth strategy? So he's perfectly OK to login via SSH, but not OK > to use SNMP? Sorry, I was not clear. What I wrote "keep an open SSH session" I actually meant "keep an open SSH session to an SNMP subsystem". My thinking is biased by our prototype which uses an SSH library that is integrated into the SNMP agent and thus a connection to managed by this SSH library implicitely is a connection to the SNMP subsystem. > >I consider an SSH connection establishment failure a clearer signal > >that someone is not authorized to talk to a system than letting the > >establishment of the secure channel succeed and then get just > >application layer access exceptions. > > If you aren't allowed SSH - clearly you aren't allowed SSH-based SNMP. > The reverse isn't true. I am not even sure the first is generally true. > >The motivation for RADIUS is to be able to control from a centralized > >system which authenticated user has the right to manage a device. > > The danger is - local and central repositories of users diverging. Exactly. This is why you want to have _all_ accounts controlled by whatever central service you use (except a few emergency accounts). /js -- Juergen Schoenwaelder International 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 Thu Jul 06 13:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXsZ-0005ci-Sg; Thu, 06 Jul 2006 13:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXsY-0005cc-UR for isms@ietf.org; Thu, 06 Jul 2006 13:43:06 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXsX-0007Ug-Ij for isms@ietf.org; Thu, 06 Jul 2006 13:43:06 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 06 Jul 2006 10:43:04 -0700 Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by orsmga001.jf.intel.com with ESMTP; 06 Jul 2006 10:32:53 -0700 X-IronPort-AV: i="4.06,214,1149490800"; d="scan'208"; a="61439522:sNHT2820967478" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:32:07 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:32: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] SNMP "access control" terminology Date: Thu, 6 Jul 2006 13:32:00 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E70405641B355@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] SNMP "access control" terminology thread-index: AcahINQJOWDjHXNAS5a21GHwZ0HsIQAAI3YQ From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 06 Jul 2006 17:32:07.0668 (UTC) FILETIME=[1AC47340:01C6A122] 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 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 >> >Why should a user who is not authorized to use the system be allowed >> >to create and keep an open SSH session? And why should such a user be >> >allowed to send SNMP packets even if they will return just exceptions? >>=20 >> Because he is allowed to login as a system user, and you opted for a >> common auth strategy? So he's perfectly OK to login via SSH, but not OK >> to use SNMP? > >Sorry, I was not clear. What I wrote "keep an open SSH session" I >actually meant "keep an open SSH session to an SNMP subsystem". User may not be allowed to KEEP an open SSH session TO SNMP SUBSYSTEM, but he certainly should (and will) be allowed to pass through SSH authentication and hold that session open until authorization comes up with an answer. And since the authorization in SNMP works on per-object basis (unlike authentication that's on per-packet or per-request, or even per-bunch-of-requests-named-session). So for practical reasons result is the same: user has an open SSH session while authorization process is running. >> If you aren't allowed SSH - clearly you aren't allowed SSH-based SNMP. >> The reverse isn't true. > >I am not even sure the first is generally true. Well, you did want common auth base, didn't you? One implication is that whoever is listed in that common auth database, can get SSH-authenticated and thus open an SSH session. How long that session will stay alive - is a different question that depends on who decides what on the other end of the SSH pipe. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 06 14:13:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYLh-0005vf-Lo; Thu, 06 Jul 2006 14:13:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYLg-0005vW-1X for isms@ietf.org; Thu, 06 Jul 2006 14:13:12 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyYLa-00014b-OY for isms@ietf.org; Thu, 06 Jul 2006 14:13:12 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 14:13:06 -0400 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] SNMP "access control" terminology Date: Thu, 6 Jul 2006 14:13:06 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219331@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] SNMP "access control" terminology Thread-Index: AcahINQJOWDjHXNAS5a21GHwZ0HsIQAAI3YQAAD6JFA= From: "Nelson, David" To: X-OriginalArrivalTime: 06 Jul 2006 18:13:06.0587 (UTC) FILETIME=[D465B6B0:01C6A127] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) 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 Uri Blumenthal writes... > Well, you did want common auth base, didn't you? One implication > is that whoever is listed in that common auth database, can get > SSH-authenticated and thus open an SSH session. How long that=20 > session will stay alive - is a different question that depends=20 > on who decides what on the other end of the SSH pipe. I think this is an accurate description of how SSH works, as deployed. If you can authenticate, you get the "access right" to open an SSH session and attempt to use an application over that session. It is up to the applications to provide further authorization, if required. In this instance, SNMP is the application. I don't think this is how SSH ought to work, when integrated with RADIUS, or any other AAA service. It is not in our charter to specify how SSH integrates with RADIUS, of course, and since we aim to leverage existing deployments, it is somewhat moot anyway. However, I'll indulge in a small digression. I think that the SSH server should take into consideration RADIUS authorization information, when RADIUS is used for SSH authentication. I'll leave out a discussion of any possible SSH use of RADIUS for "Authorize Only" services. In such a scenario, the SSH server should launch the application that is specified by the RADIUS Service-Type attribute. It would not be up to the application to determine the user's authorization. Back to the main point. If it is up to SNMP, as the application, to determine the user's authorization to invoke/use SNMP, how should this occur? I've heard two suggestions: (1) It doesn't matter. With appropriate authorization binding to the VACM, unauthorized users won't be able to complete any operations. Consumption of session resources is at worst a DoS issue. (2) SNMP needs to be able to determine if the authenticated user is an authorized user for SNMP and disconnect the SSH session if the user is not authorized. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 06 14:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYan-0007bX-1F; Thu, 06 Jul 2006 14:28:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYam-0007bI-0m for isms@ietf.org; Thu, 06 Jul 2006 14:28:48 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyYaj-0002J4-N4 for isms@ietf.org; Thu, 06 Jul 2006 14:28:47 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D176C55F35; Thu, 6 Jul 2006 20:28:44 +0200 (CEST) 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 29948-07; Thu, 6 Jul 2006 20:28:42 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 0D93155F0C; Thu, 6 Jul 2006 20:28:40 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 711A1782675; Thu, 6 Jul 2006 20:28:37 +0200 (CEST) Date: Thu, 6 Jul 2006 20:28:37 +0200 From: Juergen Schoenwaelder To: "Blumenthal, Uri" Subject: Re: [Isms] SNMP "access control" terminology Message-ID: <20060706182837.GA11206@boskop.local> Mail-Followup-To: "Blumenthal, Uri" , isms@ietf.org References: <279DDDAFA85EC74C9300A0598E70405641B355@hdsmsx412.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <279DDDAFA85EC74C9300A0598E70405641B355@hdsmsx412.amr.corp.intel.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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, Jul 06, 2006 at 01:32:00PM -0400, Blumenthal, Uri wrote: > > User may not be allowed to KEEP an open SSH session TO SNMP SUBSYSTEM, > but he certainly should (and will) be allowed to pass through SSH > authentication and hold that session open until authorization comes up > with an answer. And since the authorization in SNMP works on per-object > basis (unlike authentication that's on per-packet or per-request, or > even per-bunch-of-requests-named-session). > > So for practical reasons result is the same: user has an open SSH > session while authorization process is running. According to your interpretation of the word authorization. Our dilemma is that we do not have the same interpretation of this term. /js -- Juergen Schoenwaelder International 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 Thu Jul 06 14:41:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYn2-0005w8-EP; Thu, 06 Jul 2006 14:41:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYn1-0005vb-Ff for isms@ietf.org; Thu, 06 Jul 2006 14:41:27 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyYn0-0003Wa-5O for isms@ietf.org; Thu, 06 Jul 2006 14:41:27 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9D28655CFC; Thu, 6 Jul 2006 20:41:25 +0200 (CEST) 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 30754-03; Thu, 6 Jul 2006 20:41:23 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 5C77C55CCC; Thu, 6 Jul 2006 20:41:23 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id BD23F7826A4; Thu, 6 Jul 2006 20:41:20 +0200 (CEST) Date: Thu, 6 Jul 2006 20:41:20 +0200 From: Juergen Schoenwaelder To: "Nelson, David" Subject: Re: [Isms] SNMP "access control" terminology Message-ID: <20060706184120.GB11206@boskop.local> Mail-Followup-To: "Nelson, David" , isms@ietf.org References: <3CFB564E055A594B82C4FE89D2156560219331@MABOSEVS2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219331@MABOSEVS2.ets.enterasys.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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, Jul 06, 2006 at 02:13:06PM -0400, Nelson, David wrote: > Back to the main point. If it is up to SNMP, as the application, to > determine the user's authorization to invoke/use SNMP, how should this > occur? > > I've heard two suggestions: > > (1) It doesn't matter. With appropriate authorization binding to the > VACM, unauthorized users won't be able to complete any operations. > Consumption of session resources is at worst a DoS issue. > > (2) SNMP needs to be able to determine if the authenticated user is an > authorized user for SNMP and disconnect the SSH session if the user is > not authorized. Yes, there are two levels here - authorization to use a service like SNMP in general and authorization to perform a given operation on a given object (object level access control like VACM). And yes, the scope of this question is broader than ISMS since at least NETCONF will have the same issues (with the difference that NETCONF does not have an access control model yet). /js -- Juergen Schoenwaelder International 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 Thu Jul 06 16:11:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaCZ-0002dH-8D; Thu, 06 Jul 2006 16:11:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaCY-0002by-98 for isms@ietf.org; Thu, 06 Jul 2006 16:11:54 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaCW-00079V-Ua for isms@ietf.org; Thu, 06 Jul 2006 16:11:54 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 6E2B711D390; Thu, 6 Jul 2006 13:11:49 -0700 (PDT) From: Wes Hardaker To: "Nelson, David" Subject: Re: [Isms] SNMP "access control" terminology Organization: Sparta References: <3CFB564E055A594B82C4FE89D2156560219331@MABOSEVS2.ets.enterasys.com> <20060706184120.GB11206@boskop.local> Date: Thu, 06 Jul 2006 13:11:49 -0700 In-Reply-To: <20060706184120.GB11206@boskop.local> (Juergen Schoenwaelder's message of "Thu, 6 Jul 2006 20:41:20 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 >>>>> On Thu, 6 Jul 2006 20:41:20 +0200, Juergen Schoenwaelder said: Juergen> Yes, there are two levels here - authorization to use a service like Juergen> SNMP in general and authorization to perform a given operation on a Juergen> given object (object level access control like VACM). Though you may desire to extract one from the other. Specifically, authorization to use the "SNMP service in general" can be derived by seeing if any authorization is allowed to the object model. Whether this is desired on not remains to be seen, but it is adding another configuration variable that isn't necessary (technically) and may lead to configuration errors. What scares me about this conversation is that it sounds like everyone is winding the way to adding another configuration variable. When would you want to allow the SNMP session in general to be used if they couldn't do anything with the service? - Likely never When would you want to allow the SNMP objects to be used but not the SNMP/SSH session? - Likely never, but: - Maybe only allow other security models. - But this is also already possible with VACM and doesn't need separate configuration. - To quick-disable a user and leave the more complex OID include/exclude mappings in place to re-enable it in the future. - But this is also already defined by VACM and doesn't need separate configuration. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 06 16:54:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyas6-0004PP-OI; Thu, 06 Jul 2006 16:54:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyas5-0004PK-EC for isms@ietf.org; Thu, 06 Jul 2006 16:54:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZeM-0000WT-T1 for isms@ietf.org; Thu, 06 Jul 2006 15:36:34 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyZYn-0002ua-Fd for isms@ietf.org; Thu, 06 Jul 2006 15:30:51 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060706193040m1100i6cdae>; Thu, 6 Jul 2006 19:30:45 +0000 From: "David Harrington" To: , "'Nelson, David'" Subject: RE: [Isms] SNMP "access control" terminology Date: Thu, 6 Jul 2006 15:29:26 -0400 Message-ID: <011001c6a132$8169f740$0400a8c0@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: <20060706184120.GB11206@boskop.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcahK8qEstYgaEksQcCUeYKTGMwb9gABRdyg X-Spam-Score: -2.6 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 So can we agree on terminology for two types of authorization? "service authorization" or "session authorization", in which an SSH server is authorized to establish an SSH subsystem of type "snmp" on behalf of an authenticated SSH principal? "operations authorization", in which an SNMP application is authorized to perform specific SNMP operations on specific sets of SNMP data on behalf of an authenticated SNMP principal? dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Thursday, July 06, 2006 2:41 PM > To: Nelson, David > Cc: isms@ietf.org > Subject: Re: [Isms] SNMP "access control" terminology > > On Thu, Jul 06, 2006 at 02:13:06PM -0400, Nelson, David wrote: > > > Back to the main point. If it is up to SNMP, as the application, to > > determine the user's authorization to invoke/use SNMP, how > should this > > occur? > > > > I've heard two suggestions: > > > > (1) It doesn't matter. With appropriate authorization > binding to the > > VACM, unauthorized users won't be able to complete any operations. > > Consumption of session resources is at worst a DoS issue. > > > > (2) SNMP needs to be able to determine if the authenticated > user is an > > authorized user for SNMP and disconnect the SSH session if > the user is > > not authorized. > > Yes, there are two levels here - authorization to use a service like > SNMP in general and authorization to perform a given operation on a > given object (object level access control like VACM). > > And yes, the scope of this question is broader than ISMS since at > least NETCONF will have the same issues (with the difference that > NETCONF does not have an access control model yet). > > /js > > -- > Juergen Schoenwaelder International 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 Thu Jul 06 17:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybLp-0007ZD-1w; Thu, 06 Jul 2006 17:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybLn-0007Z8-QY for isms@ietf.org; Thu, 06 Jul 2006 17:25:31 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FybLm-0004RI-IN for isms@ietf.org; Thu, 06 Jul 2006 17:25:31 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k66LPRol012547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 17:25:28 -0400 (EDT) Date: Thu, 06 Jul 2006 17:25:27 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] SNMP "access control" terminology Message-ID: In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219331@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D2156560219331@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01v7M00CkbqUQL/qxR8jFkP1Yla/tG560sKGI19TM=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Jeffrey Hutzelman 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 On Thursday, July 06, 2006 02:13:06 PM -0400 "Nelson, David" wrote: > I think this is an accurate description of how SSH works, as deployed. > If you can authenticate, you get the "access right" to open an SSH > session and attempt to use an application over that session. It is up > to the applications to provide further authorization, if required. In > this instance, SNMP is the application. This is an oversimplification. If the step that SSH calls "user authentication" succeeds, then you get to open a session. That step is understood to include both authentication of the client and authorization of the client to start an ssh session with a particular identity (an ssh username). The former is performed using a protocol specified by the particular userauth method in use; the latter is largely implementation-dependent. An SSH server which uses RADIUS to back userauth can indeed take RADIUS attributes into account when making its authorization decision. It can even use that information to decide what programs or subsystems the client is allowed to launch(*). OpenSSH makes this sort of decision today based on authorization data included in authorized_keys files; an implementation could easily do the same thing with RADIUS. > Back to the main point. If it is up to SNMP, as the application, to > determine the user's authorization to invoke/use SNMP, how should this > occur? I think it's up to SNMP, and particularly the access control model, to decide what users are allowed to perform what operations. Whether a user is allowed to access SNMP at all is effectively up to the security model. In the case of a TMSM, we can and IMHO should push that functionality all the way down to the underlying transport, which in this case is SSH. Now, we can argue all you want about whether it's necessary for SSH or any part of SNMP to provide any sort of coarse-grained "can this user use SNMP" authorization, but ultimately, I think that's an implementation and deployment decision. Given the existence of the SNMP access control model, there is no security reason why we need to require such functionality. There's also no reason to prohibit it, and if we did, we'd be ignored, since nearly all SSH implementations at least provide "is this user allowed to access the system at all"-level authorization. So, can we stop arguing about whether coarse- or fine-grained access controls are a good idea or not, accept that people will want and deploy both, and move on to some actual protocol design? -- Jeff (*) There seems to be some confusion about what "authentication" and "authorization" mean. These terms have well-established meaning in the security community; the first means proving the identity of some entity; the second, deciding what that entity is or is not allowed to do. Deciding whether a client can perform operations like "start an SNMP session" and "update MIB object foo" are both authorization decisions; they differ only in scope, not kind. I think it would be best if we used the unqualified terms "authentication" and "authorization" only in this general sense, and always used qualifiers when a narrower meaning is intended. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 06 20:20:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fye5H-0004Wn-6J; Thu, 06 Jul 2006 20:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fye5G-0004Wi-QR for isms@ietf.org; Thu, 06 Jul 2006 20:20:38 -0400 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fye5F-00089s-Jf for isms@ietf.org; Thu, 06 Jul 2006 20:20:38 -0400 Received: from h-68-165-4-139.snvacaid.dynamic.covad.net ([68.165.4.139] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Fye5F-00021F-00 for isms@ietf.org; Thu, 06 Jul 2006 20:20:37 -0400 Message-ID: <005301c6a15b$49ce71c0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <3CFB564E055A594B82C4FE89D2156560219331@MABOSEVS2.ets.enterasys.com><20060706184120.GB11206@boskop.local> Subject: Re: [Isms] SNMP "access control" terminology Date: Thu, 6 Jul 2006 17:21:27 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 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 Hi - > From: "Wes Hardaker" > To: "Nelson, David" > Cc: > Sent: Thursday, July 06, 2006 1:11 PM > Subject: Re: [Isms] SNMP "access control" terminology ... > Though you may desire to extract one from the other. Specifically, > authorization to use the "SNMP service in general" can be derived by > seeing if any authorization is allowed to the object model. Whether > this is desired on not remains to be seen, but it is adding another > configuration variable that isn't necessary (technically) and may lead > to configuration errors. > > What scares me about this conversation is that it sounds like everyone > is winding the way to adding another configuration variable. ... A simple hack to avoid adding another configuration variable would be to just check the vacmSecurityToGroupTable to see whether there is an entry for the user. If there is none, then the session could be terminated. Of course, this violates modularity, bypasses existing ASIs, and would only work with VACM. But it *would* be simple, do the right thing, and not require additional configuration. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 07 10:29:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrKO-0007e6-Tt; Fri, 07 Jul 2006 10:29:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrKO-0007e1-Ir for isms@ietf.org; Fri, 07 Jul 2006 10:29:08 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrKJ-0007Kf-9z for isms@ietf.org; Fri, 07 Jul 2006 10:29:08 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 10:28:46 -0400 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: Suggestions for the RADIUS integration draft (was RE: [Isms] SNMP "access control" terminology) Date: Fri, 7 Jul 2006 10:28:46 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219339@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Suggestions for the RADIUS integration draft (was RE: [Isms] SNMP "access control" terminology) Thread-Index: Acag8ir3I3GmcsIFR/yn2HyEIkZX8wAH+GjgAC/HYaA= From: "Nelson, David" To: X-OriginalArrivalTime: 07 Jul 2006 14:28:46.0421 (UTC) FILETIME=[A7ED2050:01C6A1D1] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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... > In particular, I sugggest that the first three chapters introduce the > technologies that will be integrated, and set the terminology that > will be used when referring to similar concepts while discussiing > specific portions of the integration: >=20 > 1. Introduction > 1.1 An introduction to RADIUS functionality (with no mention of SSH or > SNMP) > identify the terms that will be used to reference the > functionality of RADIUS > 1.2 An introduction to SSH functionality (with no mention of RADIUS or > SNMP) > identify the terms that will be used to reference the > functionality of SSH > 1.3 An introduction to SNMP transport security (with no mention of > SSH, RADIUS, or VACM) > identify the terms that will be used to reference the > functionality of SNMP transport security > 1.4 An introduction to SNMP operations access control > identify the terms that will be used to reference the > functionality of SNMP operations access control >=20 > 2. Integration for transport security > why integration for transport security is desired > 2.1 How SNMP will use SSH to provide transport security (with no > mention of RADIUS) > to authenticate clients > to establish a session-level subsystem for SNMP message > security > 2.2 How SSH frequently uses RADIUS (with no mention of SNMP) > to suthenticate clients > to authorize an SSH subsystem > 2.3 How SSH can use RADIUS when SSH is providing transport security > for SNMP > to authenticate clients > to authorize an SSH subsystem called "snmp" >=20 > 3. Integration for SNMP operations access control > why integration for SNMP operations access control is desired > two main ways to approach getting the information from RADIUS: > 3.1 using an ACM subsystem add-on to act as a RADIUS client > directly contact the RADIUS server (without using SSHSM) > 3.2 using SSH to gather and cache RADIUS attributes > 3.2.1 attributes to specify SNMP operations access control > parameters > 3.2.2 having SSH or SSHSM cache the information > 3.2.3 subsequent use of the cached attributes by an ACM > subsystem add-on. This seems like a reasonable outline for incorporation of the -01 revision of the RADIUS integration draft. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 12 13:33:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iaN-0008IX-H8; Wed, 12 Jul 2006 13:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iaM-0008I1-98 for isms@ietf.org; Wed, 12 Jul 2006 13:33:18 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iaH-0000JI-0f for isms@ietf.org; Wed, 12 Jul 2006 13:33:18 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 13:33:12 -0400 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] FW: RADIUS integration Date: Wed, 12 Jul 2006 13:33:11 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021935A@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration Thread-Index: AcaZZJwFjgEEr3gdSFO3VxC0wad7GQMc7I0g From: "Nelson, David" To: "Jeffrey Hutzelman" , X-OriginalArrivalTime: 12 Jul 2006 17:33:12.0533 (UTC) FILETIME=[3FE89050:01C6A5D9] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > Authentication and authorization > _are_ separate concepts, and people are beginning to recognize that and > treat them separately. Authentication is no longer always about usernames > and passwords, and some authentication methods do not lend themselves to > authenticating to some entity other than the one you want to talk to. > Whether it's SSHSM, an SSH login session, 802.1x, or PPP dialup, > authentication may take place via a mechanism that is outside the RADIUS > server's control. Once that happens, the application needs to make a > decision as to whether to provide access and at what level, and RADIUS is > an appropriate tool for that, even though it did not handle > authentication. > But it can only be used that way if a RADIUS client can say "this is the > user's identity; tell me what I need to know to make an access decision". This concept was presented this past Monday in the RADEXT WG meeting at IETF-66, in the context of the concrete example of using Kerberos authentication with RADIUS authorization. Perhaps using the example of Kerberos was inadvisable. In any event, a few of those present asserted that this work should probably not go forward in RADEXT or ISMS because it would be a major architectural change to Kerberos. Since Kerberos already contains authorization elements, that are cryptographically bound to the authentication (ticket) it was argued that allowing a mechanism by which RADIUS authorization, lacking s similar cryptographic binding, to over-ride or modify any Kerberos provided authorization opened up security concerns, and architectural concerns. We will discuss this late today in the ISMS WG meeting. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 12 14:34:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jXk-0007cT-6n; Wed, 12 Jul 2006 14:34:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jWw-00072d-Ho for isms@ietf.org; Wed, 12 Jul 2006 14:33:50 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jPL-00017n-12 for isms@ietf.org; Wed, 12 Jul 2006 14:26:00 -0400 Received: from h1ac6-net84db.lab.risq.net (h1ac6-net84db.lab.risq.net [132.219.26.198] (may be forged)) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6CIPqvJ014935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jul 2006 14:25:56 -0400 (EDT) Date: Wed, 12 Jul 2006 14:25:52 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] FW: RADIUS integration Message-ID: In-Reply-To: <3CFB564E055A594B82C4FE89D215656021935A@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D215656021935A@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01Nm4PR6DWhLuCuYfIaew/ts3gRnK9ooij4z2sbO4=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Jeffrey Hutzelman 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 On Wednesday, July 12, 2006 01:33:11 PM -0400 "Nelson, David" wrote: > In any event, a few of those present asserted > that this work should probably not go forward in RADEXT or ISMS because > it would be a major architectural change to Kerberos. Yeah; I heard about that, but that's not really a very good argument. Kerberos provides a means to _carry_ data related to authorization, for cases where that is useful, but it does not itself define any authorization mechanism. The philosophy of Kerberos is that authentication and authorization are separate concepts, and Kerberos provides only the former. > Since Kerberos > already contains authorization elements, that are cryptographically > bound to the authentication (ticket) it was argued that allowing a > mechanism by which RADIUS authorization, lacking s similar cryptographic > binding, to over-ride or modify any Kerberos provided authorization > opened up security concerns, and architectural concerns. This is not an issue; Kerberos is intended to allow applications to identify clients by name, and make authorization decisions on that basis. There is nothing in the Kerberos architecture which precludes applications using any means at their disposal to make authorization decisions one authentication is complete. If anyone is confused or concerned about this issue, I'd be happy to discuss it further in person. -- Jeffrey T. Hutzelman (N3NHS) Chair, IETF Kerberos Working Group Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 12 16:01:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kto-0006UC-Go; Wed, 12 Jul 2006 16:01:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ktn-0006U5-Cq for isms@ietf.org; Wed, 12 Jul 2006 16:01:31 -0400 Received: from [132.219.8.150] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ktk-0001us-5b for isms@ietf.org; Wed, 12 Jul 2006 16:01:31 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E7499E0079; Wed, 12 Jul 2006 16:01:57 -0400 (EDT) From: Sam Hartman To: isms@ietf.org Date: Wed, 12 Jul 2006 16:01:57 -0400 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Isms] snmpwalk, snmpget and notifications 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 I want to try and explain the comment I made at the microphone today regarding Juergen's presentation on notifications. The assumption is that you can use an existing session from a command generator to a command responder for the entity previously acting as a command responder to send a notification back to the command generator. That means that if I use a command like snmpget to open up an ssh session to send a command then I need to be prepared to receive and deal with a notification on that session. I think that's a change from how SNMP works today. That is an acceptable change if the WG decides it is acceptable and properly documents it. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 13 10:02:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11lp-0005qk-6q; Thu, 13 Jul 2006 10:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11ln-0005qZ-T8 for isms@ietf.org; Thu, 13 Jul 2006 10:02:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11ln-0005LK-R0 for isms@ietf.org; Thu, 13 Jul 2006 10:02:23 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G11lj-00085V-Ha for isms@ietf.org; Thu, 13 Jul 2006 10:02:23 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id DE9CE55E5B for ; Thu, 13 Jul 2006 16:02:11 +0200 (CEST) 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 22630-05; Thu, 13 Jul 2006 16:02:09 +0200 (CEST) Received: from h0db4-net84db.lab.risq.net (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 326C14D291; Thu, 13 Jul 2006 16:02:06 +0200 (CEST) Received: by h0db4-net84db.lab.risq.net (Postfix, from userid 501) id 44AB3789F3F; Thu, 13 Jul 2006 16:02:02 +0200 (CEST) Date: Thu, 13 Jul 2006 16:02:02 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060713140202.GA365@h0db4-net84db.lab.risq.net> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: -2.2 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Isms] looking for volunteers for the applicability document 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 Hi, as our main work items are getting closer to completion, we need to start work on the applicability document. RFC 2026 section 3.2 defines the nature of an applicability statement for a technical specification (TS): : 3.2 Applicability Statement (AS) : : An Applicability Statement specifies how, and under what : circumstances, one or more TSs may be applied to support a particular : Internet capability. An AS may specify uses for TSs that are not : Internet Standards, as discussed in Section 7. : : An AS identifies the relevant TSs and the specific way in which they : are to be combined, and may also specify particular values or ranges : of TS parameters or subfunctions of a TS protocol that must be : implemented. An AS also specifies the circumstances in which the use : of a particular TS is required, recommended, or elective (see section : 3.3). : : An AS may describe particular methods of using a TS in a restricted : "domain of applicability", such as Internet routers, terminal : servers, Internet systems that interface to Ethernets, or datagram- : based database servers. : : The broadest type of AS is a comprehensive conformance specification, : commonly called a "requirements document", for a particular class of : Internet systems, such as Internet routers or Internet hosts. : : An AS may not have a higher maturity level in the standards track : than any standards-track TS on which the AS relies (see section 4.1). : For example, a TS at Draft Standard level may be referenced by an AS : at the Proposed Standard or Draft Standard level, but not by an AS at : the Standard level. Please send suggestions and/or your offer to help to the chairs. /js -- Juergen Schoenwaelder International 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 Thu Jul 13 13:21:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14sK-0007MA-GY; Thu, 13 Jul 2006 13:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14sJ-0007M0-Ep for isms@ietf.org; Thu, 13 Jul 2006 13:21:19 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14sI-0008Hc-4m for isms@ietf.org; Thu, 13 Jul 2006 13:21:19 -0400 Received: from h0ad6-net84db.lab.risq.net (unknown [132.219.10.214]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 13D671BAC9E; Thu, 13 Jul 2006 19:06:47 +0200 (CEST) Date: Thu, 13 Jul 2006 19:21:10 +0200 From: Juergen Quittek To: saag@mit.edu, isms@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (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: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Isms] IPFIX session summary 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 ISMS Session Summary Wednesday, July 12, 2006, 1510-1610 The two existing WG I-Ds on a transport mapping model and on an SSH security model for SNMP still have few remaining decisions to be made. There was consensus on clearly separating user authentication for establishing a transport session from authorization required for access control to MIB elements. The discussion on how to create sessions for notifications from a managed mode to a management system could still not get solved. From the management system point of view, there is a clear preference for initiating TLS sessions in 'reverse' direction. However, the security problems implied by this approach might be too severe to use it. Finally, the WG discussed RADIUS integration of the SSH security model. There seems to be different positions in the security community about whether or not 'authorization only' requests harmonize or dis-harmonize with the Kerberos architecture. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 13 13:28:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14zc-0001fb-8s; Thu, 13 Jul 2006 13:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14za-0001fW-Lk for isms@ietf.org; Thu, 13 Jul 2006 13:28:50 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14zZ-0000EH-85 for isms@ietf.org; Thu, 13 Jul 2006 13:28:50 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8616A55CE0; Thu, 13 Jul 2006 19:28:48 +0200 (CEST) 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 06050-04; Thu, 13 Jul 2006 19:28:45 +0200 (CEST) Received: from h1fcf-net84db.lab.risq.net (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 43E2B129C7; Thu, 13 Jul 2006 19:28:45 +0200 (CEST) Received: by h1fcf-net84db.lab.risq.net (Postfix, from userid 501) id 1F8BB78A2DC; Thu, 13 Jul 2006 19:28:40 +0200 (CEST) Date: Thu, 13 Jul 2006 19:28:40 +0200 From: Juergen Schoenwaelder To: Juergen Quittek Subject: Re: [Isms] ISMS session summary Message-ID: <20060713172840.GB624@h1fcf-net84db.lab.risq.net> Mail-Followup-To: Juergen Quittek , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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, Jul 13, 2006 at 07:21:10PM +0200, Juergen Quittek wrote: > ISMS Session Summary > Wednesday, July 12, 2006, 1510-1610 > > The two existing WG I-Ds on a transport mapping model and on an SSH > security model for SNMP still have few remaining decisions to be made. > There was consensus on clearly separating user authentication for > establishing a transport session from authorization required for > access control to MIB elements. > The discussion on how to create sessions for notifications from a > managed mode to a management system could still not get solved. From > the management system point of view, there is a clear preference for > initiating TLS sessions in 'reverse' direction. However, the security > problems implied by this approach might be too severe to use it. > Finally, the WG discussed RADIUS integration of the SSH security model. > There seems to be different positions in the security community about > whether or not 'authorization only' requests harmonize or dis-harmonize > with the Kerberos architecture. I like to add that the room had concensus to introduce a transport sub-system into the TMSM document which has the nice side effect of simplifying the terminology significantly. In particular, the TMSP becomes a transport model and the SMSP becomes a more generic session-based security model (which might map to multiple different session-based secure transports). See Dave Harrington slides for the details. /js -- Juergen Schoenwaelder International 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 Thu Jul 13 14:39:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G165v-0005Kx-H3; Thu, 13 Jul 2006 14:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G165u-0005Ks-9t for isms@ietf.org; Thu, 13 Jul 2006 14:39:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G165s-0006Vm-0r for isms@ietf.org; Thu, 13 Jul 2006 14:39:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 13 Jul 2006 11:39:23 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="305585302:sNHT23913432" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DIdNi3002564; Thu, 13 Jul 2006 11:39:23 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6DIdMHS028842; Thu, 13 Jul 2006 11:39:22 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4642.cisco.com [10.61.82.33]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6DIXKNf013075; Thu, 13 Jul 2006 11:33:21 -0700 Message-ID: <44B69357.6050507@cisco.com> Date: Thu, 13 Jul 2006 20:39:19 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [Isms] ISMS session summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-5.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1301; t=1152815963; x=1153679963; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Isms]=20ISMS=20session=20summary; X=v=3Dcisco.com=3B=20h=3DaltBINBw6kSzwe40Zm4S1Rxpfvw=3D; b=D1hkgRCSkou+LcQYjC1hcAHva293kfTJEjG1FIrIytZCLjxw8CAADC9D31QZCqj1T/feJ4oY DjqGhpUOrq8LgjM7SKhNeEIoMXAvDVpyuap9yEjjZxUEIrGxMzJjoNmi; X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: saag@mit.edu, 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 Juergen, > ISMS Session Summary > Wednesday, July 12, 2006, 1510-1610 > > The two existing WG I-Ds on a transport mapping model and on an SSH > security model for SNMP still have few remaining decisions to be made. > There was consensus on clearly separating user authentication for > establishing a transport session from authorization required for > access control to MIB elements. > The discussion on how to create sessions for notifications from a > managed mode to a management system could still not get solved. From > the management system point of view, there is a clear preference for > initiating TLS sessions in 'reverse' direction. However, the security > problems implied by this approach might be too severe to use it. Could someone elaborate on what they think those implications are? > Finally, the WG discussed RADIUS integration of the SSH security model. > There seems to be different positions in the security community about > whether or not 'authorization only' requests harmonize or dis-harmonize > with the Kerberos architecture. A simple approach to take here would be to say that if you're using Kerberos to authenticate you must fill in appropriate VACM tables OOB. This would, therefore, involve a bunch of null functions for Kerberos. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 13 15:16:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16fQ-0001Dc-Pe; Thu, 13 Jul 2006 15:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16fP-0001DW-Qe for isms@ietf.org; Thu, 13 Jul 2006 15:16:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16fO-00015W-GE for isms@ietf.org; Thu, 13 Jul 2006 15:16:07 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2006 12:16:06 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DJG6xp024565; Thu, 13 Jul 2006 12:16:06 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DJG5Ji026472; Thu, 13 Jul 2006 12:16:05 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4642.cisco.com [10.61.82.33]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6DJA2te013905; Thu, 13 Jul 2006 12:10:04 -0700 Message-ID: <44B69BF1.5070307@cisco.com> Date: Thu, 13 Jul 2006 21:16:01 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Eliot Lear , Juergen Quittek , isms@ietf.org Subject: Re: [Isms] ISMS session summary References: <44B69357.6050507@cisco.com> <20060713190040.GA1120@h1fcf-net84db.lab.risq.net> In-Reply-To: <20060713190040.GA1120@h1fcf-net84db.lab.risq.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1296; t=1152818166; x=1153682166; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Isms]=20ISMS=20session=20summary; X=v=3Dcisco.com=3B=20h=3DaltBINBw6kSzwe40Zm4S1Rxpfvw=3D; b=ekEJLYmrUBVquCAP/5oJ9DbkGHmFCos903gufQhAXjScNqu9+6LP4HEnb87b0vG3BTQgye41 4PittHj5THG+JqRNOvd25suonMqv8c8xDqpB/XDvfusm7aj4Krx6Dj5C; X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: > On Thu, Jul 13, 2006 at 08:39:19PM +0200, Eliot Lear wrote: > > >> A simple approach to take here would be to say that if you're using >> Kerberos to authenticate you must fill in appropriate VACM tables OOB. >> This would, therefore, involve a bunch of null functions for Kerberos. >> > > Two observations: > > (a) The security name to group name mapping is a VACM feature and once > you are in VACM in our architecture, you surely do not know > anymore what was actually used down there in the SSH layer to > actually perform the authentication. We do have a layered > architecture and we should not break up those layers. > Right. Nothing I proposed would do that. I'm saying that for Kerberos and others, for instance, you use the existing VACM rules with the Kerberos principal name. That's all. > (b) Our charter currently says: > > Work on new access control models or centralized administration of > View-based Access Control Model (VACM) rules and mappings is outside > the scope of the working group. > I don't understand what would need to change re the above, so I'm not sure how we get to (b), which I believe to be a general SNMP shortcoming not limited to ISMS. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 13 15:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17Cx-0005jm-82; Thu, 13 Jul 2006 15:50:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16f3-00010E-RA for isms@ietf.org; Thu, 13 Jul 2006 15:15:45 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16Qb-0008Dk-OC for isms@ietf.org; Thu, 13 Jul 2006 15:00:52 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 016A155CFD; Thu, 13 Jul 2006 21:00:49 +0200 (CEST) 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 11351-06; Thu, 13 Jul 2006 21:00:46 +0200 (CEST) Received: from h1fcf-net84db.lab.risq.net (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id ED488395A8; Thu, 13 Jul 2006 21:00:45 +0200 (CEST) Received: by h1fcf-net84db.lab.risq.net (Postfix, from userid 501) id 8986578A680; Thu, 13 Jul 2006 21:00:40 +0200 (CEST) Date: Thu, 13 Jul 2006 21:00:40 +0200 From: Juergen Schoenwaelder To: Eliot Lear Subject: Re: [Isms] ISMS session summary Message-ID: <20060713190040.GA1120@h1fcf-net84db.lab.risq.net> Mail-Followup-To: Eliot Lear , Juergen Quittek , isms@ietf.org References: <44B69357.6050507@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B69357.6050507@cisco.com> User-Agent: Mutt/1.5.10i 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 Thu, Jul 13, 2006 at 08:39:19PM +0200, Eliot Lear wrote: > A simple approach to take here would be to say that if you're using > Kerberos to authenticate you must fill in appropriate VACM tables OOB. > This would, therefore, involve a bunch of null functions for Kerberos. Two observations: (a) The security name to group name mapping is a VACM feature and once you are in VACM in our architecture, you surely do not know anymore what was actually used down there in the SSH layer to actually perform the authentication. We do have a layered architecture and we should not break up those layers. (b) Our charter currently says: Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. As much as I understand the desire to have a security name to group name mapping coming from AAA, it seems that we are currently not chartered to provide it. Note that relevant RADIUS attributes have been proposed to the radext WG and people really interested to have support should read draft-nelson-radius-management-authorization-03.txt and help David Nelson to move this document along in RADEXT. /js -- Juergen Schoenwaelder International 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 Thu Jul 13 16:59:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18HN-0000mf-Vt; Thu, 13 Jul 2006 16:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18HM-0000ma-RT for isms@ietf.org; Thu, 13 Jul 2006 16:59:24 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18HH-0008C4-IO for isms@ietf.org; Thu, 13 Jul 2006 16:59:24 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 16:59:18 -0400 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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Thu, 13 Jul 2006 16:59:18 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219368@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcamoMmNnAEnI466RJyA/LWJ66zJ9QAG1Jsg From: "Nelson, David" To: X-OriginalArrivalTime: 13 Jul 2006 20:59:18.0736 (UTC) FILETIME=[35272500:01C6A6BF] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: radiusext@ops.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 Juergen Quittek writes... > Finally, the WG discussed RADIUS integration of the SSH security model. > There seems to be different positions in the security community about > whether or not 'authorization only' requests harmonize or dis-harmonize > with the Kerberos architecture. We had a lunchtime meeting today to discuss this issue, with Jeff Hutzelman, Bernard Aboba, Russ Housley and myself. The problem turns out to be more with the RADIUS architecture and the trust models than an issue with the Kerberos architecture. This issue was not brought up in RADEXT on Monday, and the issues that were brought up in RADEXT on this point seem to have been addressed. The remaining issue, in a nutshell, with the desired Authorize Only usage is as follows. In RADIUS, Access-Request messages can be authenticated by two means, the user credentials, e.g. User-Password or CHAP-Password, or Message-Authenticator. All of these are based on the RADIUS client and server sharing a secret. One major difference between the user credentials and the Message-Authenticator is that that former provide proof to the RADIUS server that the given user is "present" at the NAS. The latter only provides proof to the RADIUS server that the NAS is trusted. =20 In an Access-Accept message, the NAS is trusted to have authorization information for the user because (a) the NAS is trusted and (b) the user is present at the NAS, so the NAS has a "need to know". The concerns with Authorize Only operations, that do not have a previous successful RADIUS authentication as a prerequisite, is that when the user is not present at the NAS, the NAS does not have a "need to know" the user's authorization status. Information might be leaked to a NAS about users, that the NAS would not otherwise be entitled to have. IN RFC 3576, the requirement for a previous RADIUS authentication is met by requiring a server State attribute t be in the Access-Request message, which provides that binding for Authorize Only operation. The only form of RADIUS operation that currently provides authorization information on a "user" without user credentials is the call check operation. In these cases the actual user is not identified, but rather the user's phone number (or similar network address information). For the SSHSM usage case, the question is whether it is an unacceptable security risk for a trusted NAS to be able to obtain authorization information about a user that is not actually "present" at the NAS? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 15 05:37:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1gaP-0004C9-1C; Sat, 15 Jul 2006 05:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1gaN-0004C3-Bk for isms@ietf.org; Sat, 15 Jul 2006 05:37:19 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1gaM-0000Th-57 for isms@ietf.org; Sat, 15 Jul 2006 05:37:19 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6F9Vmtq010896 for ; Sat, 15 Jul 2006 05:31:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 15 Jul 2006 12:37:16 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Virus warning!]delivery failed Thread-Index: Acan8kIygq1ZFAk0S8egpYhOwrc1jwAAAAl0 From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Isms] Out of Office AutoReply: [Virus warning!]delivery failed 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="===============0189046669==" Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0189046669== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A7F2.425AC162" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A7F2.425AC162 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am out-of-office traveling at the IETF and IEEE meetings and will be = back on July 23, 2006. I may not read and respond all e-mails during = this period. If you need to contact me urgently, please leave a voice = mail message at my office number. Regards, Dan ------_=_NextPart_001_01C6A7F2.425AC162 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: [Virus warning!]delivery failed

I am out-of-office traveling at the IETF and IEEE = meetings and will be back on July 23, 2006.  I may not read and = respond all e-mails during this period.  If you need to contact me = urgently, please leave a voice mail message at my office number.

Regards,

Dan

------_=_NextPart_001_01C6A7F2.425AC162-- --===============0189046669== 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 --===============0189046669==-- From isms-bounces@lists.ietf.org Sat Jul 15 15:29:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ppW-0004FA-3Y; Sat, 15 Jul 2006 15:29:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ppV-0004F5-LX for isms@ietf.org; Sat, 15 Jul 2006 15:29:33 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1ppT-0005EO-7a for isms@ietf.org; Sat, 15 Jul 2006 15:29:33 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 048684D3AB; Sat, 15 Jul 2006 21:29:30 +0200 (CEST) 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 24035-03; Sat, 15 Jul 2006 21:29:27 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 54D784D36A; Sat, 15 Jul 2006 21:29:25 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 8F9F6791350; Sat, 15 Jul 2006 21:29:21 +0200 (CEST) Date: Sat, 15 Jul 2006 21:29:20 +0200 From: Juergen Schoenwaelder To: "Nelson, David" Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Message-ID: <20060715192920.GA6906@boskop.local> Mail-Followup-To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org References: <3CFB564E055A594B82C4FE89D2156560219368@MABOSEVS2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219368@MABOSEVS2.ets.enterasys.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: isms@ietf.org, radiusext@ops.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, Jul 13, 2006 at 04:59:18PM -0400, Nelson, David wrote: > > In an Access-Accept message, the NAS is trusted to have authorization > information for the user because (a) the NAS is trusted and (b) the user > is present at the NAS, so the NAS has a "need to know". The concerns > with Authorize Only operations, that do not have a previous successful > RADIUS authentication as a prerequisite, is that when the user is not > present at the NAS, the NAS does not have a "need to know" the user's > authorization status. Information might be leaked to a NAS about users, > that the NAS would not otherwise be entitled to have. Thanks, I think I understand this. Now I wonder how other AAA systems which I have been told to support authorize only deal with this issue. Can someone please explain? > IN RFC 3576, the requirement for a previous RADIUS authentication is met > by requiring a server State attribute t be in the Access-Request > message, which provides that binding for Authorize Only operation. If I understand this correctly, then you have (a) the NAS is trusted and (b) the user was previously present at the NAS here. Correct? > The only form of RADIUS operation that currently provides authorization > information on a "user" without user credentials is the call check > operation. In these cases the actual user is not identified, but rather > the user's phone number (or similar network address information). > > For the SSHSM usage case, the question is whether it is an unacceptable > security risk for a trusted NAS to be able to obtain authorization > information about a user that is not actually "present" at the NAS? This probably needs more thought and discussion. Thanks for discussing this issue and writing things up in a way that I seem to understand. /js -- Juergen Schoenwaelder International 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 Mon Jul 17 22:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2eyU-0008Ew-Ne; Mon, 17 Jul 2006 22:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SRd-0001FY-2V for isms@ietf.org; Fri, 14 Jul 2006 14:31:21 -0400 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1SRb-0003Kl-Hw for isms@ietf.org; Fri, 14 Jul 2006 14:31:21 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3735F16CBC; Fri, 14 Jul 2006 14:22:10 -0400 (EDT) From: "Alan DeKok" To: "Nelson, David" Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) In-Reply-To: Your message of "Thu, 13 Jul 2006 16:59:18 EDT." <3CFB564E055A594B82C4FE89D2156560219368@MABOSEVS2.ets.enterasys.com> Date: Fri, 14 Jul 2006 14:22:10 -0400 Message-Id: <20060714182210.3735F16CBC@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 17 Jul 2006 22:06:13 -0400 Cc: isms@ietf.org, radiusext@ops.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 "Nelson, David" wrote: > For the SSHSM usage case, the question is whether it is an unacceptable > security risk for a trusted NAS to be able to obtain authorization > information about a user that is not actually "present" at the NAS? i.e. "present" as in "the RADIUS server performed the authentication, and verified that the user is present". Is there any *other* authentication credentials that can be sent to the RADIUS server, to mitigate the issue? e.g. A kerberos ticket? The RADIUS server could either validate the kerberos ticket itself, or log the ticket for later auditing. If it's too hard to send the ticket, maybe a hash of the ticket, or ticket ID (I'm not sure if this is available or useful in Kerberos..) If the server had some auditing capability for Authorize-Only requests, an admin could correlate that information with authentication performed by non-RADIUS servers. That would mitigate the concerns over the RADIUS server not performing the authorization. Alan DeKok. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 17 22:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2eyU-0008F2-Rd; Mon, 17 Jul 2006 22:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SY0-00013n-24 for isms@ietf.org; Fri, 14 Jul 2006 14:37:56 -0400 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1SXy-0004ln-S8 for isms@ietf.org; Fri, 14 Jul 2006 14:37:56 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 285A716CBC; Fri, 14 Jul 2006 14:28:46 -0400 (EDT) From: "Alan DeKok" To: isms@ietf.org, radiusext@ops.ietf.org Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) In-Reply-To: Your message of "Fri, 14 Jul 2006 14:22:10 EDT." <20060714182210.3735F16CBC@mail.nitros9.org> Date:From isms-bounces@lists.ietf.org Mon Jul 17 22:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2eyU-0008Ew-Ne; Mon, 17 Jul 2006 22:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SRd-0001FY-2V for isms@ietf.org; Fri, 14 Jul 2006 14:31:21 -0400 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1SRb-0003Kl-Hw for isms@ietf.org; Fri, 14 Jul 2006 14:31:21 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3735F16CBC; Fri, 14 Jul 2006 14:22:10 -0400 (EDT) From: "Alan DeKok" To: "Nelson, David" Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) In-Reply-To: Your message of "Thu, 13 Jul 2006 16:59:18 EDT." <3CFB564E055A594B82C4FE89D2156560219368@MABOSEVS2.ets.enterasys.com> Date: Fri, 14 Jul 2006 14:22:10 -0400 Message-Id: <20060714182210.3735F16CBC@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 17 Jul 2006 22:06:13 -0400 Cc: isms@ietf.org, radiusext@ops.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 "Nelson, David" wrote: > For the SSHSM usage case, the question is whether it is an unacceptable > security risk for a trusted NAS to be able to obtain authorization > information about a user that is not actually "present" at the NAS? i.e. "present" as in "the RADIUS server performed the authentication, and verified that the user is present". Is there any *other* authentication credentials that can be sent to the RADIUS server, to mitigate the issue? e.g. A kerberos ticket? The RADIUS server could either validate the kerberos ticket itself, or log the ticket for later auditing. If it's too hard to send the ticket, maybe a hash of the ticket, or ticket ID (I'm not sure if this is available or useful in Kerberos..) If the server had some auditing capability for Authorize-Only requests, an admin could correlate that information with authentication performed by non-RADIUS servers. That would mitigate the concerns over the RADIUS server not performing the authorization. Alan DeKok. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 17 22:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2eyU-0008F2-Rd; Mon, 17 Jul 2006 22:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SY0-00013n-24 for isms@ietf.org; Fri, 14 Jul 2006 14:37:56 -0400 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1SXy-0004ln-S8 for isms@ietf.org; Fri, 14 Jul 2006 14:37:56 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 285A716CBC; Fri, 14 Jul 2006 14:28:46 -0400 (EDT) From: "Alan DeKok" To: isms@ietf.org, radiusext@ops.ietf.org Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) In-Reply-To: Your message of "Fri, 14 Jul 2006 14:22:10 EDT." <20060714182210.3735F16CBC@mail.nitros9.org> Date: Fri, 14 Jul 2006 14:28:46 -0400 Message-Id: <20060714182846.285A716CBC@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Mon, 17 Jul 2006 22:06:13 -0400 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 "Alan DeKok" wrote: > If the server had some auditing capability for Authorize-Only > requests, an admin could correlate that information with > authentication performed by non-RADIUS servers. That would mitigate > the concerns over the RADIUS server not performing the authorization. ^^^^^^^^^^^^^ "authentication". Alan DeKok. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms Fri, 14 Jul 2006 14:28:46 -0400 Message-Id: <20060714182846.285A716CBC@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Mon, 17 Jul 2006 22:06:13 -0400 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 "Alan DeKok" wrote: > If the server had some auditing capability for Authorize-Only > requests, an admin could correlate that information with > authentication performed by non-RADIUS servers. That would mitigate > the concerns over the RADIUS server not performing the authorization. ^^^^^^^^^^^^^ "authentication". Alan DeKok. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 18 00:16:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2h0A-0007Om-4g; Tue, 18 Jul 2006 00:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2h09-0007Oh-B3 for isms@ietf.org; Tue, 18 Jul 2006 00:16:05 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2h07-0001IQ-Va for isms@ietf.org; Tue, 18 Jul 2006 00:16:05 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id A614411D7B0; Mon, 17 Jul 2006 19:03:44 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Mon, 17 Jul 2006 19:03:44 -0700 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Cc: Subject: [Isms] using notifications with SNMP/SSH 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 following is based on the message I sent out in January about sending notifications over SNMP/SSH and the usable authentication mechanisms. It's been edited heavily for improved readability and usability. I can probably be coerced into further formalizing the writing for suitable inclusion into the resulting draft assuming the description below is sufficient for forward progress. I'll send the original again for reference right after I ship this one off. I won't be able to respond to comments on the following text until after mid-next week unfortunately. Note: I have not trolled through all the docs to make sure everything below is 100% accurate and secure. Think of it as a white-board diagram not an end-specification. 1.0 Background 1.1 Terminology Politically correct SNMP terms: CG = command generator CR = command responder NG = notification generator NR = notification responder SSH terms: LoF = Leap of Faith 1.2 Basic Notification Configuration The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB already allow for configuration of notification receivers destinations to which notifications should be sent. The following examples depict possible configuration of this setup using a USM configuration. snmpTargetParamsTable row: snmpTargetParamsName toCR (administrative string) snmpTargetParamsMPModel 3 (SNMPv3) * snmpTargetParamsSecurityModel 3 (USM) * snmpTargetParamsSecurityName usmUser (The USM user name) snmpTargetParamsSecurityLevel 3 (auth|encr) snmpTargetParamsStorageType 3 (nonVolatile) snmpTargetParamsRowStatus 4 (createAndGo) snmpTargetAddrTable row: snmpTargetAddrName toCRAddr (arbitrary string) snmpTargetAddrTDomain snmpUDPDomain snmpTargetAddrTAddress 0x0A00000100A2 (CR address, port) snmpTargetAddrTimeout 1500 (in .01 sec) snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (must match prev table) snmpTargetAddrStorageType 3 (nonVolatile) snmpTargetAddrColumnStatus 4 (createAndGo) snmpNotifyTable row: snmpNotifyName CRNotif (arbitrary string) snmpNotifyTag toCRTag (matches tag list above) snmpNotifyType 2 (inform) snmpNotifyStorageType 3 (nonVolatile) snmpNotifyColumnStatus 4 (createAndGo) The above will configure an agent to act as a NG and send informs to the NR at 10.0.0.1 port 162 using the SNMPv3/USM user "usmUser". The configuration for the "usmUser" settings in the SNMP-USER-BASED-SM-MIB and SNMP-VIEW-BASED-ACM-MIB objects are not shown here for brevity. The columns marked with a "*" are the items that are USM specific. We'll refer back in later sections about how this changes when using SNMP/SSH. 2.0 Notification Generation by a Notification Responder Notification Generators (NGs) need to send notifications to management stations acting as a Notification Responders (NRs). There are three possibilities for how this might be done depending on the current SNMP/SSH sessions available for use and the directionality associated with them. Section 2.1 describes 2 authentication mechanism procedures for how a Notification Generator would open and authenticate a SNMP/SSH connection to a Notification Receiver. Section 2.2 describes how a Notification Receiver can open a connection (or more than one) to the Notification Generator and configure it to send notifications over an existing connection. 2.1 A Notification Generator Opening a SNMP/SSH Connection to the Notification Responder There are a number of interesting issues with how to do the case where a Notification Generator needs to open a connection to the Notification Receiver. The hardest issue with this has been authentication mechanism to authenticate the NG at the NR side. Additionally, the NR must be authenticated at the NG side and the NG must properly check VACM settings to ensure each notification sent to the NR is authorized. 2.1.1 Authentication Using a User Credential Devices could be configured with user credentials (EG, a user name and the user's public-key or password) to use when connecting to a NR. This would make use of the normal user-to-host mode of operation of SSH. Steps to send the notification: 1) The NG would open a SNMP/SSH connection to the NR. 2) The NR would send it's public key and proof of ownership 3) The NG would verify that it was talking to the expected NR (by verifying the public key against the proof and by verifying that the public key presented matched the expected public key for that destination). 4) The NG would transmit it's user name and it's own credentials (either the a public key, and proof or a password). 5) The NR would verify the authenticity of the received credentials. 6) The NG would send the notification through the established connection. The configuration pieces missing that are not currently available in any modern MIBs at this time: A) Ability to specify the SSH user credential type to use (eg, public key or password) B) the ability to configure that public-key or password C) end-destination expected public SSH host-key - the public key of the NR the NG should be connecting to. This would result in notification destination parameter configuration that looked like (the settings explained next): snmpTargetParamsTable row: snmpTargetParamsName toCR (administrative string) snmpTargetParamsMPModel 3 (SNMPv3) * snmpTargetParamsSecurityModel 4 (SNMP/SSH mapping) * snmpTargetParamsSecurityName sshParams (The SSH parameter name) snmpTargetParamsSecurityLevel 3 (auth|encr) snmpTargetParamsStorageType 3 (nonVolatile) snmpTargetParamsRowStatus 4 (createAndGo) snmpTargetAddrTable row: snmpTargetAddrName toCRAddr (arbitrary string) + snmpTargetAddrTDomain snmpTCPDomain ++ snmpTargetAddrTAddress 0x0A00000100A2 (CR address, port) snmpTargetAddrTimeout 1500 (in .01 sec) snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (must match prev) snmpTargetAddrStorageType 3 (nonVolatile) snmpTargetAddrColumnStatus 4 (createAndGo) * = changed since previous example. + = may change to SSHDomain? subject to debate ++ = shown as same but will likely change (port number likely new from IANA) Because we need 3 configuration settings (A, B, and C above) and there is no room in the existing tables for that information, we'll need to create another table to contain the needed settings. This will be the snmpSSHParametersTable and will contain the following information: snmpSSHParametersTable: snmpSSHParameterName sshParams (matches 2nd * above) snmpSSHUserName sshUser (the NG says "I'm sshUser") snmpSSHUserCredentialType 1 (1 = userPublicKey, 2 = userPassword, 3 = hostPublicKey ... enum list should be pulled from ssh auth types?) snmpSSHNRUserKey +++ (the expected NG Key) snmpSSHNRUserPass ++++ (the passphrase to use) snmpSSHNRHostKey +++ (the expected NR Key) +++ = issue with config via SNMP since these are potentially larger than SNMP/UDP would like. ++++ = GET = "", SET = set it? With all of this in place it is possible for a NG to ope a connection to a NR and authenticate itself and verify the other end is the expected end. It is implementation dependent how the NR decides whether to accept notifications given the authentication provided by the NG. This is already true for SNMPv3/USM NR engines today. 2.1.2 Authentication Using a SSH Host-Key Devices with deployed SSH Host public-key credentials ("Host-Keys") already have a public key that is likely known to a network management station. This is the same host identity that must be authenticated to when connecting to an agent operating as a CR when a management station takes on the role of a CG. It is possible to reuse the agent's (CR's) SSH public host key when operating as a NG to open a connection back to a NR. To accomplish this, the NG would open a SSH connection to the NR and both sides would authenticate each other. The NR would use a host-key certificate per-normal SSH usage. The NG would present it's own host-key certificate to authenticate itself rather than present the more typical user-based credential as discussed in section 2.1.1. How to accomplish this via the SSH protocol is discussed in Section 9 of [RFC4252]. Note that for SSH this form of authentication is optional. Steps to send the notification: 1) The NG would open a SNMP/SSH connection to the NR. 2) The NR would send it's public key and proof of ownership 3) The NG would verify that it was talking to the expected NR (by verifying the public key against the proof and by verifying that the public key presented matched the expected public key for that destination). 4) The NG would transmit it's user name (see below) and it's host credential. 5) The NR would verify the authenticity of the received credentials. 6) The NG would send the notification through the established connection. Note: Section 9 of [RFC4252] actually specifies that for authorization purposes the NR can ignore the user name field for this authentication type. The NG must fill it in, however. For the new snmpSSHParametersTable settings, they would look like: snmpSSHParametersTable: snmpSSHParameterName sshParams (matches 2nd * above) snmpSSHUserName sshUser (the NG says "I'm sshUser") * snmpSSHUserCredentialType 3 (1 = userPublicKey, 2 = userPassword, 3 = hostPublicKey ... enum list should be pulled from ssh auth types?) * snmpSSHNRUserKey "" (the expected NG Key) (blank = default host key) snmpSSHNRUserPass "" (none) snmpSSHNRHostKey +++ (the expected NR Key) * = changed from last time +++ = issue with config via SNMP since these are potentially larger than SNMP/UDP would like. With the above in place, it should be possible to open a host-key based authentication from the NG to an NR. It is implementation dependent how the NR decides whether to accept notifications given the authentication provided by the NG. This is already true for SNMPv3/USM NR engines today. The primary advantage of this over the user-based credentials used in Section 2.1.1 is that the host-key has likely already been created and no credential configuration is needed. The NR, however, still needs to be configured to accept notifications from an NG using it's host-key credentials (and tied to the snmpSSHUserName passed in the "user name" field of the SSH_MSG_USERAUTH_REQUEST message described in Section 9 of [RFC4252]. 2.2 Reusing an existing SNMP/SSH Connection That Was Previously Established between the NG and NR. There has been desire to have an architecture where a Notification Receiver connects to a Notification Generator and notifications are then sent via this connection. This section describes how this can be done via SNMP/SSH using additional MIB configuration settings. Steps to send the notification: 1) The NR would open a SNMP/SSH connection to the NG. There are two choices here: a) Open only a single connection to the standard CR service endpoint which also happens to be capable of sending notifications back over the same stream (acting as a NG on the same session). b) One connection to the standard CR service, and a second to a NG service port. Note that notifications would not be sent until the rest of the following steps had taken place. 2) The CR and/or NG service(s) would send it's public key and proof of ownership. 3) The CG and/or NR would verify that it was talking to the expected CR/NG (by verifying the public key against the proof and by verifying that the public key presented matched the expected public key for that destination). 4) The CG/NR would transmit it's user name and credentials (either a public key, password or other SSH authentication mechanism). 5) The CR/NG would verify the authenticity of the received credentials. 6) The CG would configure the CR to send notifications over the already existing SNMP/SSH channels (configuration of the snmpNotifyTable not shown as it matches that in section 1.2): snmpTargetParamsTable row: snmpTargetParamsName toCR (administrative string) snmpTargetParamsMPModel 3 (SNMPv3) * snmpTargetParamsSecurityModel 4 (SSH) * snmpTargetParamsSecurityName XXX (see below) snmpTargetParamsSecurityLevel 3 (auth|encr) snmpTargetParamsStorageType 3 (nonVolatile) snmpTargetParamsRowStatus 4 (createAndGo) snmpTargetAddrTable row: snmpTargetAddrName toCRAddr (arbitrary string) * snmpTargetAddrTDomain snmpSSHSession * snmpTargetAddrTAddress YYY (see below) snmpTargetAddrTimeout 1500 (in .01 sec) snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (must match prev) snmpTargetAddrStorageType 3 (nonVolatile) snmpTargetAddrColumnStatus 4 (createAndGo) * = changed since previous example. In order to enable the NG to start sending notifications over either the current ssh session (the connection to the CR service) or another SSH session (a connection to the NG service), the XXX value of the snmpTargetParamsSecurityName and the YYY parameter of the snmpTargetAddrTAddress field need to be filled into to point to the proper session. This could be done in 2 different ways that I can think of (possibly more): option 1) snmpTargetAddrTDomain = snmpSSHSession snmpTargetParamsSecurityName = XXX = "NRUser" snmpTargetAddrTAddress = YYY = "" This would effectively state that the NG could send notifications to all connected SNMP/SSH sessions that the incoming (***only***) SNMP/SSH connection had authenticated as the SNMP/SSH user "NRUser". Outgoing sessions from the NG MUST NOT be checked for when looking for sessions that match this criteria. The VACM would be consulted based on the SNMP/SSH security model and the security Name of "NRUser" in this example. option 2) snmpTargetAddrTDomain = snmpSSHSession snmpTargetParamsSecurityName = XXX = "" snmpTargetAddrTAddress = YYY = 0x00000001 (session id) This would effectively state that the NG could send notifications to the SNMP/SSH session with a session id of 1. This could potentially be the exact same session that the CG/CR were speaking over, or it could be an "external" session such as one connected to via the CR. The VACM would be consulted based on the SNMP/SSH security model and the security name of the ***remote*** user name associated with the remote session #1 for incoming sessions. Outgoing sessions MUST NOT be referred to by the NG (see ????) (???? aside: actually I'm not sure this is required from a security stand point, but I don't like the security name associations that would have to happen between the configuration and the sessions... I'd rather just only do this for incoming sessions as it doesn't make my hairs stand up as potentially problematic). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 18 13:04:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2szh-0002dT-No; Tue, 18 Jul 2006 13:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2szf-0002dD-H4 for isms@ietf.org; Tue, 18 Jul 2006 13:04:23 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2szc-000583-Q4 for isms@ietf.org; Tue, 18 Jul 2006 13:04:23 -0400 Received: from harrington73653 (c-24-61-137-43.hsd1.nh.comcast.net[24.61.137.43]) by comcast.net (alnrmhc13) with SMTP id <20060718170419b1300ftcrle>; Tue, 18 Jul 2006 17:04:19 +0000 From: "David Harrington" To: "'Wes Hardaker'" , Subject: RE: [Isms] using notifications with SNMP/SSH Date: Tue, 18 Jul 2006 13:03:02 -0400 Message-ID: <016201c6aa8c$0833e580$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaqIOONUgITAw2hQ++c8gxEtChTJwAZ/Usw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 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, I need some editorial guidance from the WG and the chairs. The consensus has been that the SSH particulars be hidden. As a result, we have not defined (in fact I have removed) a MIB to carry SSH-specific parameters. The current documents just say there is SSH-specific (or transport-specific) data stored in a Local Configuration Datastore. If that is all we need, then the documents may be close to done, but there is quite a bit of hand-waving about implementation-dependent configuration and parameter passing. I think this will make it harder to get independent interoperable SSHSM model implementations, but I am not implementing, so I could be wrong. Wes's email describes such an LCD and how it relates to the snmpTarget tables. Does the WG want an snmpSSHParametersTable included in the SSHSM document? Should I put this into an appendix as a sample of how an LCD might be designed? Should this be a normative MIB module to allow SNMP configuration of the security model (we cnosidered snmp configurability important for the snmpv3 standard)? I think defining a MIB module, either informative or normative, might be helpful to guide implementors, but we risk defining a model that is harder to integrate with some implementations of SSH and SNMP. By relying on an implementation-dependent opaque datastore of transport parameters, we have been able to genericize the session-based security model wording to be transport independent. If we define a MIB module for SSHParameters, we may not be able to hide the security-model elements of procedure details behind an opaque LCD. Should we define an snmpSSHParametersTable, and reference the managed objects in the elements of procedure section? dbh > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Monday, July 17, 2006 10:04 PM > To: isms@ietf.org > Subject: [Isms] using notifications with SNMP/SSH > > > The following is based on the message I sent out in January about > sending notifications over SNMP/SSH and the usable authentication > mechanisms. It's been edited heavily for improved readability and > usability. I can probably be coerced into further formalizing the > writing for suitable inclusion into the resulting draft assuming > the description below is sufficient for forward progress. > > I'll send the original again for reference right after I ship this one > off. I won't be able to respond to comments on the following text > until after mid-next week unfortunately. > > Note: I have not trolled through all the docs to make sure everything > below is 100% accurate and secure. Think of it as a white-board > diagram not an end-specification. > > > > 1.0 Background > > 1.1 Terminology > > Politically correct SNMP terms: > > CG = command generator > CR = command responder > NG = notification generator > NR = notification responder > > SSH terms: > > LoF = Leap of Faith > > 1.2 Basic Notification Configuration > > The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB already allow for > configuration of notification receivers destinations to which > notifications should be sent. The following examples depict > possible configuration of this setup using a USM configuration. > > snmpTargetParamsTable row: > snmpTargetParamsName toCR > (administrative string) > snmpTargetParamsMPModel 3 (SNMPv3) > * snmpTargetParamsSecurityModel 3 (USM) > * snmpTargetParamsSecurityName usmUser (The USM user name) > snmpTargetParamsSecurityLevel 3 (auth|encr) > snmpTargetParamsStorageType 3 (nonVolatile) > snmpTargetParamsRowStatus 4 (createAndGo) > > snmpTargetAddrTable row: > snmpTargetAddrName toCRAddr > (arbitrary string) > snmpTargetAddrTDomain snmpUDPDomain > snmpTargetAddrTAddress 0x0A00000100A2 (CR > address, port) > snmpTargetAddrTimeout 1500 (in .01 sec) > snmpTargetAddrRetryCount 3 > snmpTargetAddrTagList toCRTag > snmpTargetAddrParams toCR (must > match prev table) > snmpTargetAddrStorageType 3 (nonVolatile) > snmpTargetAddrColumnStatus 4 (createAndGo) > > > snmpNotifyTable row: > snmpNotifyName CRNotif > (arbitrary string) > snmpNotifyTag toCRTag > (matches tag list above) > snmpNotifyType 2 (inform) > snmpNotifyStorageType 3 (nonVolatile) > snmpNotifyColumnStatus 4 (createAndGo) > > > The above will configure an agent to act as a NG and send informs to > the NR at 10.0.0.1 port 162 using the SNMPv3/USM user "usmUser". > The configuration for the "usmUser" settings in the > SNMP-USER-BASED-SM-MIB and SNMP-VIEW-BASED-ACM-MIB objects are not > shown here for brevity. The columns marked with a "*" are the items > that are USM specific. > > We'll refer back in later sections about how this changes when using > SNMP/SSH. > > 2.0 Notification Generation by a Notification Responder > > Notification Generators (NGs) need to send notifications to > management > stations acting as a Notification Responders (NRs). There are three > possibilities for how this might be done depending on the current > SNMP/SSH sessions available for use and the directionality > associated > with them. > > Section 2.1 describes 2 authentication mechanism procedures for how > a Notification Generator would open and authenticate a SNMP/SSH > connection to a Notification Receiver. > > Section 2.2 describes how a Notification Receiver can open a > connection (or more than one) to the Notification Generator and > configure it to send notifications over an existing connection. > > 2.1 A Notification Generator Opening a SNMP/SSH Connection to the > Notification Responder > > There are a number of interesting issues with how to do the case > where a Notification Generator needs to open a connection to the > Notification Receiver. The hardest issue with this has been > authentication mechanism to authenticate the NG at the NR side. > Additionally, the NR must be authenticated at the NG side and the > NG must properly check VACM settings to ensure each notification > sent to the NR is authorized. > > 2.1.1 Authentication Using a User Credential > > Devices could be configured with user credentials (EG, a user name > and the user's public-key or password) to use when connecting to a > NR. This would make use of the normal user-to-host mode of > operation of SSH. > > Steps to send the notification: > > 1) The NG would open a SNMP/SSH connection to the NR. > > 2) The NR would send it's public key and proof of ownership > > 3) The NG would verify that it was talking to the > expected NR (by > verifying the public key against the proof and by verifying > that the public key presented matched the expected public key > for that destination). > > 4) The NG would transmit it's user name and it's own credentials > (either the a public key, and proof or a password). > > 5) The NR would verify the authenticity of the received > credentials. > > 6) The NG would send the notification through the established > connection. > > The configuration pieces missing that are not currently available > in any modern MIBs at this time: > > A) Ability to specify the SSH user credential type to use > (eg, public key or password) > > B) the ability to configure that public-key or password > > C) end-destination expected public SSH host-key > > - the public key of the NR the NG should be connecting to. > > This would result in notification destination parameter > configuration that looked like (the settings explained next): > > snmpTargetParamsTable row: > snmpTargetParamsName toCR > (administrative string) > snmpTargetParamsMPModel 3 (SNMPv3) > * snmpTargetParamsSecurityModel 4 > (SNMP/SSH mapping) > * snmpTargetParamsSecurityName sshParams (The SSH > parameter name) > snmpTargetParamsSecurityLevel 3 (auth|encr) > snmpTargetParamsStorageType 3 (nonVolatile) > snmpTargetParamsRowStatus 4 (createAndGo) > > snmpTargetAddrTable row: > snmpTargetAddrName toCRAddr > (arbitrary string) > + snmpTargetAddrTDomain snmpTCPDomain > ++ snmpTargetAddrTAddress 0x0A00000100A2 (CR > address, port) > snmpTargetAddrTimeout 1500 (in > .01 sec) > snmpTargetAddrRetryCount 3 > snmpTargetAddrTagList toCRTag > snmpTargetAddrParams toCR > (must match prev) > snmpTargetAddrStorageType 3 > (nonVolatile) > snmpTargetAddrColumnStatus 4 > (createAndGo) > > > * = changed since previous example. > + = may change to SSHDomain? subject to debate > ++ = shown as same but will likely change (port number > likely new from IANA) > > Because we need 3 configuration settings (A, B, and C above) and > there is no room in the existing tables for that information, > we'll need to create another table to contain the needed > settings. This will be the snmpSSHParametersTable and will > contain the following information: > > snmpSSHParametersTable: > snmpSSHParameterName sshParams (matches > 2nd * above) > snmpSSHUserName sshUser (the NG > says "I'm sshUser") > snmpSSHUserCredentialType 1 (1 = > userPublicKey, > 2 = > userPassword, > 3 = > hostPublicKey > ... enum list > should be pulled > from > ssh auth types?) > snmpSSHNRUserKey +++ (the > expected NG Key) > snmpSSHNRUserPass ++++ (the > passphrase to use) > snmpSSHNRHostKey +++ (the > expected NR Key) > > +++ = issue with config via SNMP since these are potentially > larger than SNMP/UDP would like. > ++++ = GET = "", SET = set it? > > With all of this in place it is possible for a NG to ope a > connection to a NR and authenticate itself and verify the other > end is the expected end. > > It is implementation dependent how the NR decides whether to > accept notifications given the authentication provided by the NG. > This is already true for SNMPv3/USM NR engines today. > > 2.1.2 Authentication Using a SSH Host-Key > > Devices with deployed SSH Host public-key credentials > ("Host-Keys") already have a public key that is likely known to a > network management station. This is the same host identity that > must be authenticated to when connecting to an agent operating as > a CR when a management station takes on the role of a CG. It is > possible to reuse the agent's (CR's) SSH public host key when > operating as a NG to open a connection back to a NR. > > To accomplish this, the NG would open a SSH connection to the NR > and both sides would authenticate each other. The NR would use a > host-key certificate per-normal SSH usage. The NG would present > it's own host-key certificate to authenticate itself rather than > present the more typical user-based credential as discussed in > section 2.1.1. > > How to accomplish this via the SSH protocol is discussed in > Section 9 of [RFC4252]. Note that for SSH this form of > authentication is optional. > > > Steps to send the notification: > > 1) The NG would open a SNMP/SSH connection to the NR. > > 2) The NR would send it's public key and proof of ownership > > 3) The NG would verify that it was talking to the > expected NR (by > verifying the public key against the proof and by verifying > that the public key presented matched the expected public key > for that destination). > > 4) The NG would transmit it's user name (see below) and it's > host credential. > > 5) The NR would verify the authenticity of the received > credentials. > > 6) The NG would send the notification through the established > connection. > > Note: Section 9 of [RFC4252] actually specifies that for > authorization purposes the NR can ignore the user name field for > this authentication type. The NG must fill it in, however. > > For the new snmpSSHParametersTable settings, they would look > like: > > snmpSSHParametersTable: > snmpSSHParameterName sshParams (matches > 2nd * above) > snmpSSHUserName sshUser (the NG > says "I'm sshUser") > * snmpSSHUserCredentialType 3 (1 = > userPublicKey, > 2 = > userPassword, > 3 = > hostPublicKey > ... enum list > should be pulled > from > ssh auth types?) > * snmpSSHNRUserKey "" (the > expected NG Key) > (blank = > default host key) > snmpSSHNRUserPass "" (none) > snmpSSHNRHostKey +++ (the > expected NR Key) > > * = changed from last time > +++ = issue with config via SNMP since these are potentially > larger than SNMP/UDP would like. > > > With the above in place, it should be possible to open a host-key > based authentication from the NG to an NR. > > It is implementation dependent how the NR decides whether to > accept notifications given the authentication provided by the NG. > This is already true for SNMPv3/USM NR engines today. > > The primary advantage of this over the user-based credentials used > in Section 2.1.1 is that the host-key has likely already been > created and no credential configuration is needed. The NR, > however, still needs to be configured to accept notifications from > an NG using it's host-key credentials (and tied to the > snmpSSHUserName passed in the "user name" field of the > SSH_MSG_USERAUTH_REQUEST message described in Section 9 of > [RFC4252]. > > 2.2 Reusing an existing SNMP/SSH Connection That Was Previously > Established between the NG and NR. > > There has been desire to have an architecture where a Notification > Receiver connects to a Notification Generator and notifications > are then sent via this connection. This section describes how > this can be done via SNMP/SSH using additional MIB configuration > settings. > > Steps to send the notification: > > 1) The NR would open a SNMP/SSH connection to the NG. There are > two choices here: > > a) Open only a single connection to the standard CR service > endpoint which also happens to be capable of sending > notifications back over the same stream (acting as a NG on > the same session). > b) One connection to the standard CR service, and a second to > a NG service port. > > Note that notifications would not be sent until the rest of > the following steps had taken place. > > 2) The CR and/or NG service(s) would send it's public key and > proof of ownership. > > 3) The CG and/or NR would verify that it was talking to the > expected CR/NG (by verifying the public key against the proof > and by verifying that the public key presented matched the > expected public key for that destination). > > 4) The CG/NR would transmit it's user name and credentials > (either a public key, password or other SSH authentication > mechanism). > > 5) The CR/NG would verify the authenticity of the received > credentials. > > 6) The CG would configure the CR to send notifications over the > already existing SNMP/SSH channels (configuration of the > snmpNotifyTable not shown as it matches that in section 1.2): > > snmpTargetParamsTable row: > snmpTargetParamsName toCR > (administrative string) > snmpTargetParamsMPModel 3 (SNMPv3) > * snmpTargetParamsSecurityModel 4 (SSH) > * snmpTargetParamsSecurityName XXX (see below) > snmpTargetParamsSecurityLevel 3 (auth|encr) > snmpTargetParamsStorageType 3 (nonVolatile) > snmpTargetParamsRowStatus 4 (createAndGo) > > snmpTargetAddrTable row: > snmpTargetAddrName toCRAddr > (arbitrary string) > * snmpTargetAddrTDomain snmpSSHSession > * snmpTargetAddrTAddress YYY (see below) > snmpTargetAddrTimeout 1500 (in > .01 sec) > snmpTargetAddrRetryCount 3 > snmpTargetAddrTagList toCRTag > snmpTargetAddrParams toCR > (must match prev) > snmpTargetAddrStorageType 3 > (nonVolatile) > snmpTargetAddrColumnStatus 4 > (createAndGo) > > > * = changed since previous example. > > > In order to enable the NG to start sending notifications over > either the current ssh session (the connection to the CR service) > or another SSH session (a connection to the NG service), the XXX > value of the snmpTargetParamsSecurityName and the YYY parameter of > the snmpTargetAddrTAddress field need to be filled into to point > to the proper session. This could be done in 2 different ways > that I can think of (possibly more): > > option 1) > > snmpTargetAddrTDomain = snmpSSHSession > snmpTargetParamsSecurityName = XXX = "NRUser" > snmpTargetAddrTAddress = YYY = "" > > This would effectively state that the NG could send > notifications > to all connected SNMP/SSH sessions that the incoming > (***only***) > SNMP/SSH connection had authenticated as the SNMP/SSH user > "NRUser". Outgoing sessions from the NG MUST NOT be checked for > when looking for sessions that match this criteria. The VACM > would be consulted based on the SNMP/SSH security model and the > security Name of "NRUser" in this example. > > option 2) > > snmpTargetAddrTDomain = snmpSSHSession > snmpTargetParamsSecurityName = XXX = "" > snmpTargetAddrTAddress = YYY = 0x00000001 (session id) > > This would effectively state that the NG could send > notifications to the SNMP/SSH session with a session id of 1. > This could potentially be the exact same session that the CG/CR > were speaking over, or it could be an "external" session such as > one connected to via the CR. The VACM would be consulted based > on the SNMP/SSH security model and the security name of the > ***remote*** user name associated with the remote session #1 for > incoming sessions. Outgoing sessions MUST NOT be referred to by > the NG (see ????) > > (???? aside: actually I'm not sure this is required from a > security stand point, but I don't like the security name > associations that would have to happen between the configuration > and the sessions... I'd rather just only do this for incoming > sessions as it doesn't make my hairs stand up as potentially > problematic). > -- > Wes Hardaker > Sparta, Inc. > > _______________________________________________ > 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 Jul 18 18:10:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xlt-0000Xi-NC; Tue, 18 Jul 2006 18:10:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xls-0000Xc-Sc for isms@ietf.org; Tue, 18 Jul 2006 18:10:28 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2xlm-0005U1-K2 for isms@ietf.org; Tue, 18 Jul 2006 18:10:28 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 18:10:21 -0400 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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Tue, 18 Jul 2006 18:10:20 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219379@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcaoRVG02UdoqaT/Tk6lTHErEnDykgCRXPfAAAp4gIA= From: "Nelson, David" To: , X-OriginalArrivalTime: 18 Jul 2006 22:10:21.0171 (UTC) FILETIME=[F5D3DC30:01C6AAB6] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Avi Lior writes... =20 > I am having trouble understanding "user that is not actually present". In the proposed use case, the NAS could request, from a RADIUS server, authorization information for a user that it asserts is present, but is not. The RADIUS server cannot tell, since no user credentials are presented. Well behaved NASes won't do this. One might argue that all trusted NASes will be well behaved, but that makes certain threat model assumptions. Why would a (compromised) NAS want to do this? Well, leaking authorization information on various user accounts may help an attacker select high value target accounts.=20 The only standardized scenario for non-authenticated authorization RADIUS is call check. The assumption is that the PSTN is a reliable source of the telephone number(s), the NAS is trusted and non-compromised, and the user will typically be authenticated once the session is initiated. Thus, the risk is relatively low. For Dynamic RADIUS, RFC 3576 requires a State attribute, which can only have come from a previous successful authentication. In this particular ISMS use case, SNMP service is authorized based on the assertion of identity of the user by the NAS, without the RADIUS server ever having performed an authentication, and without the benefit of the resultant State attribute. Thus, the risk is potentially higher. The questions at hand are whether the risk is high enough to be of serious concern, and whether or not it can be mitigated? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 18 18:34:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2y9N-0004L3-NV; Tue, 18 Jul 2006 18:34:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2y9M-0004Kv-74 for isms@ietf.org; Tue, 18 Jul 2006 18:34:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2y9K-0006Ja-Rh for isms@ietf.org; Tue, 18 Jul 2006 18:34:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 18 Jul 2006 15:34:42 -0700 X-IronPort-AV: i="4.06,256,1149490800"; d="scan'208"; a="306555497:sNHT25792808" 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.20060308/8.12.11) with ESMTP id k6IMYg1N013586; Tue, 18 Jul 2006 15:34:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6IMYg2D019284; Tue, 18 Jul 2006 15:34:42 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 15:34:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Tue, 18 Jul 2006 15:34:40 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250253CE18@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcaoRVG02UdoqaT/Tk6lTHErEnDykgCRXPfAAAp4gIAAARjBkA== From: "Glen Zorn \(gwz\)" To: "Nelson, David" X-OriginalArrivalTime: 18 Jul 2006 22:34:41.0880 (UTC) FILETIME=[5C7A5D80:01C6AABA] DKIM-Signature: a=rsa-sha1; q=dns; l=1330; t=1153262082; x=1154126082; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session=20summary); X=v=3Dcisco.com=3B=20h=3DCjpP+uhlnMxVEplGPhlYMpJKjW8=3D; b=VUEEyTK54yHOA3X3eZkd/nUSi7Wibrb9x3cJBxmtCouO9wwUwpoCuCi5JXtyfa69EA52H5pb cp3tDr4C2W2k7E7YHUdSBwIv0Lx8y3T4lfy7KK5OSu19Vvdp2q5J7sbu; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: isms@ietf.org, radiusext@ops.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 Nelson, David supposedly scribbled: ... >=20 > In this particular ISMS use case, SNMP service is authorized based on > the assertion of identity of the user by the NAS, without the RADIUS > server ever having performed an authentication, and without the > benefit of the resultant State attribute. Thus, the risk is > potentially higher. =20 Actually, the same risk has always been present in RADIUS, because of = the way that PPP CHAP (&, for that matter, the MD5-Challenge EAP method) = is implemented. The RADIUS server in the CHAP case generally has no = idea whether the user is actually present or not: the NAS presents the = server with a self-generated challenge and a response that may or may = not be a replay; without saving every challenge-response pair, the = server cannot know if the response is fresh or not. =20 >=20 > The questions at hand are whether the risk is high enough to be of > serious concern, and whether or not it can be mitigated?=20 The risk I mention above has never seemed to bother anyone, at least not = enough to fix it; I don't know why we should be obsessing over it now. ... Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 18 18:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ySM-0006F1-0z; Tue, 18 Jul 2006 18:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ySK-0006CZ-Du for isms@ietf.org; Tue, 18 Jul 2006 18:54:20 -0400 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ySG-00072x-20 for isms@ietf.org; Tue, 18 Jul 2006 18:54:20 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id BAF5216E3C; Tue, 18 Jul 2006 18:45:05 -0400 (EDT) From: "Alan DeKok" To: "Glen Zorn \(gwz\)" Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) In-Reply-To: Your message of "Tue, 18 Jul 2006 15:34:40 PDT." <4C0FAAC489C8B74F96BEAD85EAEB26250253CE18@xmb-sjc-215.amer.cisco.com> Date: Tue, 18 Jul 2006 18:45:05 -0400 Message-Id: <20060718224505.BAF5216E3C@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: isms@ietf.org, radiusext@ops.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 "Glen Zorn \(gwz\)" wrote: > The risk I mention above has never seemed to bother anyone, at least not > enough to fix it; True. I think the concern here is that the user has not been authenticated. In the above scenario, the bad guesses have been rejected, and no additional information leaks from the RADIUS server to the NAS. If the user is authenticated, then information about the user can, and should be sent from the server to the NAS. I could rephrase the original question as: what information can the RADIUS server send to the NAS about the user, if the user was not authenticated through RADIUS? For privacy and security, I think the answer is "none". For useful networks, I think "authorize only" is pretty safe. If we look at another threat scenairo: A user is authenticated through RADIUS, and RADIUS returns authorization parameters in the Access-Accept. Since the contents of RADIUS packets aren't encrypted, anyone who can see that traffic can see all of the users authorization. So the information could be construed as public. In that case, there's little additional risk in sending that information, again unencrypted, to a NAS without authenticating the user. If the traffic *is* encrypted, then the previous analysis doesn't apply... Alan DeKok. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 18 19:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zOp-0000fT-0c; Tue, 18 Jul 2006 19:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zOo-0000fO-7c for isms@ietf.org; Tue, 18 Jul 2006 19:54:46 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2zOm-0002I7-U2 for isms@ietf.org; Tue, 18 Jul 2006 19:54:46 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 18 Jul 2006 16:54:44 -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.20060308/8.12.11) with ESMTP id k6INshFE019482; Tue, 18 Jul 2006 16:54:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6INsh2D029709; Tue, 18 Jul 2006 16:54:43 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 16:54:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Tue, 18 Jul 2006 16:54:42 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250253CEA1@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcaqvR+mdBpto3TzRp6ZPN3WTSHcqQABzy2g From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 18 Jul 2006 23:54:43.0679 (UTC) FILETIME=[8A92BEF0:01C6AAC5] DKIM-Signature: a=rsa-sha1; q=dns; l=2005; t=1153266883; x=1154130883; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session=20summary)=20; X=v=3Dcisco.com=3B=20h=3DCjpP+uhlnMxVEplGPhlYMpJKjW8=3D; b=jqI+104b1X1c3GUrrdZT5YXzCJJewPX/rE+CmUq6AHlVruZzXqh+nDdGO8xtag2sZvtnVVj/ p/diFYciulz8+wu5oNjcoks8DJGR/+9OvAwmiYxFBbcXK8/qeWQvyui5; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: isms@ietf.org, radiusext@ops.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 aland@nitros9.org supposedly scribbled: > "Glen Zorn \(gwz\)" wrote: >> The risk I mention above has never seemed to bother anyone, at least >> not enough to fix it; >=20 > True. I think the concern here is that the user has not been > authenticated. In the above scenario, the bad guesses=20 OK, yeah, but I didn't say anything about guesses: in that scenario, the = compromised NAS has saved valid credentials from previous = authentications & used them for nefarious purposes. > have been > rejected, and no additional information leaks from the RADIUS server > to the NAS. If the user is authenticated, then information about the > user can, and should be sent from the server to the NAS. =20 >=20 > I could rephrase the original question as: what information can the > RADIUS server send to the NAS about the user, if the user was not > authenticated through RADIUS? =20 >=20 > For privacy and security, I think the answer is "none". For useful > networks, I think "authorize only" is pretty safe.=20 >=20 > If we look at another threat scenairo: A user is authenticated > through RADIUS, and RADIUS returns authorization parameters in the > Access-Accept. Since the contents of RADIUS packets aren't > encrypted, anyone who can see that traffic can see all of the users > authorization. So the information could be construed as public. =20 >=20 > In that case, there's little additional risk in sending that > information, again unencrypted, to a NAS without authenticating the > user. =20 >=20 > If the traffic *is* encrypted, then the previous analysis doesn't > apply...=20 I hope that the issue is not divulging the contents of RADIUS attributes = but something a bit more serious, like authorizing an imposter. >=20 > Alan DeKok. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 19 00:09:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33Nb-0008Ti-SN; Wed, 19 Jul 2006 00:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33Na-0008Td-Ic for isms@ietf.org; Wed, 19 Jul 2006 00:09:46 -0400 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G33NZ-0006Jo-96 for isms@ietf.org; Wed, 19 Jul 2006 00:09:46 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 8779416E3C; Wed, 19 Jul 2006 00:00:44 -0400 (EDT) From: "Alan DeKok" To: "Glen Zorn \(gwz\)" Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) In-Reply-To: Your message of "Tue, 18 Jul 2006 16:54:42 PDT." <4C0FAAC489C8B74F96BEAD85EAEB26250253CEA1@xmb-sjc-215.amer.cisco.com> Date: Wed, 19 Jul 2006 00:00:44 -0400 Message-Id: <20060719040044.8779416E3C@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: isms@ietf.org, radiusext@ops.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 "Glen Zorn \(gwz\)" wrote: > OK, yeah, but I didn't say anything about guesses: in that scenario, the > compromised NAS has saved valid credentials from previous = > authentications & used them for nefarious purposes. It could also save authorization parameters, for precisely the same reason. > I hope that the issue is not divulging the contents of RADIUS attributes > but something a bit more serious, like authorizing an imposter. A compromised NAS can authorize anyone it chooses for any purpose. If the threat we're trying to avoid is a compromised NAS, then there is little point in doing more security analysis. The NAS is *inside* of the RADIUS trust boundary, with all of the side-effects that result. If the threat we're trying to avoid is someone fooling a trusted NAS into leaking information about users, then that situation is somewhat more managable. Alan DeKok. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 20 15:57:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ee3-0008L0-Oc; Thu, 20 Jul 2006 15:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ee2-0008Ku-Ss for isms@ietf.org; Thu, 20 Jul 2006 15:57:14 -0400 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ee1-0001ef-MX for isms@ietf.org; Thu, 20 Jul 2006 15:57:14 -0400 Received: from h-68-165-3-195.snvacaid.dynamic.covad.net ([68.165.3.195] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1G3ee1-0001rp-00 for isms@ietf.org; Thu, 20 Jul 2006 15:57:13 -0400 Message-ID: <002a01c6ac36$e318c2a0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <016201c6aa8c$0833e580$0400a8c0@china.huawei.com> Subject: Re: [Isms] using notifications with SNMP/SSH Date: Thu, 20 Jul 2006 12:58:35 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 - > From: "David Harrington" > To: "'Wes Hardaker'" ; > Sent: Tuesday, July 18, 2006 10:03 AM > Subject: RE: [Isms] using notifications with SNMP/SSH ... > Should we define an snmpSSHParametersTable, and reference the managed > objects in the elements of procedure section? ... I'd say yes, if we ever want to provision these things in an interoperable way. However, since it's configuration data, shouldn't it be done in the form of a netconf data model rather than a MIB? But the question that really nags at me is whether this will still be subject to the same criticisms as USM with respect to the effort required to set up and maintain a system's security configuration. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 21 17:28:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42YG-0007Jo-1m; Fri, 21 Jul 2006 17:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42YF-0007IF-6B for isms@ietf.org; Fri, 21 Jul 2006 17:28:51 -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 1G42YD-0002lv-JC for isms@ietf.org; Fri, 21 Jul 2006 17:28:51 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2006 14:28:49 -0700 X-IronPort-AV: i="4.07,170,1151910000"; d="scan'208"; a="330715643:sNHT26363226" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6LLSmC5008613; Fri, 21 Jul 2006 14:28:48 -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 k6LLSmiB006179; Fri, 21 Jul 2006 14:28:48 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Jul 2006 14:28:48 -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 Date: Fri, 21 Jul 2006 14:27:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue Thread-Index: AcamoMmNnAEnI466RJyA/LWJ66zJ9QAG1JsgAZJeE4AAAavUIA== From: "Joseph Salowey \(jsalowey\)" To: "Nelson, David" , , X-OriginalArrivalTime: 21 Jul 2006 21:28:48.0152 (UTC) FILETIME=[A71C9980:01C6AD0C] DKIM-Signature: a=rsa-sha1; q=dns; l=1205; t=1153517329; x=1154381329; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3DObZ73vujEK3pOnVK5sX7aGBdRmQ=3D; b=lcXQGZYhHEpGogR4VQcF0UrnZIgeHKDr+VygJBOHaHo4ZZZRsfFRea6U7ux+fntN6KT+8SXG B1m1wXHRqEBwjh3yK55mqYpM6qqLgcDXC/9fKZA/NeBzMIxh9T09jOm7; Authentication-Results: sj-dkim-1.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Isms] RE: Follow up on Authorize Only issue 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 I agree with Avi, Glen and Alan. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Friday, July 21, 2006 1:44 PM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: Follow up on Authorize Only issue >=20 > > For the SSHSM usage case, the question is whether it is an=20 > > unacceptable security risk for a trusted NAS to be able to obtain=20 > > authorization information about a user that is not actually=20 > "present"=20 > > at the NAS? >=20 > My interpretation is that three respondents (Glen, Alan, Avi)=20 > believe that the answer is "no". The existing RADIUS trust=20 > model collapses if the NAS has been compromised and does=20 > nefarious or foolish things. >=20 > I'd like to determine if we have consensus on this position. If you > *have* an opinion on this issue, please *respond* whether you=20 > agree or disagree with this assertion. >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jul 22 13:09:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4Kz7-0004ii-DY; Sat, 22 Jul 2006 13:09:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4Kz5-0004iY-R4 for isms@ietf.org; Sat, 22 Jul 2006 13:09:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4JYf-0003Gs-9c for isms@ietf.org; Sat, 22 Jul 2006 11:38:25 -0400 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G4JNN-0004UR-75 for isms@ietf.org; Sat, 22 Jul 2006 11:26:46 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B478C16E1E; Sat, 22 Jul 2006 11:17:37 -0400 (EDT) From: "Alan DeKok" To: "Bernard Aboba" In-Reply-To: Your message of "Fri, 21 Jul 2006 23:57:53 PDT." Date: Sat, 22 Jul 2006 11:17:37 -0400 Message-Id: <20060722151737.B478C16E1E@mail.nitros9.org> X-Spam-Score: -1.1 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org, radiusext@ops.ietf.org Subject: [Isms] Re: Follow up on Authorize Only issue 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 "Bernard Aboba" wrote: > For example, should a NAS be able to retrieve the Tunnel-Password attribute > of any user, regardless of whether they are connected? i.e. A compromised NAS can leverage this requested feature to obtain that information more readily. Right now, if the NAS hasn't had a user log in through it, it can get those credentials only through a brute force attack on the password. The server *should* be able to catch that attack, mitigating the vulnerability. For users who have logged in through a compromised NAS, nearly all hope for security is lost. > If this is allowed, it should follow the principle of "least privilege", > only providing the attributes relevant to SSH. Which means that the Access-Request has to be recognizable as for SSH in this use-case. This means an attribute or value specifically for this purpose. The RADIUS server can then key off of that special request, and return a limited response. The use case should also enumerate the possible attributes and values needed in the Access-Accept, and state explicitely that responding with any other attributes or values may result in security violations. i.e. Other attributes and values SHOULD NOT be sent in the Access-Accept. Alan DeKok. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Jul 23 12:02:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4gP7-0007ru-UC; Sun, 23 Jul 2006 12:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4gP7-0007rp-2b for isms@ietf.org; Sun, 23 Jul 2006 12:02:05 -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 1G4gP5-0004Tp-NX for isms@ietf.org; Sun, 23 Jul 2006 12:02:05 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2006 09:02:03 -0700 X-IronPort-AV: i="4.07,173,1151910000"; d="scan'208"; a="435873937:sNHT26609632" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6NG23fh013591; Sun, 23 Jul 2006 09:02:03 -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 k6NG222D021038; Sun, 23 Jul 2006 09:02:03 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Jul 2006 09:02:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 23 Jul 2006 09:02:01 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250259749B@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue Thread-Index: AcatXDtdLUyDubsZS5mYy7NB27+YngBErYwQ From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" X-OriginalArrivalTime: 23 Jul 2006 16:02:02.0732 (UTC) FILETIME=[56326AC0:01C6AE71] DKIM-Signature: a=rsa-sha1; q=dns; l=1751; t=1153670523; x=1154534523; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3DgYUCFFU2lrC1AfD+49l4JpczLFs=3D; b=D7rhSGItymYOuz6XgSOOBnoycpvDMjHY3jiVtXhsg0fdydjH67/Fl1/PyU3QjoJnZQjBeFSg Q/KqZRlAcM/I/TaXdlc1y126A2IqdJYCuuIoyVANAZkXyklS0tC26xAT; Authentication-Results: sj-dkim-4.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: isms@ietf.org, radiusext@ops.ietf.org Subject: [Isms] RE: Follow up on Authorize Only issue 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 Bernard Aboba <> supposedly scribbled: > The security implications of unrestricted access to *any* user > attributes are fairly severe.=20 I agree, but apparently not severe enough to warrant changing the way = RADIUS handles CHAP at any time over, oh , the last 10 years. >=20 > For example, should a NAS be able to retrieve the Tunnel-Password > attribute of any user, regardless of whether they are connected?=20 Of course not, but there are arguably lots of things that shouldn't be = yet are: the point is that allowing Authorize-Only in this case actually = doesn't open any new security holes. >=20 > There are also VSAs that contain sensitive information. >=20 > The Call-Check Service typically provides very little information in > the Access-Accept (all that is needed is whether to accept or reject > the call) so there is minimal leakage. =20 >=20 > If this is allowed, it should follow the principle of "least > privilege", only providing the attributes relevant to SSH.=20 >=20 >=20 >=20 >=20 >> For the SSHSM usage case, the question is whether it is an >> unacceptable security risk for a trusted NAS to be able to obtain >> authorization information about a user that is not actually >> "present" at the NAS? OK, this is becoming slightly absurd. I am not a cryptographer, but I = do know that one of the cardinal assumptions of secret-key cryptography = is that the secret key stays secret. This "trusted NAS" should not be = trusted because the secret has been compromised; if the secret is no = longer a secret, all bets are off.=20 Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 24 05:36:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4wrG-00058M-8e; Mon, 24 Jul 2006 05:36:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4wrF-00058H-1b for isms@ietf.org; Mon, 24 Jul 2006 05:36:13 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4wrC-0006C8-IG for isms@ietf.org; Mon, 24 Jul 2006 05:36:13 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B50D455EF9; Mon, 24 Jul 2006 11:36:09 +0200 (CEST) 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 09232-08; Mon, 24 Jul 2006 11:36:07 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E12BC55E58; Mon, 24 Jul 2006 11:36:01 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 3584C7A3031; Mon, 24 Jul 2006 11:35:59 +0200 (CEST) Date: Mon, 24 Jul 2006 11:35:59 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] using notifications with SNMP/SSH Message-ID: <20060724093559.GA1450@boskop.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <016201c6aa8c$0833e580$0400a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016201c6aa8c$0833e580$0400a8c0@china.huawei.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Tue, Jul 18, 2006 at 01:03:02PM -0400, David Harrington wrote: > I need some editorial guidance from the WG and the chairs. > The consensus has been that the SSH particulars be hidden. > As a result, we have not defined (in fact I have removed) a MIB to > carry SSH-specific parameters. > The current documents just say there is SSH-specific (or > transport-specific) data stored in a Local Configuration Datastore. > > If that is all we need, then the documents may be close to done, but > there is quite a bit of hand-waving about implementation-dependent > configuration and parameter passing. I think this will make it harder > to get independent interoperable SSHSM model implementations, but I am > not implementing, so I could be wrong. > > Wes's email describes such an LCD and how it relates to the snmpTarget > tables. Does the WG want an snmpSSHParametersTable included in the > SSHSM document? Should I put this into an appendix as a sample of how > an LCD might be designed? Should this be a normative MIB module to > allow SNMP configuration of the security model (we cnosidered snmp > configurability important for the snmpv3 standard)? I think defining a > MIB module, either informative or normative, might be helpful to guide > implementors, but we risk defining a model that is harder to integrate > with some implementations of SSH and SNMP. > > By relying on an implementation-dependent opaque datastore of > transport parameters, we have been able to genericize the > session-based security model wording to be transport independent. If > we define a MIB module for SSHParameters, we may not be able to hide > the security-model elements of procedure details behind an opaque LCD. > > Should we define an snmpSSHParametersTable, and reference the managed > objects in the elements of procedure section? As far as I can tell, we first need to figure out how to ship notifications and settle on hopefully just one mechanism. As a technical contributor and implementor, I would not mind to have things spelled out in order to achieve interoperability. I assume that MIB details will be transport specific (specific for SSH or for TLS) and as such they are different from the MIB module that previously existed in the session-based security model and which was transport agnostic (correct me if I am wrong). /js -- Juergen Schoenwaelder International 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 Mon Jul 24 05:36:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4wrx-0005rt-6s; Mon, 24 Jul 2006 05:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4wrw-0005rP-3H for isms@ietf.org; Mon, 24 Jul 2006 05:36:56 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4wru-0006EC-PZ for isms@ietf.org; Mon, 24 Jul 2006 05:36:56 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5A52F55DF5; Mon, 24 Jul 2006 11:36:54 +0200 (CEST) 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 09572-02; Mon, 24 Jul 2006 11:36:52 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 0B02755D19; Mon, 24 Jul 2006 11:36:50 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 95B277A3039; Mon, 24 Jul 2006 11:36:49 +0200 (CEST) Date: Mon, 24 Jul 2006 11:36:49 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] using notifications with SNMP/SSH Message-ID: <20060724093649.GB1450@boskop.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Mon, Jul 17, 2006 at 07:03:44PM -0700, Wes Hardaker wrote: > The following is based on the message I sent out in January about > sending notifications over SNMP/SSH and the usable authentication > mechanisms. It's been edited heavily for improved readability and > usability. I can probably be coerced into further formalizing the > writing for suitable inclusion into the resulting draft assuming > the description below is sufficient for forward progress. [...] Thanks for writing this up. I think this is very helpful input. /js -- Juergen Schoenwaelder International 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 Mon Jul 24 08:46:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4zoy-0001hM-AT; Mon, 24 Jul 2006 08:46:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4zox-0001hG-5G for isms@ietf.org; Mon, 24 Jul 2006 08:46:03 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4zov-0005qr-JC for isms@ietf.org; Mon, 24 Jul 2006 08:46:03 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 916CA4C00C for ; Mon, 24 Jul 2006 14:46:00 +0200 (CEST) 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 24225-10; Mon, 24 Jul 2006 14:45:57 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id B99543A6CA; Mon, 24 Jul 2006 14:45:57 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 3141C7A3914; Mon, 24 Jul 2006 14:45:56 +0200 (CEST) Date: Mon, 24 Jul 2006 14:45:55 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060724124555.GB1657@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: Subject: [Isms] draft minutes of the montreal meeting 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 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the draft minutes for the montreal meeting. Please check the minutes for correctness and send me your feedback. I like to submit the minutes to the proceedings on Friday. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-minutes.txt" ==================================================== Minutes of the ISMS session at IETF 66 Wednesday, July 12, 2006, 1510-1610, Room 519B notes by Olivier Festor and Sharon Chisholm (jabber) edited by Juergen Schoenwaelder ==================================================== Chairs: Juergen Schoenwaelder (JS) Juergen Quittek (JQ) Content: 0. Relevant Documents 1. Session Summary 2. ISMS WG Status 3. Transprot Subsystem 4. Notifications and Session Establishment 5. Radius Integration 6. Wrap Up == 0. Relevant Documents == - Transport Mapping Security Model (TMSM) for SNMP - Secure Shell Security Model (SSHSM) for SNMP - RADIUS Usage for SNMP SSH Security Model - RADIUS NAS-Management Authorization == 1. Session Summary == The two existing WG I-Ds on a transport mapping model and on an SSH security model for SNMP still have few remaining decisions to be made. The room had consensus to introduce a transport sub-system into the TMSM document which has the effect of simplifying the terminology significantly. In particular, the TMSP becomes a transport model and the SMSP becomes a more generic session-based security model (which might map to multiple different session-based secure transports). The discussion on how to create sessions for notifications from a managed mode to a management system could still not get solved. From the management system point of view, there is a clear preference for initiating sessions in 'reverse' direction. However, the security problems implied by this approach might be too severe to use it. Finally, the WG discussed RADIUS integration of the SSH security model. There was consensus in the room to separate user authentication from authorization for establishing a session and from authorization required for access MIB elements. There seem to be different positions in the security community about whether or not 'authorization only' requests harmonize or dis-harmonize with the Kerberos architecture. == 2. ISMS WG Status == The core documents have improved significantly and only a few issues remain under discussion. Radius extension documents have been started. Volunteers are still needed for the applicability document. A short poll among the participants showed that 6 people in the room did read the transport mapping security model document, 4 people did read the secure shell document and no-one did read the radius document. == 3. Transport Subsystem == Dave Harrington (DH) explains that he likes to introduce a transport subsystem to simplify the documents. He proposes to change the SSH security model into a generic session-based security model. The SSH specific part would become an SSH transport model in the transport subsystem. He believes this change can be implemented by adding two more ASIs to the RFC 3411 architecture for the transport subsystem. See DH's slides. There was consensus in the room to follow the proposal and DH will make the required changes to the document. == 4. Notifications and Session Establishment == Juergen Schoenwaelder (JS) explains the issues involved with sending notification from a notification originator. In essence, the asymmetric nature of SSH authentication works nicely if the session has been established by a command generator (CG) or notification receiver (NR). The open question is what happens if such a session does not exist and the notification originator (NO) wants to deliver a notification. JS is basically concerned about having to configure credentials on agents. See JS's slides for the details. Robert Story (RS), Wes Hardacker (WH) and Sam Hartmans (SH) together pointed out that notification targets point to a host and associated parameters. If there are multiple sessions, the notification might be broadcasted to all suitable sessions which might be different from the model that is currently used by SNMP and clearly needs to be documented since a command generator today typically does not receive notifications. Margaret Wasserman (MW) questions whether a user is the target of a notification. She wants to send a notification to a log file under a given user's permissions. Bert Wijnen (BW) believes this is OK since one can create specific users for the notifications. WH believes this will work out, but the WG session may be the wrong place to work out the details. WH points out that an agent can use its host key to start an SNMP session but he believes this is not the identity to use for access control. A discussion of the approach which reverses roles took place. Chris Elliot (CE) says that he likes the idea. RS points out that it needs to be worked out how the notification receiver determines the user that is used to establish the SSH session. WH points out that this needs discussion with SSH experts since he expects security issues with this approach. Jeffrey Hutzelman (JH) explains that the hard issue is that SSH assumes that the SSH client knows the host it likes to talk to. This does not work in reverse since you do not know which host you are connected to nor whether you want to talk to that hosts. Some key exchange methods require to know the name of the host you like to talk to. There are additional issues with NATs where multiple agents appear as using a single IP address. SH suggests to have a conference call on this issue. == 5. Radius Integration == David Nelson (DN) goes through a list of issues (see DN's slides). There was a discussion whether separation of authentication and authorization causes issues with Kerberos. JH (chair of the Kerberos WG) says that he does not see a problem with Kerberos and authorize only. DH tries to explain the difference between authorization of a session (ssh subsystem) and authorization of access to managed objects. BW questions what the scope of the RADIUS authorization is. DH explains that the scope is security name to group name mapping within VACM since groups and the associated access control rules are typically rather static. Due to the lack of readers of the Radius document, the decision to accept the Radius document as a WG document was deferred. == 6. Wrap Up == Running out of meeting time. The notification authentication issues as well as the Radius issues will be further discussed on the mailing list. --ZGiS0Q5IWpPtfppv 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 --ZGiS0Q5IWpPtfppv-- From isms-bounces@lists.ietf.org Mon Jul 24 09:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G503s-0007mB-9s; Mon, 24 Jul 2006 09:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G503q-0007kv-GB for isms@ietf.org; Mon, 24 Jul 2006 09:01:26 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G503p-0002y5-5Y for isms@ietf.org; Mon, 24 Jul 2006 09:01:26 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9E1A34CA69; Mon, 24 Jul 2006 15:01:24 +0200 (CEST) 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 25886-03; Mon, 24 Jul 2006 15:01:22 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 06D0349716; Mon, 24 Jul 2006 15:01:22 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 5D3A17A394F; Mon, 24 Jul 2006 15:01:20 +0200 (CEST) Date: Mon, 24 Jul 2006 15:01:20 +0200 From: Juergen Schoenwaelder To: Dave Harrington Message-ID: <20060724130120.GA1928@boskop.local> Mail-Followup-To: Dave Harrington , isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org Subject: [Isms] transport subsystem and new terminology 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 Dave, if I recall your proposal correctly, you wand to introduce a transport subsystem with proper ASIs and then we would define an SSH transport model which can be used with a session-based security model. I wonder whether this change will also affect the titles of our documents: - Will the document "Transport Mapping Security Model (TMSM) Architectural Extension for the Simple Network Management Protocol (SNMP)" become "Session-based Security Model (SSM) Architectural Extension for the Simple Network Management Protocol (SNMP)" or something close to that? (Perhaps even just "Session-based Security Model for the Simple Network Management Protocol (SNMP)" would do it?) - Will the "Secure Shell Security Model for SNMP" become something like "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)"? Or more precise perhaps "Secure Shell Transport Model for the Session-based Security Model of the Simple Network Management Protocol (SNMP)"? What do you intend to do? And can you post the draft ASIs for the transport subsystem as you see them so we do not have to wait until all the edits have been done? /js -- Juergen Schoenwaelder International 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 Mon Jul 24 10:06:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G514q-0001ZI-Vm; Mon, 24 Jul 2006 10:06:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G514q-0001ZC-Bq for isms@ietf.org; Mon, 24 Jul 2006 10:06:32 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G514o-0002r8-UH for isms@ietf.org; Mon, 24 Jul 2006 10:06:32 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc15) with SMTP id <2006072414063001500q7v7me>; Mon, 24 Jul 2006 14:06:30 +0000 From: "David Harrington" To: Date: Mon, 24 Jul 2006 10:05:09 -0400 Message-ID: <040401c6af2a$2cad4d00$0400a8c0@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: <20060724093559.GA1450@boskop.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcavBJiBYqSVfvaoRqecLU/7h6lvPgAIzbRA X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org Subject: [Isms] snmpSSHParametersTable 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 > > Wes's email describes such an LCD and how it relates to the > snmpTarget > > tables. Does the WG want an snmpSSHParametersTable included in the > > SSHSM document? > > As far as I can tell, we first need to figure out how to ship > notifications and settle on hopefully just one mechanism. > >[...] I assume that > MIB details will be transport specific (specific for SSH or for TLS) > and as such they are different from the MIB module that previously > existed in the session-based security model and which was transport > agnostic (correct me if I am wrong). > I think it likely we will need to have entries in the snmptargetParamstable that reference entries in the SSHSMParamaters table (referenced by securityModel/Name/Level, where model=SSHSM tells us to use the SSHSMParameters table, and securityName/level tells us which row to use). So, we can define the MIB in the SSHSM document, in an SSH-transport-mapping specific manner. 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 Jul 24 13:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54Lw-0007cE-FW; Mon, 24 Jul 2006 13:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x7w-000293-0I for isms@ietf.org; Tue, 18 Jul 2006 17:29:12 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2x7r-00014V-Nb for isms@ietf.org; Tue, 18 Jul 2006 17:29:11 -0400 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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Tue, 18 Jul 2006 17:29:29 -0400 Message-ID: In-Reply-To: <20060715192920.GA6906@boskop.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcaoRVG02UdoqaT/Tk6lTHErEnDykgCRXPfA From: "Avi Lior" To: , "Nelson, David" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Mon, 24 Jul 2006 13:36:23 -0400 Cc: isms@ietf.org, radiusext@ops.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 > >=20 > > For the SSHSM usage case, the question is whether it is an=20 > > unacceptable security risk for a trusted NAS to be able to obtain=20 > > authorization information about a user that is not actually=20 > "present" at the NAS? >=20 > This probably needs more thought and discussion. >=20 I am having trouble understanding "..user that is not actually present" Why are we sending authorization attributes to a NAS where the user is not actually present. I have seen scenarios where we push authorization attributes to a NAS and hence that creates a Session for a user using COA for example.=20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 24 13:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54Lw-0007co-Jr; Mon, 24 Jul 2006 13:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G406Z-0001E8-Oi for isms@ietf.org; Fri, 21 Jul 2006 14:52:07 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3zzA-0006cz-1A for isms@ietf.org; Fri, 21 Jul 2006 14:44:29 -0400 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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Fri, 21 Jul 2006 14:44:52 -0400 Message-ID: In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219379@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcaoRVG02UdoqaT/Tk6lTHErEnDykgCRXPfAAAp4gIAAkCaXsA== From: "Avi Lior" To: "Nelson, David" , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Mon, 24 Jul 2006 13:36:23 -0400 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, I agree with Glen and Alan. NAS is within the trust boundary of AAA. =20 If you comprise the NAS you are done. It can leak information, modify accounting, disallow or allow services that are not authorized. > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, July 18, 2006 6:10 PM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Avi Lior writes... > =20 > > I am having trouble understanding "user that is not=20 > actually present". >=20 > In the proposed use case, the NAS could request, from a=20 > RADIUS server, authorization information for a user that it=20 > asserts is present, but is not. The RADIUS server cannot=20 > tell, since no user credentials are presented. Well behaved=20 > NASes won't do this. One might argue that all trusted NASes=20 > will be well behaved, but that makes certain threat model assumptions. >=20 > Why would a (compromised) NAS want to do this? Well, leaking=20 > authorization information on various user accounts may help=20 > an attacker select high value target accounts.=20 >=20 > The only standardized scenario for non-authenticated=20 > authorization RADIUS is call check. The assumption is that=20 > the PSTN is a reliable source of the telephone number(s), the=20 > NAS is trusted and non-compromised, and the user will=20 > typically be authenticated once the session is initiated. =20 > Thus, the risk is relatively low. >=20 > For Dynamic RADIUS, RFC 3576 requires a State attribute,=20 > which can only have come from a previous successful authentication. >=20 > In this particular ISMS use case, SNMP service is authorized=20 > based on the assertion of identity of the user by the NAS,=20 > without the RADIUS server ever having performed an=20 > authentication, and without the benefit of the resultant=20 > State attribute. Thus, the risk is potentially higher. >=20 > The questions at hand are whether the risk is high enough to=20 > be of serious concern, and whether or not it can be mitigated? >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 24 13:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54Lw-0007dP-P7; Mon, 24 Jul 2006 13:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4BR1-0004W1-Hv for isms@ietf.org; Sat, 22 Jul 2006 02:57:59 -0400 Received: from bay0-omc3-s13.bay0.hotmail.com ([65.54.246.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4BR0-0005Ws-8L for isms@ietf.org; Sat, 22 Jul 2006 02:57:59 -0400 Received: from hotmail.com ([65.54.161.27]) by bay0-omc3-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 23:57:57 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 21 Jul 2006 23:57:57 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 22 Jul 2006 06:57:53 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: isms@ietf.org, radiusext@ops.ietf.org Bcc: Date: Fri, 21 Jul 2006 23:57:53 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Jul 2006 06:57:57.0166 (UTC) FILETIME=[29829CE0:01C6AD5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Mon, 24 Jul 2006 13:36:22 -0400 Cc: Subject: [Isms] RE: Follow up on Authorize Only issue 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 security implications of unrestricted access to *any* user attributes are fairly severe. For example, should a NAS be able to retrieve the Tunnel-Password attribute of any user, regardless of whether they are connected? There are also VSAs that contain sensitive information. The Call-Check Service typically provides very little information in the Access-Accept (all that is needed is whether to accept or reject the call) so there is minimal leakage. If this is allowed, it should follow the principle of "least privilege", only providing the attributes relevant to SSH. >For the SSHSM usage case, the question is whether it is an >unacceptable security risk for a trusted NAS to be able to obtain >authorization information about a user that is not actually >"present" at the NAS? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 24 13:36:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54Lx-0007dz-0H; Mon, 24 Jul 2006 13:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4lXi-0003g5-EA for isms@ietf.org; Sun, 23 Jul 2006 17:31:18 -0400 Received: from bay0-omc1-s41.bay0.hotmail.com ([65.54.246.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4lXh-0006RB-3i for isms@ietf.org; Sun, 23 Jul 2006 17:31:18 -0400 Received: from hotmail.com ([65.54.161.40]) by bay0-omc1-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Jul 2006 14:31:16 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 23 Jul 2006 14:31:16 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 23 Jul 2006 21:31:12 GMT X-Originating-IP: [131.107.0.71] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20060722151737.B478C16E1E@mail.nitros9.org> From: "Bernard Aboba" To: aland@nitros9.org Bcc: Date: Sun, 23 Jul 2006 14:31:12 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Jul 2006 21:31:16.0157 (UTC) FILETIME=[5427DED0:01C6AE9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Mon, 24 Jul 2006 13:36:22 -0400 Cc: isms@ietf.org, radiusext@ops.ietf.org Subject: [Isms] Re: Follow up on Authorize Only issue 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 >A compromised NAS can leverage this requested feature to obtain >that information more readily. Right now, if the NAS hasn't had a >user log in through it, it can get those credentials only through a >brute force attack on the password. The server *should* be able to >catch that attack, mitigating the vulnerability. Right. > > If this is allowed, it should follow the principle of "least privilege", > > only providing the attributes relevant to SSH. > >Which means that the Access-Request has to be recognizable as for >SSH in this use-case. This means an attribute or value specifically >for this purpose. The RADIUS server can then key off of that special >request, and return a limited response. Right. For example an additional Service-Type value of "SSH" could be allocated One concern would be whether an attacker could use this Service-Type with any NAS-Port-Type, in order to retrieve attributes relevant to that NAS-Port-Type. To prevent this, one possibility is to add NAS-Port-Type values of "SSH" and "ISMS" (since different attributes might be returned for a straight SSH or SSH-protected ISMS session) and only allow Service-Type="SSH" to be used with those NAS-Port-Type values; all other NAS-Port-Type values would result in an Access-Reject. >The use case should also enumerate the possible attributes and >values needed in the Access-Accept, and state explicitely that >responding with any other attributes or values may result in security >violations. i.e. Other attributes and values SHOULD NOT be sent in >the Access-Accept. Makes sense. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 24 14:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54qN-0004Vc-2X; Mon, 24 Jul 2006 14:07:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54qL-0004VP-Sd for isms@ietf.org; Mon, 24 Jul 2006 14:07:49 -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 1G54qK-0002Cq-Ey for isms@ietf.org; Mon, 24 Jul 2006 14:07:49 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 24 Jul 2006 11:07:48 -0700 X-IronPort-AV: i="4.07,176,1151910000"; d="scan'208"; a="331049744:sNHT35308008" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6OI7lNH022884; Mon, 24 Jul 2006 11:07:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6OI7lJi025569; Mon, 24 Jul 2006 11:07:47 -0700 (PDT) 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); Mon, 24 Jul 2006 11:07:47 -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] RE: Follow up on Authorize Only issue Date: Mon, 24 Jul 2006 11:07:45 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C301FAF0A7@xmb-sjc-22d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcamoMmNnAEnI466RJyA/LWJ66zJ9QAG1JsgAZJeE4AAkMmv0A== From: "Kaushik Narayan \(kaushik\)" To: "Nelson, David" , , X-OriginalArrivalTime: 24 Jul 2006 18:07:47.0543 (UTC) FILETIME=[11AAF670:01C6AF4C] DKIM-Signature: a=rsa-sha1; q=dns; l=1867; t=1153764467; x=1154628467; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3DSWqC14FTHZTTKKP3R7O5ZhrXPcg=3D; b=irhgjOJTwHfMWnRDVRx6OR65Bnn0fk0OJUgiXW+ZzLdG3BwAlrSSmGZAZpuEJUcAv2WwKJSa lAZ0GFY58NJNj3l4srnBfbWgQifjV7528B5BnfaNAD06h3IstGlpD8sq; Authentication-Results: sj-dkim-2.cisco.com; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 All, I think the security risk is really tied to AAA use case and what constitutes authorization. As pointed out by several folks, there is definitely a significant security risk if the model of authorization involves a general purpose attribute assertion, i.e. the NAS acquiring any set of attributes tied to the session. The other end of the spectrum is to have an authorization assertion model wherein the AAA server is always responding with a permit/deny (this is the TACACS+ per-command authz model). I think the authorization assertion model will not scale for the SNMP use case so the only way to address this issue seems to be to restrict the scope (what attributes can be retrieved with Authorize-only) of the attribute assertion based on the Service-Type, I think this is what Bernard and some others had suggested.=20 regards, kaushik! =20 -----Original Message----- From: Nelson, David [mailto:dnelson@enterasys.com]=20 Sent: Friday, July 21, 2006 1:44 PM To: isms@ietf.org; radiusext@ops.ietf.org Subject: [Isms] RE: Follow up on Authorize Only issue > For the SSHSM usage case, the question is whether it is an=20 > unacceptable security risk for a trusted NAS to be able to obtain=20 > authorization information about a user that is not actually "present"=20 > at the NAS? My interpretation is that three respondents (Glen, Alan, Avi) believe that the answer is "no". The existing RADIUS trust model collapses if the NAS has been compromised and does nefarious or foolish things. I'd like to determine if we have consensus on this position. If you *have* an opinion on this issue, please *respond* whether you agree or disagree with this assertion. _______________________________________________ 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 Jul 24 14:09:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54rz-0006Uw-31; Mon, 24 Jul 2006 14:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54ry-0006Uo-4D for isms@ietf.org; Mon, 24 Jul 2006 14:09:30 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G54rw-0002Rv-RB for isms@ietf.org; Mon, 24 Jul 2006 14:09:30 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc13) with SMTP id <2006072418092701300afskne>; Mon, 24 Jul 2006 18:09:28 +0000 From: "David Harrington" To: "'Avi Lior'" , "'Nelson, David'" , , Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Mon, 24 Jul 2006 14:08:06 -0400 Message-ID: <042901c6af4c$1d6a0320$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaoRVG02UdoqaT/Tk6lTHErEnDykgCRXPfAAAp4gIAAkCaXsACVByag X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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, Let me point out that authorize only is being requested for use with SNMP. The NAS is effectively the SNMP agent, and the RADIUS interaction is to determine which data the already authenticated principal should be allowed to access. If the NAS is compromised, then the SNMP agent is compromised, and within the scope of the managed entity, you are probably already toast, with or without support from RADIUS. And if the SNMP agent is compromised, then an attacker probably doesn't much care what RADIUS has to say about accessing the SNMP MIB. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Friday, July 21, 2006 2:45 PM > To: Nelson, David; isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: Follow up on Authorize Only issue (was RE: > [Isms] ISMS session > > David, > > I agree with Glen and Alan. > > NAS is within the trust boundary of AAA. > > If you comprise the NAS you are done. It can leak information, modify > accounting, disallow or allow services that are not authorized. > > > > > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > > Sent: Tuesday, July 18, 2006 6:10 PM > > To: isms@ietf.org; radiusext@ops.ietf.org > > Subject: RE: Follow up on Authorize Only issue (was RE: > > [Isms] ISMS session > > > > Avi Lior writes... > > > > > I am having trouble understanding "user that is not > > actually present". > > > > In the proposed use case, the NAS could request, from a > > RADIUS server, authorization information for a user that it > > asserts is present, but is not. The RADIUS server cannot > > tell, since no user credentials are presented. Well behaved > > NASes won't do this. One might argue that all trusted NASes > > will be well behaved, but that makes certain threat model > assumptions. > > > > Why would a (compromised) NAS want to do this? Well, leaking > > authorization information on various user accounts may help > > an attacker select high value target accounts. > > > > The only standardized scenario for non-authenticated > > authorization RADIUS is call check. The assumption is that > > the PSTN is a reliable source of the telephone number(s), the > > NAS is trusted and non-compromised, and the user will > > typically be authenticated once the session is initiated. > > Thus, the risk is relatively low. > > > > For Dynamic RADIUS, RFC 3576 requires a State attribute, > > which can only have come from a previous successful authentication. > > > > In this particular ISMS use case, SNMP service is authorized > > based on the assertion of identity of the user by the NAS, > > without the RADIUS server ever having performed an > > authentication, and without the benefit of the resultant > > State attribute. Thus, the risk is potentially higher. > > > > The questions at hand are whether the risk is high enough to > > be of serious concern, and whether or not it can be mitigated? > > > > > > -- > > to unsubscribe send a message to > > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > > a single line as the message text body. > > archive: > > > > _______________________________________________ > 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 Jul 24 15:16:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55ud-0002nR-9C; Mon, 24 Jul 2006 15:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55ub-0002nM-UY for isms@ietf.org; Mon, 24 Jul 2006 15:16:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G55ua-0000f5-KK for isms@ietf.org; Mon, 24 Jul 2006 15:16:17 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 24 Jul 2006 12:16:16 -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.20060308/8.12.11) with ESMTP id k6OJGG7H007183; Mon, 24 Jul 2006 12:16:16 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6OJGFJi007159; Mon, 24 Jul 2006 12:16:15 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4317.cisco.com [10.61.80.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6OJ9V9A012107; Mon, 24 Jul 2006 12:09:32 -0700 Message-ID: <44C51C7D.9000809@cisco.com> Date: Mon, 24 Jul 2006 21:16:13 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: David Harrington Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session References: <042901c6af4c$1d6a0320$0400a8c0@china.huawei.com> In-Reply-To: <042901c6af4c$1d6a0320$0400a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=768; t=1153768576; x=1154632576; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session; X=v=3Dcisco.com=3B=20h=3DfQBT3+/9YNiwlNyLPF87fy/wnwk=3D; b=sGVHIDrGa8BIceJwndr8ZMNWvyn5oHO+MPJqGGnUOF42CuyEsIKPmMC0YF2C7pUMda9Of0qm 6x9x7uSmv4sCMa5wkTGmcco95W4QNWX1t0DHUUj2bS6wh+etpPivSl8R; X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: radiusext@ops.ietf.org, isms@ietf.org, 'Avi Lior' 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 Dave, > Hi, > > Let me point out that authorize only is being requested for use with > SNMP. The NAS is effectively the SNMP agent, and the RADIUS > interaction is to determine which data the already authenticated > principal should be allowed to access. > > If the NAS is compromised, then the SNMP agent is compromised, and > within the scope of the managed entity, you are probably already > toast, with or without support from RADIUS. And if the SNMP agent is > compromised, then an attacker probably doesn't much care what RADIUS > has to say about accessing the SNMP MIB. > I've lost the plot just a little here. I thought the concern was beyond the scope of the managed entity but the broader service area of the radius server. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 24 15:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G564Q-0008Ps-7H; Mon, 24 Jul 2006 15:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G564P-0008Pn-13 for isms@ietf.org; Mon, 24 Jul 2006 15:26:25 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G564N-0005Dn-Pa for isms@ietf.org; Mon, 24 Jul 2006 15:26:24 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc13) with SMTP id <2006072419262101300agpjme>; Mon, 24 Jul 2006 19:26:21 +0000 From: "David Harrington" To: "'Bernard Aboba'" , , Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Mon, 24 Jul 2006 15:24:59 -0400 Message-ID: <042a01c6af56$dae6e0d0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcavR6+Vgfz1qXx1RdOf0T5pZHoS7wAA+HBw X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Saturday, July 22, 2006 2:58 AM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: [Isms] RE: Follow up on Authorize Only issue > > The security implications of unrestricted access to *any* > user attributes > are fairly severe. > OK. If RADIUS supports this, we can probably ask for specific attributes or attribute sets. > > If this is allowed, it should follow the principle of "least > privilege", > only providing the attributes relevant to SSH. There are multiple possible proposals on the ISMS table, and we are trying to determine what RADIUS can or cannot provide for us. We are asking for an authorize-only because the current requirement of RADIUS to tie the authentication and authorization together does not fit the SNMP architecture. If we cannot get a RADIUS authorize-only, then we probably will not be able to use RADIUS for one of our purposes. What we are NOT asking for when we request "authorize-only" support: We know that RADIUS can provide SSH-related attributes when the user connects to the NAS using an SSH session and RADIUS provides the authentication. We know that the RADIUS server might be able to provide SNMP-related attributes when the user connects to the NAS using an SSH transport and RADIUS provides the authentication. We do not need "authorize-only" support for those situations, since RADIUS would be doing the authentication. It would be pretty silly to call a feature "authorize-only" if the authentication must be part of the feature. What we are asking for: The purpose of authorize-only is to make the authentication independent of the authorization. So there would be no guarantee there is any SSH involved anywhere in the system. The authentication might have been provided via Kerberos or TLS or SNMPv3's USM, but RADIUS is not involved in the authentication, only the (later) authorization. What the RADIUS server will know is that a trusted RADIUS client asserts that authentication of the principal has been performed, and the trusted RADIUS client is asking for the attributes that indicate what the principal is allowed to do. The attributes we want to see are specific to SNMP, or to Network Management via SNMP/Netconf/CLI, etc. If RADIUS supports it, the RADIUS client may be able to identify that the request is associated wih an SNMP engine, so the server can return only SNMP-related attributes. 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 Jul 24 16:01:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56co-00016B-ME; Mon, 24 Jul 2006 16:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56cn-000163-7f for isms@ietf.org; Mon, 24 Jul 2006 16:01:57 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G56cm-0008Ka-04 for isms@ietf.org; Mon, 24 Jul 2006 16:01:57 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc13) with SMTP id <2006072420015501300ac1g8e>; Mon, 24 Jul 2006 20:01:55 +0000 From: "David Harrington" To: "'Eliot Lear'" Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Mon, 24 Jul 2006 16:00:33 -0400 Message-ID: <048801c6af5b$d3012470$0400a8c0@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: <44C51C7D.9000809@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcavVaJ/o21kG28KT+62RlLcOC0YOAAAUmRQ X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: radiusext@ops.ietf.org, isms@ietf.org, 'Avi Lior' 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 Eliot, The ISMS concern is that some operators want to use authentication mechanisms other than RADIUS to authenticate the SNMP principal (which may or may not be a human user), but would like to be able to use a RADIUS server to provide information about what "SNMP-policy" (think SNMP-specific FilterID) the SNMP agent should apply regarding "which SNMP operations to what SNMP data sets" the already-authenticated "user" is permitted. And they would like to get the SNMP-policy without having to perform another authentication of the principal via the RADIUS server, since requiring that might force the operators to store the principal's authentication credentials at the SNMP agent or require the realtime intervention of a human being. The "NAS" has already done an authentication and does not want to waste resources doing yet another one. We only want this "authorize-only" service to be performed at the request of an authenticated/trusted RADIUS client. If the AAA trust for an ISMS-related client is compromised, the situation should be identical to that of any other compromised AAA client - all bets are off concerning the behavior of the RADIUS client. Who provides the hints that identify which set of attributes should be returned in a request-accept? The AAA client? If the AAA client is compromised, who provides the hints that identify which set of attributes should be returned? dbh > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Monday, July 24, 2006 3:16 PM > To: David Harrington > Cc: 'Avi Lior'; 'Nelson, David'; isms@ietf.org; radiusext@ops.ietf.org > Subject: Re: Follow up on Authorize Only issue (was RE: > [Isms] ISMS session > > Dave, > > Hi, > > > > Let me point out that authorize only is being requested for use with > > SNMP. The NAS is effectively the SNMP agent, and the RADIUS > > interaction is to determine which data the already authenticated > > principal should be allowed to access. > > > > If the NAS is compromised, then the SNMP agent is compromised, and > > within the scope of the managed entity, you are probably already > > toast, with or without support from RADIUS. And if the SNMP agent is > > compromised, then an attacker probably doesn't much care what RADIUS > > has to say about accessing the SNMP MIB. > > > > I've lost the plot just a little here. I thought the concern > was beyond > the scope of the managed entity but the broader service area of the > radius server. > > Eliot > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jul 24 17:08:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57fU-0004ma-Ex; Mon, 24 Jul 2006 17:08:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57fT-0004lg-Lr for isms@ietf.org; Mon, 24 Jul 2006 17:08:47 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G57fR-0007D9-Bx for isms@ietf.org; Mon, 24 Jul 2006 17:08:47 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc15) with SMTP id <2006072421084401500q709pe>; Mon, 24 Jul 2006 21:08:45 +0000 From: "David Harrington" To: , "'Dave Harrington'" Subject: RE: [Isms] transport subsystem and new terminology Date: Mon, 24 Jul 2006 17:07:23 -0400 Message-ID: <048901c6af65$28d0ad40$0400a8c0@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: <20060724130120.GA1928@boskop.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcavIUabp/G5PJ29R7Gal1P3pXTZYwAQdZ3Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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, I think the resulting documents would be "SSH Transport Mapping" and "Session-based Security Model". I will over the next few weeks break down what needs to be changed to effect the split. My planned split was based on assumptions that we were accepting that there no special procedures were rqeuired to support notifications. If we are changing that assumption, based on Wes's email and based on the issues you raised at IEFF66, my planned split may not be possible. I have committed my time for this coming week to work on company projects, so I will probably not have a lot of time to analyze the impact on TMSM and SSHSM of Wes's three approaches. His approaches are not described in terms of RFC3411 architectural modularity, and I would like to better understand how his stuff fits into the RFC3411 architecture, and the EOP I have in the current documents. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Monday, July 24, 2006 9:01 AM > To: Dave Harrington > Cc: isms@ietf.org > Subject: [Isms] transport subsystem and new terminology > > Dave, > > if I recall your proposal correctly, you wand to introduce a transport > subsystem with proper ASIs and then we would define an SSH transport > model which can be used with a session-based security model. I wonder > whether this change will also affect the titles of our documents: > > - Will the document "Transport Mapping Security Model (TMSM) > Architectural Extension for the Simple Network Management Protocol > (SNMP)" become "Session-based Security Model (SSM) Architectural > Extension for the Simple Network Management Protocol (SNMP)" or > something close to that? (Perhaps even just "Session-based Security > Model for the Simple Network Management Protocol (SNMP)" would do > it?) > > - Will the "Secure Shell Security Model for SNMP" become something > like "Secure Shell Transport Model for the Simple Network Management > Protocol (SNMP)"? Or more precise perhaps "Secure Shell Transport > Model for the Session-based Security Model of the Simple Network > Management Protocol (SNMP)"? > > What do you intend to do? And can you post the draft ASIs for the > transport subsystem as you see them so we do not have to wait until > all the edits have been done? > > /js > > -- > Juergen Schoenwaelder International 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 Jul 24 18:03:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G58WC-00067w-2t; Mon, 24 Jul 2006 18:03:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G58WA-00067r-Ci for isms@ietf.org; Mon, 24 Jul 2006 18:03:14 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G58W9-0005PK-2b for isms@ietf.org; Mon, 24 Jul 2006 18:03:14 -0400 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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Mon, 24 Jul 2006 18:03:35 -0400 Message-ID: In-Reply-To: <048801c6af5b$d3012470$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcavVaJ/o21kG28KT+62RlLcOC0YOAAAUmRQAAVawOA= From: "Avi Lior" To: "David Harrington" , "Eliot Lear" X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: isms@ietf.org, radiusext@ops.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, If I was specifying how this is done: It would be nice if the AAA client could return some sort of token to the AAA server to assert that the user has been authenticated by an entity that it trusts. The token can be generated by the Authentication Server. We need this assertion to make sure we deliver the correct profile. Even if we don't have this type of interaction I still think that we should support Authorize-Only for this type of transaction. Since this can be used in cases where the NAS is absolutely trusted or there are other means to secure the NAS/AAA -- eg in a closed system. > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, July 24, 2006 4:01 PM > To: 'Eliot Lear' > Cc: Avi Lior; 'Nelson, David'; isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Hi Eliot, >=20 > The ISMS concern is that some operators want to use=20 > authentication mechanisms other than RADIUS to authenticate=20 > the SNMP principal (which may or may not be a human user),=20 > but would like to be able to use a RADIUS server to provide=20 > information about what "SNMP-policy" (think SNMP-specific=20 > FilterID) the SNMP agent should apply regarding "which SNMP=20 > operations to what SNMP data sets" the already-authenticated=20 > "user" is permitted.=20 >=20 > And they would like to get the SNMP-policy without having to=20 > perform another authentication of the principal via the=20 > RADIUS server, since requiring that might force the operators=20 > to store the principal's authentication credentials at the=20 > SNMP agent or require the realtime intervention of a human=20 > being. The "NAS" has already done an authentication and does=20 > not want to waste resources doing yet another one. >=20 > We only want this "authorize-only" service to be performed at=20 > the request of an authenticated/trusted RADIUS client. If the=20 > AAA trust for an ISMS-related client is compromised, the=20 > situation should be identical to that of any other=20 > compromised AAA client - all bets are off concerning the=20 > behavior of the RADIUS client. =20 >=20 > Who provides the hints that identify which set of attributes=20 > should be returned in a request-accept? The AAA client? If=20 > the AAA client is compromised, who provides the hints that=20 > identify which set of attributes should be returned? >=20 > dbh >=20 > > -----Original Message----- > > From: Eliot Lear [mailto:lear@cisco.com] > > Sent: Monday, July 24, 2006 3:16 PM > > To: David Harrington > > Cc: 'Avi Lior'; 'Nelson, David'; isms@ietf.org; > radiusext@ops.ietf.org > > Subject: Re: Follow up on Authorize Only issue (was RE:=20 > > [Isms] ISMS session > >=20 > > Dave, > > > Hi, > > > > > > Let me point out that authorize only is being requested for use > with > > > SNMP. The NAS is effectively the SNMP agent, and the RADIUS=20 > > > interaction is to determine which data the already authenticated=20 > > > principal should be allowed to access. > > > > > > If the NAS is compromised, then the SNMP agent is=20 > compromised, and=20 > > > within the scope of the managed entity, you are probably already=20 > > > toast, with or without support from RADIUS. And if the SNMP agent > is > > > compromised, then an attacker probably doesn't much care what > RADIUS > > > has to say about accessing the SNMP MIB. > > > =20 > >=20 > > I've lost the plot just a little here. I thought the concern was=20 > > beyond the scope of the managed entity but the broader=20 > service area of=20 > > the radius server. > >=20 > > Eliot > >=20 >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 00:23:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ESM-0008Qo-Ar; Tue, 25 Jul 2006 00:23:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ESK-0008Pr-P4 for isms@ietf.org; Tue, 25 Jul 2006 00:23:40 -0400 Received: from bay0-omc2-s24.bay0.hotmail.com ([65.54.246.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ESJ-0000tL-Eg for isms@ietf.org; Tue, 25 Jul 2006 00:23:40 -0400 Received: from hotmail.com ([65.54.161.42]) by bay0-omc2-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 21:23:38 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 24 Jul 2006 21:23:38 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 25 Jul 2006 04:23:35 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <042a01c6af56$dae6e0d0$0400a8c0@china.huawei.com> From: "Bernard Aboba" To: ietfdbh@comcast.net, isms@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Mon, 24 Jul 2006 21:23:35 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Jul 2006 04:23:38.0632 (UTC) FILETIME=[1A3BB080:01C6AFA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 >OK. If RADIUS supports this, we can probably ask for specific >attributes or attribute sets. Typically this is handled by utilization of a unique Service-Type or NAS-Port-Type value. The RADIUS policy engine then selects the attribute set to be returned based on these values. >There are multiple possible proposals on the ISMS table, and we are >trying to determine what RADIUS can or cannot provide for us. > >We know that RADIUS can provide SSH-related attributes when the user >connects to the NAS using an SSH session and RADIUS provides the >authentication. As far as I know there is no specification for SSH authentication support within RADIUS so I'm not sure if this is true or not. For example, as I understand it SSH can support authentication mechanisms such as Kerberos which are not supported in RADIUS. >We know that the RADIUS server might be able to provide SNMP-related >attributes when the user connects to the NAS using an SSH transport >and RADIUS provides the authentication. In this case it sounds like the NAS-Port-Type might be "SSH" but the Service-Type might be "SNMP". >We do not need "authorize-only" support for those situations, since >RADIUS would be doing the authentication. I think this depends on whether RADIUS can support all the required authentication methods. If not, then either that support needs to be added to RADIUS or only authorization will be available. >The authentication might have been provided via Kerberos >or TLS or SNMPv3's USM, but RADIUS is not involved in the >authentication, only the (later) authorization. In this case you might have a Service-Type of "SNMP" and a NAS-Port-Type of "SNMP". >The attributes we want to see are >specific to SNMP, or to Network Management via SNMP/Netconf/CLI, etc. > >If RADIUS supports it, the RADIUS client may be able to identify that >the request is associated wih an SNMP engine, so the server can return >only SNMP-related attributes. A Service-Type of "SNMP" with a NAS-Port-Type of "SNMP" could be used to indicate this. Question: In the case where SSH is used, do you just need SSH attributes, or are SNMP attributes required there as well? In other words, how is SSH for SNMP distinguished from plain old SSH? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 09:26:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5MvQ-0004am-Nz; Tue, 25 Jul 2006 09:26:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5MvO-0004ah-Qu for isms@ietf.org; Tue, 25 Jul 2006 09:26:14 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5MvN-0000mp-GQ for isms@ietf.org; Tue, 25 Jul 2006 09:26:14 -0400 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: Tue, 25 Jul 2006 09:26:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue Thread-Index: Acaun5F+OBZSd5h4St+Z8HXTGLTFlwBTfM4g From: "Avi Lior" To: "Bernard Aboba" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: isms@ietf.org, radiusext@ops.ietf.org Subject: [Isms] RE: Follow up on Authorize Only issue 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 Well I am not exactly against using an Authorize Only in this way. I do recognize that there is a severe security issue. However, I still think designers need to be aware of the issues and design appropriately. We in the IETF need to make sure that designers are aware of the security risk of a particular feature. That is afterall what the Security section is about. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Sunday, July 23, 2006 5:31 PM > To: aland@nitros9.org > Cc: isms@ietf.org; radiusext@ops.ietf.org > Subject: Re: Follow up on Authorize Only issue >=20 > >A compromised NAS can leverage this requested feature to obtain that=20 > >information more readily. Right now, if the NAS hasn't had=20 > a user log=20 > >in through it, it can get those credentials only through a=20 > brute force=20 > >attack on the password. The server *should* be able to catch that=20 > >attack, mitigating the vulnerability. >=20 > Right. >=20 > > > If this is allowed, it should follow the principle of "least=20 > > > privilege", only providing the attributes relevant to SSH. > > > >Which means that the Access-Request has to be recognizable=20 > as for SSH=20 > >in this use-case. This means an attribute or value specifically for=20 > >this purpose. The RADIUS server can then key off of that special=20 > >request, and return a limited response. >=20 > Right. For example an additional Service-Type value of "SSH"=20 > could be allocated One concern would be whether an attacker=20 > could use this Service-Type with any NAS-Port-Type, in order=20 > to retrieve attributes relevant to that NAS-Port-Type. To=20 > prevent this, one possibility is to add NAS-Port-Type values=20 > of "SSH" and "ISMS" (since different attributes might be=20 > returned for a straight SSH or SSH-protected ISMS session)=20 > and only allow Service-Type=3D"SSH" to be used with those=20 > NAS-Port-Type values; all other NAS-Port-Type values would=20 > result in an Access-Reject. >=20 > >The use case should also enumerate the possible attributes=20 > and values=20 > >needed in the Access-Accept, and state explicitely that=20 > responding with=20 > >any other attributes or values may result in security=20 > violations. i.e.=20 > >Other attributes and values SHOULD NOT be sent in the Access-Accept. >=20 > Makes sense. >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 10:52:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OGg-00077J-HW; Tue, 25 Jul 2006 10:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OGe-00077D-Sv for isms@ietf.org; Tue, 25 Jul 2006 10:52:16 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5OGa-00069g-H3 for isms@ietf.org; Tue, 25 Jul 2006 10:52:16 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 10:52:10 -0400 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] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 10:52:09 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219388@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: Acavoie27VuWp27ORNiJlGtWCEHqwAAVG2UQ From: "Nelson, David" To: , X-OriginalArrivalTime: 25 Jul 2006 14:52:10.0048 (UTC) FILETIME=[E7FD1C00:01C6AFF9] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Bernard Aboba writes... > Typically this is handled by utilization of a unique Service-Type > or NAS-Port-Type value. The RADIUS policy engine then selects the=20 > attribute set to be returned based on these values. The values of NAS-Port-Type are (almost exclusively) related to media type: 0 Async 1 Sync 2 ISDN Sync 3 ISDN Async V.120 4 ISDN Async V.110 5 Virtual 6 PIAFS 7 HDLC Clear Channel 8 X.25 9 X.75 10 G.3 Fax 11 SDSL - Symmetric DSL 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 14 IDSL - ISDN Digital Subscriber Line 15 Ethernet 16 xDSL - Digital Subscriber Line of unknown type 17 Cable 18 Wireless - Other 19 Wireless - IEEE 802.11 20 Token-Ring =20 21 FDDI =20 22 Wireless - CDMA2000=20 23 Wireless - UMTS =20 24 Wireless - 1X-EV =20 25 IAPP =20 26 FTTP - Fiber to the Premises =20 27-29 Unassigned 30 PPPoA - PPP over ATM =20 31 PPPoEoA - PPP over Ethernet over ATM=20 32 PPPoEoE - PPP over Ethernet over Ethernet =20 33 PPPoEoVLAN - PPP over Ethernet over VLAN =20 34 PPPoEoQinQ - PPP over Ethernet over IEEE 802.1QinQ=20 While there have been proposals to over-load NAS-Port-Type with application layer protocol information, I think this is not a good idea. > As far as I know there is no specification for SSH authentication > support within RADIUS so I'm not sure if this is true or not. That is one of the issues that we have addressed in the NAS-Management draft. ( http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho rization-03.txt ) SSH implementations use RADIUS today for authentication, with or without a formal specification. What is lacking is a set of authorization attributes targeted at SSH, SNMP over SSH, and similar use cases. > For example, as I understand it SSH can support authentication=20 > mechanisms such as Kerberos which are not supported in RADIUS. SSH authentication support indeed extends beyond RADIUS. > In this case it sounds like the NAS-Port-Type might be "SSH" but the > Service-Type might be "SNMP". Uh, something like that. Actually, in the NAS-Management draft we recommend that the Service-Type attribute be "Framed-Management" and the (new) Framed-Management-Protocol attribute be "SNMPv3". I think that this is much cleaner than overloading the NAS-Port-Type. Once could argue that a generic service such as Framed-Management, with subsidiary attributes such as Framed-Management-Protocol, is "too much". One could flatten all the combinations into a set of new service types. I think that the approach in the NAS-Management draft is more in line with traditional RADIUS usages (e.g. Service-Type =3D Framed, and Framed-Protocol =3D PPP). > I think this depends on whether RADIUS can support all the required > authentication methods. If not, then either that support needs to=20 > be added to RADIUS or only authorization will be available. Right. For those deployments that are using non-RADIUS authentication today, the SSHSM usage of RADIUS will likely be for authorization only. The goal of the ISMS WG is to re-use existing AAA infrastructures. Where RADIUS is already in use, it would naturally be used for both authentication and authorization. Where it is not already in use, it may be used only for authorization. =20 > Question: In the case where SSH is used, do you just need SSH=20 > attributes, or are SNMP attributes required there as well? This is addressed in the NAS-Management draft. Provisioning of "plain" SSH, SNMPv3 over SSH, and other protocol combinations are described. So, yes, more than a single attribute (or single service provisioning description) is necessary. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 11:49:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5PA6-0003Ia-9F; Tue, 25 Jul 2006 11:49:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5PA5-0003Gy-C1 for isms@ietf.org; Tue, 25 Jul 2006 11:49:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5MOs-0003WP-BW for isms@ietf.org; Tue, 25 Jul 2006 08:52:38 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5M01-0003vR-D6 for isms@ietf.org; Tue, 25 Jul 2006 08:27:00 -0400 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 91C571BAC4D for ; Tue, 25 Jul 2006 14:11:01 +0200 (CEST) Date: Tue, 25 Jul 2006 14:26:49 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (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: -2.6 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Subject: [Isms] Conference call on notifications and call home 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, At our session in Montreal, we stopped the discussion on agent initiated channels for notifications and on what we call "call home" and agreed to continue it in a conference call. Juergen S. and I tried to find a good time for this call, but it is already summer and many people are having their vacation soon. Based on advice from our area director we chose to make this an open conference call where every WG member can participate. The time we suggest is Thursday, July 27, 10am EST (DST) I apologize for the late announcement and for potential inconveniences for participants form the west coast. We checked in advance at which time at least some of the main contributors of the discussion in Montreal would be available, and it looks like either take this date or we have to delay the discussion for at least three weeks until people return from vacations. Subject of the phone conference will be a rather technical discussion that (hopefully) brings us in a position that we can decide soon on how to deliver notifications with ISMS. The results of the discussion will be brought to the mailing list where I hoe that we can close this issue soon after the conference call. Please find a suggestion for the agenda below. The access parameters will be announced soon. We are currently looking for an operator that provides dial-in numbers in the US as well as in Europe. Thanks, Juergen Agenda for the ISMS phone conference on July 27 1. Agenda bashing 2. Call Home for SSH Main subject will be agent initiated channels for notifications. Juergen S. raised this issue in our last session. Please find his slides at The main question to be answered is: "Is the reverse creation of an SSH session as suggested in the slides an acceptable solution for ISMS notifications? 3. Alternative approaches If call home for SSH does not work, alternatives need to be discussed. Wes listed three of them in his email from July 17: . We will have as look at all three and try to identify pros and cons for each of them. 4. Summary of technical results _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 12:09:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5PTP-0002Zn-1f; Tue, 25 Jul 2006 12:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5PTO-0002Zd-3X for isms@ietf.org; Tue, 25 Jul 2006 12:09:30 -0400 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5PTM-0001MJ-TI for isms@ietf.org; Tue, 25 Jul 2006 12:09:30 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 0FF9516CBC; Tue, 25 Jul 2006 12:00:40 -0400 (EDT) From: "Alan DeKok" To: "Nelson, David" Subject: Re: [Isms] RE: Follow up on Authorize Only issue In-Reply-To: Your message of "Tue, 25 Jul 2006 10:52:09 EDT." <3CFB564E055A594B82C4FE89D2156560219388@MABOSEVS2.ets.enterasys.com> Date: Tue, 25 Jul 2006 12:00:40 -0400 Message-Id: <20060725160040.0FF9516CBC@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: isms@ietf.org, radiusext@ops.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 "Nelson, David" wrote: > Uh, something like that. Actually, in the NAS-Management draft we > recommend that the Service-Type attribute be "Framed-Management" and the > (new) Framed-Management-Protocol attribute be "SNMPv3". I think that > this is much cleaner than overloading the NAS-Port-Type. I agree. Alan DeKok. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 12:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Pu6-0006GR-JH; Tue, 25 Jul 2006 12:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Pu4-0006GM-P9 for isms@ietf.org; Tue, 25 Jul 2006 12:37:04 -0400 Received: from bay0-omc3-s32.bay0.hotmail.com ([65.54.246.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Pu3-00043a-Fb for isms@ietf.org; Tue, 25 Jul 2006 12:37:04 -0400 Received: from hotmail.com ([65.54.161.12]) by bay0-omc3-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 09:37:03 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Jul 2006 09:37:02 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 25 Jul 2006 16:36:58 GMT X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219388@MABOSEVS2.ets.enterasys.com> From: "Bernard Aboba" To: dnelson@enterasys.com, isms@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 09:36:58 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Jul 2006 16:37:02.0779 (UTC) FILETIME=[8EBFA8B0:01C6B008] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 >Actually, in the NAS-Management draft we >recommend that the Service-Type attribute be "Framed-Management" and the >(new) Framed-Management-Protocol attribute be "SNMPv3". I think that >this is much cleaner than overloading the NAS-Port-Type. This makes sense. >Right. For those deployments that are using non-RADIUS authentication >today, the SSHSM usage of RADIUS will likely be for authorization only. Does the Service-Type of "Framed-Management" imply authorization-only? Or is it possible for authentication to be requested as well? For example, what attributes are used in existing SSH implementations acting as a RADIUS client? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 14:02:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5REl-00061F-9N; Tue, 25 Jul 2006 14:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5REj-00060y-N2 for isms@ietf.org; Tue, 25 Jul 2006 14:02:29 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5REi-00009y-FK for isms@ietf.org; Tue, 25 Jul 2006 14:02:29 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PI2Kes010453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 14:02:25 -0400 (EDT) Date: Tue, 25 Jul 2006 14:02:22 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Bernard Aboba'" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: In-Reply-To: <042a01c6af56$dae6e0d0$0400a8c0@china.huawei.com> References: <042a01c6af56$dae6e0d0$0400a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01ALCsCWoYIX1M+ySKMy7ceJci4zSH5CVtJdpuNjA=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Jeffrey Hutzelman 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 On Monday, July 24, 2006 03:24:59 PM -0400 David Harrington wrote: > The purpose of authorize-only is to make the authentication > independent of the authorization. > So there would be no guarantee there is any SSH involved anywhere in > the system. The authentication might have been provided via Kerberos > or TLS or SNMPv3's USM, but RADIUS is not involved in the > authentication, only the (later) authorization. > What the RADIUS server will know is that a trusted RADIUS client > asserts that authentication of the principal has been performed, and > the trusted RADIUS client is asking for the attributes that indicate > what the principal is allowed to do. The attributes we want to see are > specific to SNMP, or to Network Management via SNMP/Netconf/CLI, etc. > If RADIUS supports it, the RADIUS client may be able to identify that > the request is associated wih an SNMP engine, so the server can return > only SNMP-related attributes. Careful here. I don't want to end up with something that's specific to SNMP, SSH, or any particular authentication mechanism. It's fine to have an approach where the RADIUS server will only provide attributes relevant to the service and/or the particular RADIUS client (NAS) in question. That decision can be made by the RADIUS server based on things like the client's identity, but it should _not_ be made based on the client's assertion of what service it's providing. What I'd like to see is a model in which the RADIUS server is told, as a matter of policy, which attributes it is allowed to provide in an authorize-only transaction, and to which RADIUS clients, and which attributes can only be reported after successful authentication of a user. The administrator can then configure this based on his deployment needs. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 14:02:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5REn-00063P-G0; Tue, 25 Jul 2006 14:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5REk-000613-SM for isms@ietf.org; Tue, 25 Jul 2006 14:02:30 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5REj-0000A1-KA for isms@ietf.org; Tue, 25 Jul 2006 14:02:30 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PI2Keq010453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 14:02:20 -0400 (EDT) Date: Tue, 25 Jul 2006 14:02:20 -0400 From: Jeffrey Hutzelman To: Avi Lior , David Harrington , Eliot Lear Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Message-ID: <22912E892FFAB46B75388ED5@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01zQ+Dgzd3+PcZWvsEAI2z8mSBuq5UQ/w6hLHoA48=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Jeffrey Hutzelman , isms@ietf.org, radiusext@ops.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 On Monday, July 24, 2006 06:03:35 PM -0400 Avi Lior wrote: > It would be nice if the AAA client could return some sort of token to > the AAA server to assert that the user has been authenticated by an > entity that it trusts. The token can be generated by the Authentication > Server. Most authentication mechanisms don't have any such token, or even any such thing as an "Authentication Server". There is no central entitiy that knows every time a Kerberos client proves its identity for a server. Nor is there such a thing for SSH publickey, or USM, or TLS. And even if there were, I wouldn't want this to be a requirement. Authentication and authorization are separate concepts, and many people want to (and do!) handle them independently. The selection of mechanisms for these should, to the maximum extent possible, be orthogonal. A service providing authorization, as we are asking RADIUS to do, should not care what authentication mechanism was used, and certainly should not require that protocol elements be defined for each authentication mechanism. > We need this assertion to make sure we deliver the correct profile. No, you don't. The correct profile is the one requested by the NAS. What you mean to say is "we need this assertion to make sure we don't deliver the correct profile to a bad guy", but I don't agree with that. Just don't give the bad guys access to the RADIUS server (that is, don't give them keys with which to authenticate to the RADIUS server). If you're concerned that a NAS might be compromised or be malicious for some other reason, then restrict that NAS to retrieving only information relevant to itself. Bear in mind that it is the NAS, not the RADIUS server, which is providing service here, so if the NAS has been compromised then you've already lost. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 14:12:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ROR-0001ZI-Vx; Tue, 25 Jul 2006 14:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ROR-0001YT-E4 for isms@ietf.org; Tue, 25 Jul 2006 14:12:31 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ROM-0001OC-57 for isms@ietf.org; Tue, 25 Jul 2006 14:12:31 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:12:24 -0400 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] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:12:23 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021938D@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQ From: "Nelson, David" To: , X-OriginalArrivalTime: 25 Jul 2006 18:12:24.0120 (UTC) FILETIME=[E0EF0380:01C6B015] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Bernard Aboba writes... > Does the Service-Type of "Framed-Management" imply=20 > authorization-only? No. It could equally be used when RADIUS is providing both authentication and authorization. > Or is it possible for authentication to be requested=20 > as well? Yes. > For example, what attributes are used in existing SSH=20 > implementations acting as a RADIUS client? I rather suspect that existing implementations either ignore the Service-Type (i.e. authenticate only) or expect something like NAS-Prompt. There is an issue to be worked out, and that it how does the NAS signal to the RADIUS Server that it is seeking Authorize Only service specifically for SSHSM? The existing Authorize only usage in RFC 3576 suggests that: The NAS then sends an Access-Request to the RADIUS server with a Service-Type Attribute with value "Authorize Only". This Access-Request SHOULD contain the NAS attributes from the Disconnect or CoA-Request, as well as the session attributes from the Request legal for inclusion in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. So it seems clear that the Access-Request message, in the SSHSM Authorize Only usage, should contain; Service-Type =3D Authorize Only Message-Authenticator Plus various forms of ID attributes, such as NAS-IP-Address, NAS-Identifier, etc. But what else? It would be typical to include: Service-Type =3D Framed-Management Framed-Management-Protocol =3D SNMPv3 as hints, however, the value of Service-Type conflicts. Perhaps simply including:=20 Framed-Management-Protocol =3D SNMPv3 is a sufficient hint to the RADIUS Server, along with Service-Type =3D Authorize Only, to indicate the SSHSM Authorize Only use case. I would fully expect that the Access-Accept message would contain: Service-Type =3D Framed-Management Framed-Management-Protocol =3D SNMPv3 Message-Authenticator Plus what ever else might be desired. There was also a suggestion on the list that the NAS convey the asserted identity to the RADIUS Server for audit purposes. This could be accomplished by a (new) Asserted-Identity attribute. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 14:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ReJ-0001gn-F8; Tue, 25 Jul 2006 14:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ReH-0001gi-Ib for isms@ietf.org; Tue, 25 Jul 2006 14:28:53 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ReG-0005kF-A4 for isms@ietf.org; Tue, 25 Jul 2006 14:28:53 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PISo4m011183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 14:28:50 -0400 (EDT) Date: Tue, 25 Jul 2006 14:28:50 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: <0CF74BB4F7E245A508397708@sirius.fac.cs.cmu.edu> In-Reply-To: <3CFB564E055A594B82C4FE89D215656021938D@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D215656021938D@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01huhOcvBQw+bSM8bzuWZ+4R1ahZ0NHMfzXXzXvGg=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Jeffrey Hutzelman 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 On Tuesday, July 25, 2006 02:12:23 PM -0400 "Nelson, David" wrote: > The existing Authorize only usage in RFC 3576 suggests that: > > The NAS then sends an Access-Request > to the RADIUS server with a Service-Type Attribute with value > "Authorize Only". This Access-Request SHOULD contain the NAS > attributes from the Disconnect or CoA-Request, as well as the session > attributes from the Request legal for inclusion in an Access-Request > as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As > noted in [RFC2869] Section 5.19, a Message-Authenticator attribute > SHOULD be included in an Access-Request that does not contain a > User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. Overloading Service-Type in this way was almost certainly a mistake; as you note, it prevents the attribute for being used for its intended purpose, which is to indicate something orthogonal to whether you want authentication or authorize-only. I think this is up to radext to fix; possibilities I can think of are defining an "authorize-only" authentication mechanism, or defininig a new attribute which carries the value that Service-Type would have had. I must not, BTW, that if you are trying to restrict what information the RADIUS server gives out because you don't trust the NAS, then giving out informaton based on what service the NAS claims it is providing, or what port type the NAS claims the user came in on, is kind of silly. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 14:34:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rk1-00049V-Ju; Tue, 25 Jul 2006 14:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rk0-00049M-1V for isms@ietf.org; Tue, 25 Jul 2006 14:34:48 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Rjy-0007Ad-NV for isms@ietf.org; Tue, 25 Jul 2006 14:34:48 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060725183445b1300fspj1e>; Tue, 25 Jul 2006 18:34:46 +0000 From: "David Harrington" To: "'Nelson, David'" , , Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:33:23 -0400 Message-ID: <051201c6b018$d0373320$0400a8c0@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: <3CFB564E055A594B82C4FE89D215656021938D@MABOSEVS2.ets.enterasys.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQAADcQ4A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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, Per the discussion at the ISMS interim meeting, there is an architectural issue here. The authorize-only functionality is meant to be used by the SNMP (data) Access Control subsystem, not by the message security subsystem or the transport mapping. SSHSM is a combination of transport mapping and message security model, but it is not a model in the SNMP (data) access control subsystem. You use SSHSM when you want SSH to provide the user authentication. Ergo, I believe SSHSM should never use the "authorize-only" feature. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Tuesday, July 25, 2006 2:12 PM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: [Isms] RE: Follow up on Authorize Only issue > > Bernard Aboba writes... > > > Does the Service-Type of "Framed-Management" imply > > authorization-only? > > No. It could equally be used when RADIUS is providing both > authentication and authorization. > > > Or is it possible for authentication to be requested > > as well? > > Yes. > > > For example, what attributes are used in existing SSH > > implementations acting as a RADIUS client? > > I rather suspect that existing implementations either ignore the > Service-Type (i.e. authenticate only) or expect something like > NAS-Prompt. > > There is an issue to be worked out, and that it how does the > NAS signal > to the RADIUS Server that it is seeking Authorize Only service > specifically for SSHSM? > > The existing Authorize only usage in RFC 3576 suggests that: > > The NAS then sends an Access-Request > to the RADIUS server with a Service-Type Attribute with value > "Authorize Only". This Access-Request SHOULD contain the NAS > attributes from the Disconnect or CoA-Request, as well as > the session > attributes from the Request legal for inclusion in an > Access-Request > as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As > noted in [RFC2869] Section 5.19, a Message-Authenticator attribute > SHOULD be included in an Access-Request that does not contain a > User-Password, CHAP-Password, ARAP-Password or EAP-Message > Attribute. > > > So it seems clear that the Access-Request message, in the SSHSM > Authorize Only usage, should contain; > > Service-Type = Authorize Only > Message-Authenticator > > Plus various forms of ID attributes, such as NAS-IP-Address, > NAS-Identifier, etc. > > But what else? > > It would be typical to include: > > Service-Type = Framed-Management > Framed-Management-Protocol = SNMPv3 > > as hints, however, the value of Service-Type conflicts. > > Perhaps simply including: > > Framed-Management-Protocol = SNMPv3 > > is a sufficient hint to the RADIUS Server, along with Service-Type = > Authorize Only, to indicate the SSHSM Authorize Only use case. > > I would fully expect that the Access-Accept message would contain: > > Service-Type = Framed-Management > Framed-Management-Protocol = SNMPv3 > Message-Authenticator > > Plus what ever else might be desired. > > There was also a suggestion on the list that the NAS convey > the asserted > identity to the RADIUS Server for audit purposes. This could be > accomplished by a (new) Asserted-Identity attribute. > > > _______________________________________________ > 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 Jul 25 14:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RnJ-0005lR-0S; Tue, 25 Jul 2006 14:38:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RnH-0005lM-1Y for isms@ietf.org; Tue, 25 Jul 2006 14:38:11 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RnB-0007cs-OO for isms@ietf.org; Tue, 25 Jul 2006 14:38:11 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:38:04 -0400 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] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:38:03 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021938E@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawGC5Cd0U7Vo4FQ1iCsDPCDN/k2gAACYzQ From: "Nelson, David" To: , X-OriginalArrivalTime: 25 Jul 2006 18:38:04.0153 (UTC) FILETIME=[76DD6690:01C6B019] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Jeffrey Hutzelman writes... > Overloading Service-Type in this way was almost certainly a=20 > mistake; ... Perhaps. > ...as you note, it prevents the attribute for being used for=20 > its intended purpose, ... In this case, providing a service hint. > I think this is up to radext to fix; possibilities I can think of are > defining an "authorize-only" authentication mechanism, or defininig a new > attribute which carries the value that Service-Type would have had. One suggestion that comes to mind is to create a new attribute called Asserted-Identity, which could be empty. In RADIUS, the authentication method is implicitly selected by the inclusion of the corresponding credential-bearing attribute(s), such as User-Password, CHAP-Password, EAP-Message, etc. Asserted-Identity could be the attribute which selects the Authorize Only authentication method.=20 > I must note, BTW, that if you are trying to restrict what information the > RADIUS server gives out because you don't trust the NAS, then giving out > informaton based on what service the NAS claims it is providing, or what > port type the NAS claims the user came in on, is kind of silly. Right. But providing hints in the Access-Request message is still necessary for the RADIUS server to make an informed policy decision as to which service to provision, from among those allowed for the user, and to put the corresponding attributes in the Access-Accept message. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 14:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RxZ-0001jX-UK; Tue, 25 Jul 2006 14:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RxY-0001eX-5V for isms@ietf.org; Tue, 25 Jul 2006 14:48:48 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RxS-0001uq-RZ for isms@ietf.org; Tue, 25 Jul 2006 14:48:48 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:48:41 -0400 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] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:48:41 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021938F@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQAADcQ4AAAJfPAA== From: "Nelson, David" To: , X-OriginalArrivalTime: 25 Jul 2006 18:48:41.0849 (UTC) FILETIME=[F2F61690:01C6B01A] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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... > Ergo, I believe SSHSM should never use the "authorize-only"=20 > feature. I'm more that a little fuzzy on the architecture, the ASIs, etc., so please bear with me. I agree that the Access Control Subsystem will be the ultimate consumer of the "fine granularity" authorization, such as that provided by Management-Policy-ID, or a similar attribute. It is my understanding, and please correct me if I miss some details, that the Transport Mapping Subsystem (e.g. the SSN server) has the responsibility of enforcing "coarse granularity" authorization, i.e. whether a SNMP subsystem may be spawned by the SSH server. It also has the responsibility to pass along the securityName to the Access Control Subsystem. Given that any additional authorization information that comes during an integrated RADIUS authentication and authorization also needs to be passed along with the securityName, that implies some participation by the Transport Mapping Subsystem. In the case where RADIUS is only used for authorization, it could be argued that it is the responsibility of the Access Control subsystem to obtain that information. I suppose the interface would be implementation dependent. This needs to be described somewhere. If not in the RADIUS Usage for SSHSM document, then where? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 14:53:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5S1d-0003TG-Rl; Tue, 25 Jul 2006 14:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5S1d-0003TB-AF for isms@ietf.org; Tue, 25 Jul 2006 14:53:01 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5S1c-000323-2B for isms@ietf.org; Tue, 25 Jul 2006 14:53:01 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PIqvR2012125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 14:52:57 -0400 (EDT) Date: Tue, 25 Jul 2006 14:52:57 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Nelson, David'" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: <4DE3C46E118151E5B2A7A902@sirius.fac.cs.cmu.edu> In-Reply-To: <051201c6b018$d0373320$0400a8c0@china.huawei.com> References: <051201c6b018$d0373320$0400a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01eR6QaeOGBd3FaQjqrJzA2BCQx5QAUgnmk77Or54=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Jeffrey Hutzelman 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 On Tuesday, July 25, 2006 02:33:23 PM -0400 David Harrington wrote: > Hi David, > > Per the discussion at the ISMS interim meeting, there is an > architectural issue here. > > The authorize-only functionality is meant to be used by the SNMP > (data) Access Control subsystem, not by the message security subsystem > or the transport mapping. SSHSM is a combination of transport mapping > and message security model, but it is not a model in the SNMP (data) > access control subsystem. > > You use SSHSM when you want SSH to provide the user authentication. > > Ergo, I believe SSHSM should never use the "authorize-only" feature. I'm not entirely sure that's true. First, it's reasonable for SSH itself to use this feature. Some ssh userauth mechanisms need to be able to determine from the client's authenticated identity whether it is allowed to use a particular SSH username, and this would be an appropriate use of RADIUS. Of course, it's also reasonable for the SSH server to use RADIUS to decide whether a particular SSH username is allowed to use a particular service or command, including SNMP. For the record, these uses of RADIUS by SSH are not things I think we need to or should specify in ISMS, but they are appropriate uses of authorize-only. Second, you might want to use RADIUS to determine how to map an SSH username to an SNMP username. It's not clear to me that we nailed down how this is supposed to happen, but it clearly needs to happen in the transport model, since no higher layers are SSH-specific. If the mapping is other than the identity or some simple transformation, it might be desirable to use RADIUS for this. If so, this is definitely a use for authorize-only, since the TM is not directly involved in authentication. Of course, the real motivator here is as you described -- to allow the access-control subsystem to get information it needs to make fine-grained access control decisions. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 14:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5S5T-0005cb-If; Tue, 25 Jul 2006 14:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5S5S-0005cT-Hb for isms@ietf.org; Tue, 25 Jul 2006 14:56:58 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5S5O-0004Ie-9T for isms@ietf.org; Tue, 25 Jul 2006 14:56:58 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PIuqcR012337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 14:56:52 -0400 (EDT) Date: Tue, 25 Jul 2006 14:56:52 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: In-Reply-To: <3CFB564E055A594B82C4FE89D215656021938E@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D215656021938E@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01PrKTHagaCJGK/QuecTDDjNUkykjF5gyrJ8GCdDI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Jeffrey Hutzelman 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 On Tuesday, July 25, 2006 02:38:03 PM -0400 "Nelson, David" wrote: > One suggestion that comes to mind is to create a new attribute called > Asserted-Identity, which could be empty. In RADIUS, the authentication > method is implicitly selected by the inclusion of the corresponding > credential-bearing attribute(s), such as User-Password, CHAP-Password, > EAP-Message, etc. Asserted-Identity could be the attribute which > selects the Authorize Only authentication method. Yes; I was thinking of something along those lines. Of course, you'd want to require a MAC on any request with that attribute. > Right. But providing hints in the Access-Request message is still > necessary for the RADIUS server to make an informed policy decision as > to which service to provision, from among those allowed for the user, > and to put the corresponding attributes in the Access-Accept message. Oh, yes, absolutely. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 15:04:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SD2-0008Mp-Mi; Tue, 25 Jul 2006 15:04:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SD1-0008Kh-JT for isms@ietf.org; Tue, 25 Jul 2006 15:04:47 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5SCz-0007Vc-BA for isms@ietf.org; Tue, 25 Jul 2006 15:04:47 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PJ4hZ5012611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 15:04:43 -0400 (EDT) Date: Tue, 25 Jul 2006 15:04:43 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: <38E89459B1B8D4812FCAD13D@sirius.fac.cs.cmu.edu> In-Reply-To: <3CFB564E055A594B82C4FE89D215656021938F@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D215656021938F@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01wVt6ECvD74QNpvKR9Nmqf1jNsTtIj/Mu0Kh199s=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Jeffrey Hutzelman 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 On Tuesday, July 25, 2006 02:48:41 PM -0400 "Nelson, David" wrote: > It is my understanding, and please correct me if I miss some details, > that the Transport Mapping Subsystem (e.g. the SSN server) has the > responsibility of enforcing "coarse granularity" authorization, i.e. > whether a SNMP subsystem may be spawned by the SSH server. It also has > the responsibility to pass along the securityName to the Access Control > Subsystem. Given that any additional authorization information that > comes during an integrated RADIUS authentication and authorization also > needs to be passed along with the securityName, that implies some > participation by the Transport Mapping Subsystem. SNMP provides no interface by which that information can be conveyed between subsystems. At one time, we thought the SSH transport mapping and security model would be tightly bound, with the transport mapping passing SSH-specific information to the security model via a new interface (an opaque blob whose meaning was known only to the TM and corresponding SM), and the real work being done in the SSHSM. Now, I believe we've moved to a model where there is a generic "transport" security model which does basically no work, and all the work is done in the TM. In either case, all the access model sees is the security name/type/level, and there is no way to provide more specific information. In fact, it would be something of an abstraction violation to provide transport or security model-specific information to the ACM. IMHO it would be even worse to expect those models to obtain information which is actually RADIUS-specific but _not_ specific to the TM or SM, and pass _that_ to the ACM. After all, RADIUS might _not_ be in use, and some other authorization mechanism might be. Now, it's entirely possible that an SSH+SNMP implementation could pass RADIUS attributes up to the ACM "behind the back" of the abstract model. However, that would be an optimization, not something described by the specification. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 15:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SJk-0004cF-7q; Tue, 25 Jul 2006 15:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SJi-0004c8-R3 for isms@ietf.org; Tue, 25 Jul 2006 15:11:42 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5SJh-0001TE-C6 for isms@ietf.org; Tue, 25 Jul 2006 15:11:42 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 4D2E31E1495; Tue, 25 Jul 2006 12:11:38 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Jul 2006 12:11:38 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE88@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Juergen Quittek' , isms@ietf.org Subject: RE: [Isms] Thursday 27 July - Conference call on notifications an d call home Date: Tue, 25 Jul 2006 12:11:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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, Retitled with date to highlight the short notice. At some time I'm unable to determine from the ambiguous "Thursday, July 27, 10am EST (DST)" below - perhaps "EDT" (Eastern Daylight Savings Time)? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > Sent: Tuesday, July 25, 2006 8:27 AM > To: isms@ietf.org > Subject: [Isms] Conference call on notifications and call home > > > Dear all, > > At our session in Montreal, we stopped the discussion on > agent initiated channels for notifications and on what we > call "call home" and agreed to continue it in a conference > call. > > Juergen S. and I tried to find a good time for this call, > but it is already summer and many people are having their > vacation soon. > > Based on advice from our area director we chose to make this > an open conference call where every WG member can participate. > > The time we suggest is > > Thursday, July 27, 10am EST (DST) > > I apologize for the late announcement and for potential > inconveniences for participants form the west coast. > We checked in advance at which time at least some of the > main contributors of the discussion in Montreal would be > available, and it looks like either take this date or we > have to delay the discussion for at least three weeks until > people return from vacations. > > > Subject of the phone conference will be a rather technical > discussion that (hopefully) brings us in a position that we > can decide soon on how to deliver notifications with ISMS. > The results of the discussion will be brought to the mailing > list where I hoe that we can close this issue soon after > the conference call. > > Please find a suggestion for the agenda below. > > The access parameters will be announced soon. We are currently > looking for an operator that provides dial-in numbers in the US > as well as in Europe. > > Thanks, > > Juergen > > Agenda for the ISMS phone conference on July 27 > > 1. Agenda bashing > > 2. Call Home for SSH > > Main subject will be agent initiated channels for notifications. > Juergen S. raised this issue in our last session. Please find his > slides at > > > > The main question to be answered is: "Is the reverse creation of > an SSH session as suggested in the slides an acceptable solution > for ISMS notifications? > > 3. Alternative approaches > > If call home for SSH does not work, alternatives need to be > discussed. Wes listed three of them in his email from July 17: > > > . > > We will have as look at all three and try to identify pros and cons > for each of them. > > 4. Summary of technical results > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/396 - Release Date: 7/24/2006 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 15:33:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SfC-0006oV-Vz; Tue, 25 Jul 2006 15:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SfC-0006o1-3H for isms@ietf.org; Tue, 25 Jul 2006 15:33:54 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5SfA-00026A-Sc for isms@ietf.org; Tue, 25 Jul 2006 15:33:54 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PJXnU5013539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 15:33:51 -0400 (EDT) Date: Tue, 25 Jul 2006 15:33:49 -0400 From: Jeffrey Hutzelman To: "McDonald, Ira" , "'Juergen Quittek'" , isms@ietf.org Subject: RE: [Isms] Thursday 27 July - Conference call on notifications an d call home Message-ID: <893B11E596FF5FD398DCA8A2@sirius.fac.cs.cmu.edu> In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EE88@mailsrvnt05.enet.sharplabs.com> References: <789E617C880666438EDEE30C2A3E8D10EE88@mailsrvnt05.enet.sharplabs .com> Originator-Info: login-token=Mulberry:01tc84rh83rSIBGrAv6E1oHUxBb9k8A7EiRGYT608=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Jeffrey Hutzelman 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 On Tuesday, July 25, 2006 12:11:34 PM -0700 "McDonald, Ira" wrote: > Hi, > > Retitled with date to highlight the short notice. > > At some time I'm unable to determine from the ambiguous > "Thursday, July 27, 10am EST (DST)" below - perhaps > "EDT" (Eastern Daylight Savings Time)? Yeah; for the benefit of our friends in Europe, "EST" stands for "Eastern Standard Time", and refers specifically to the offset (UTC-5) used when daylight savings is _not_ in effect. To be clear, the proposed meeting time is UTC 1400. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 15:46:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Srg-00051z-LS; Tue, 25 Jul 2006 15:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Srf-0004wq-7r for isms@ietf.org; Tue, 25 Jul 2006 15:46:47 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Src-00061T-Sh for isms@ietf.org; Tue, 25 Jul 2006 15:46:47 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 25 Jul 2006 12:46:45 -0700 X-IronPort-AV: i="4.07,180,1151910000"; d="scan'208"; a="1841701054:sNHT25918604" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PJkiP5029927; Tue, 25 Jul 2006 12:46:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6PJki79001773; Tue, 25 Jul 2006 12:46:44 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 12:46:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Tue, 25 Jul 2006 12:46:42 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597D07@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcavVaJ/o21kG28KT+62RlLcOC0YOAAAUmRQAAVawOAALYSREA== From: "Glen Zorn \(gwz\)" To: "Avi Lior" , "David Harrington" , "Eliot Lear" X-OriginalArrivalTime: 25 Jul 2006 19:46:43.0817 (UTC) FILETIME=[0E603D90:01C6B023] DKIM-Signature: a=rsa-sha1; q=dns; l=913; t=1153856804; x=1154720804; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session; X=v=3Dcisco.com=3B=20h=3DEvtPMlNbcxEdOSYlFBdUnxJo5Vs=3D; b=fxUoPuQCxPbQfmVGBRMUcKpa0f7wjQWdK7ZwlIKuX1p9o4BpbEX3Ymm6sXjxiCxiMvPIu/os Nrhe4Eh54ttiSl1q/Jbl8aZ9CuUFHToSgUvD0xP5eQEHceayZ5/QTxy/; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org, radiusext@ops.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 Avi Lior supposedly scribbled: > Hi, >=20 > If I was specifying how this is done: >=20 > It would be nice if the AAA client could return some sort of token to > the AAA server to assert that the user has been authenticated by an > entity that it trusts. The token can be generated by the > Authentication Server. =20 >=20 > We need this assertion to make sure we deliver the correct profile. I disagree: the fact that the message is being sent by an authenticated = client at all says that the user has been authenticated elsewhere. Note = that safety requires the inclusion of a MAC (either the = Message-Authenticator or preferably the Message-Authentication-Code = Attribute) in the Access-Request. =20 Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 15:59:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5T3r-0008Up-6Y; Tue, 25 Jul 2006 15:59:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5T3p-0008Uf-Iv for isms@ietf.org; Tue, 25 Jul 2006 15:59:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5T3o-0001un-8V for isms@ietf.org; Tue, 25 Jul 2006 15:59:21 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2006 12:59:18 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PJxIhW012199; Tue, 25 Jul 2006 12:59:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6PJxI2D008804; Tue, 25 Jul 2006 12:59:18 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Jul 2006 12:59:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 12:59:16 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597D1C@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQAAQzacA= From: "Glen Zorn \(gwz\)" To: "Nelson, David" , , X-OriginalArrivalTime: 25 Jul 2006 19:59:18.0024 (UTC) FILETIME=[CFEB1880:01C6B024] DKIM-Signature: a=rsa-sha1; q=dns; l=477; t=1153857558; x=1154721558; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=CIauXJd4fFcXH8B3npHRsp06F8M+laJNTK6McTkf+ylSU1UIIGIqoys30QlRwjFhAiMQ/Z1I 2SReONVKEQrT3IIkJ0IxjMO5lnJNyzEPEIjDyw/dRWnDHHhnv7oOZPqF; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Nelson, David supposedly scribbled: ... >=20 > There was also a suggestion on the list that the NAS convey the > asserted identity to the RADIUS Server for audit purposes. This > could be accomplished by a (new) Asserted-Identity attribute. =20 How would this be different than the User-Name attribute? ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 16:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TF8-0004lG-JU; Tue, 25 Jul 2006 16:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TF7-0004lA-69 for isms@ietf.org; Tue, 25 Jul 2006 16:11:01 -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 1G5TF5-0004iC-RW for isms@ietf.org; Tue, 25 Jul 2006 16:11:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2006 13:10:59 -0700 X-IronPort-AV: i="4.07,180,1151910000"; d="scan'208"; a="436330971:sNHT26250572" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PKAwCo016730; Tue, 25 Jul 2006 13:10:58 -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 k6PKAwJi007941; Tue, 25 Jul 2006 13:10:58 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 13:10:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 13:10:57 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597D2A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawGC5Cd0U7Vo4FQ1iCsDPCDN/k2gAACYzQAAM/vAA= From: "Glen Zorn \(gwz\)" To: "Nelson, David" , , X-OriginalArrivalTime: 25 Jul 2006 20:10:58.0442 (UTC) FILETIME=[716666A0:01C6B026] DKIM-Signature: a=rsa-sha1; q=dns; l=1951; t=1153858258; x=1154722258; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=p1tNetYLfGSERllqFxrWtRYOeE4+UDQy2Gz+uHxcBEMhGsn4JqPVDM3SCDsXIZLs1b5Cxv1i 4DAl+Fa/P1peGzILzF3SW3f+p5Th5yDRkP5vACOwksuJEmidjSW+NeN/; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Nelson, David supposedly scribbled: > Jeffrey Hutzelman writes... >=20 >> Overloading Service-Type in this way was almost certainly a mistake; >> ... >=20 > Perhaps. >=20 >> ...as you note, it prevents the attribute for being used for its >> intended purpose, ... >=20 > In this case, providing a service hint. >=20 >> I think this is up to radext to fix; possibilities I can think of are >> defining an "authorize-only" authentication mechanism, or defininig >> a new attribute which carries the value that Service-Type would have >> had.=20 >=20 > One suggestion that comes to mind is to create a new attribute called > Asserted-Identity, which could be empty. In RADIUS, the > authentication method is implicitly selected by the inclusion of the > corresponding credential-bearing attribute(s), such as User-Password, > CHAP-Password, EAP-Message, etc. Asserted-Identity could be the > attribute which selects the Authorize Only authentication method. =20 Aside from the fact that "Authorize Only" is hardly an authentication = method, it seems a bit silly to define a new attribute to indicate that = other attributes are missing. The absence of User-Password, etc. would = seem to be enough to implicitly select authorize-only... =20 >=20 >> I must note, BTW, that if you are trying to restrict what >> information the RADIUS server gives out because you don't trust the >> NAS, then giving out informaton based on what service the NAS claims >> it is providing, or what port type the NAS claims the user came in >> on, is kind of silly. What's actually silly is talking about untrusted NASen at all: if a = RADIUS client that has a valid shared secret has been compromised, life = is pretty much over anyway. ... Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 16:33:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tak-0002lS-Tf; Tue, 25 Jul 2006 16:33:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tak-0002lK-B0 for isms@ietf.org; Tue, 25 Jul 2006 16:33:22 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tae-0000Ij-2E for isms@ietf.org; Tue, 25 Jul 2006 16:33:22 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 16:33:14 -0400 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] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 16:33:14 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219390@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawGC5Cd0U7Vo4FQ1iCsDPCDN/k2gAACYzQAAM/vAAAAHrdoA== From: "Nelson, David" To: , X-OriginalArrivalTime: 25 Jul 2006 20:33:14.0601 (UTC) FILETIME=[8DD01590:01C6B029] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com 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 Glen Zorn writes... > Aside from the fact that "Authorize Only" is hardly an authentication > method, ... It's been described as the "null" authentication method, purely from a conceptual viewpoint. > ... it seems a bit silly to define a new attribute to indicate that > other attributes are missing. The absence of User-Password, etc. would > seem to be enough to implicitly select authorize-only... Well, the new attribute need not be empty. I could contain an identity string, for auditing purposes. I think that the use of User-Name to contain the auditing information (as you posited in a separate post) is problematic. I also think that omitting the User-Name as the only way to signal Authorize Only is also problematic. The problems I see are with existing RADIUS server implementations. Since the _presence_ of a particular kind of credential-bearing attribute has always selected the authentication method, I'm concerned about the backwards compatibility aspects of simply omitting any such. Perhaps others have thoughts on this?=20 I believe that the presence of User-Name already has a well defined semantics. I am concerned that the omission of User-Name may have muddled semantics, given RFC 3576 implementations. In RFC 3576 the Service-Type of Authorize Only in an Access-Request provides that signal. We wish to use a Service-Type of Framed-Management (or some such) in the ISMS use case, so we need another attribute to signal Authorize Only. > What's actually silly is talking about untrusted NASen at all: if a RADIUS > client that has a valid shared secret has been compromised, life is pretty > much over anyway. I think we have rough consensus on that point. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 16:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tfo-00062H-MU; Tue, 25 Jul 2006 16:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tfn-00061I-Ri for isms@ietf.org; Tue, 25 Jul 2006 16:38:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tfn-0000v6-Pp for isms@ietf.org; Tue, 25 Jul 2006 16:38:35 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5TfO-0006Ft-HI for isms@ietf.org; Tue, 25 Jul 2006 16:38:13 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PKc0xR015943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 16:38:05 -0400 (EDT) Date: Tue, 25 Jul 2006 16:38:00 -0400 From: Jeffrey Hutzelman To: "Glen Zorn (gwz)" , "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262502597D2A@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB262502597D2A@xmb-sjc-215.amer.cisco .com> Originator-Info: login-token=Mulberry:01PMUmD6Ytm4OIEJ6Qb0NWftM3XTrD+Z+pOlR0ckU=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.6 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Jeffrey Hutzelman 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 On Tuesday, July 25, 2006 01:10:57 PM -0700 "Glen Zorn (gwz)" wrote: > Aside from the fact that "Authorize Only" is hardly an authentication > method It's not an authentication method, but it fills that role in the protocol. Ordinarily, the RADIUS server must have some means of verifying the user's identity, because the NAS is counting on it to do that. The authentication method is simply the answer to the question "what is that means?". What we're doing is defining a new possible answer, which is "there is none; the NAS is not counting on you to verify the user's identity, so you don't have to do it". Now, you've suggested that the way to represent that answer is simply by not including the attributes required for some other method. The problem with that is that such a request is indistinguishable to the RADIUS server from a request using an authentication method it does not understand. A RADIUS server which supports authorize-only will probably want to return success for the request using that feature, but still must return failure for requests using methods it doesn't understand. To make the distinction, you need an affirmative indication from the client that it wants authorize-only; that is, that it is not depending on the RADIUS server to verify the user's identity. >>> I must note, BTW, that if you are trying to restrict what >>> information the RADIUS server gives out because you don't trust the >>> NAS, then giving out informaton based on what service the NAS claims >>> it is providing, or what port type the NAS claims the user came in >>> on, is kind of silly. > > What's actually silly is talking about untrusted NASen at all: if a > RADIUS client that has a valid shared secret has been compromised, life > is pretty much over anyway. Not necessarily. With the kinds of authentication mechanisms which make authorize-only RADIUS attractive, a NAS never gains the ability to impersonate a user. So, the service that NAS is providing probably has big problems, but the users' passwords haven't been compromised, and neither have other RADIUS clients. The compromised device can be turned off, and the problem is gone. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 16:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tr7-0006E5-Ir; Tue, 25 Jul 2006 16:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tr6-0006Dz-MH for isms@ietf.org; Tue, 25 Jul 2006 16:50:16 -0400 Received: from bay0-omc3-s31.bay0.hotmail.com ([65.54.246.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tr4-0003A6-Cr for isms@ietf.org; Tue, 25 Jul 2006 16:50:16 -0400 Received: from hotmail.com ([65.54.161.34]) by bay0-omc3-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 13:50:13 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Jul 2006 13:50:13 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 25 Jul 2006 20:50:10 GMT X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262502597D2A@xmb-sjc-215.amer.cisco.com> From: "Bernard Aboba" To: isms@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 13:50:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Jul 2006 20:50:13.0339 (UTC) FILETIME=[ED072AB0:01C6B02B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 >What's actually silly is talking about untrusted NASen at all: if a RADIUS >client that has a valid >shared secret has been compromised, life is pretty >much over anyway. There is still the 'cascading vulnerabilty' problem. That is, compromise of a single NAS should not imply compromise of other services, NASes or users. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 16:51:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TsK-0000Dg-MN; Tue, 25 Jul 2006 16:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TsJ-0000DS-H6 for isms@ietf.org; Tue, 25 Jul 2006 16:51:31 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5TsI-0003Es-Am for isms@ietf.org; Tue, 25 Jul 2006 16:51:31 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PKpSN0016335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 16:51:28 -0400 (EDT) Date: Tue, 25 Jul 2006 16:51:28 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: <16B00D1FBAE7AE4AEF924540@sirius.fac.cs.cmu.edu> In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219390@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D2156560219390@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01RWhdYq/Q0taRs9XjeOaN0dzalI3MnNay3YvHe+g=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Jeffrey Hutzelman 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 On Tuesday, July 25, 2006 04:33:14 PM -0400 "Nelson, David" wrote: > I think that the use of User-Name to contain the auditing information I'm sorry; what auditing information? RADIUS already has a mechanism for providing auditing data. If the RADIUS server wishes to log the NAS's request, it's welcome to do so, but what information is relevant to that that's not a necessary part of the request? -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 17:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5U0m-0002ib-RE; Tue, 25 Jul 2006 17:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5U0l-0002iW-5x for isms@ietf.org; Tue, 25 Jul 2006 17:00:15 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5U0f-0003pu-UW for isms@ietf.org; Tue, 25 Jul 2006 17:00:15 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 17:00:09 -0400 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] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 17:00:08 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219391@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawLBuXrLWYKJWrQ52hW7eVCGZAcQAACy5Q From: "Nelson, David" To: , X-OriginalArrivalTime: 25 Jul 2006 21:00:09.0294 (UTC) FILETIME=[503EAEE0:01C6B02D] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Jeff Hutzelman writes... > If the RADIUS server wishes to log the NAS's request, it's welcome to do > so, but what information is relevant to that that's not a necessary part > of the request? I think I've added some unintentional confusion. Indeed, the "user name" is necessary in the access request so that the server can perform the profile lookup. Someone had suggested on the list that additional information _might_ be provided as an outcome of authentication that could be additionally passed along for auditing purposes. I think the example was given of a Kerberos ticket. Now I don't know if that makes any sense, and the suggestion wasn't accompanied by a detailed use case. So, maybe the auditing suggestion is a red herring. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 17:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5U4i-0001Rp-BV; Tue, 25 Jul 2006 17:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5U4h-0001R1-Ly for isms@ietf.org; Tue, 25 Jul 2006 17:04:19 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5U4f-0004Mu-CN for isms@ietf.org; Tue, 25 Jul 2006 17:04:19 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060725210416b1100nv7j4e>; Tue, 25 Jul 2006 21:04:16 +0000 From: "David Harrington" To: "'Nelson, David'" , , Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 17:02:54 -0400 Message-ID: <059701c6b02d$b30f5060$0400a8c0@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: <3CFB564E055A594B82C4FE89D215656021938F@MABOSEVS2.ets.enterasys.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQAADcQ4AAAJfPAAADsW/w X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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, You're fuzzy on the SNMPv3 architecure? How can that be? It is soooo SIMPLE! ;-) comments inline. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > > In the case where RADIUS is only used for authorization, it could be > argued that it is the responsibility of the Access Control > subsystem to > obtain that information. I suppose the interface would be > implementation dependent. > > This needs to be described somewhere. If not in the RADIUS Usage for > SSHSM document, then where? It should be described in a separate document, so we do not cause other people to also be fuzzy on the architectural separation. Please note the following from the charter. The working group will cover the following work items: - Specify an architectural extension that describes how to perform a mapping from AAA-provisioned user-authentication and authorization parameter(s)to securityName and other corresponding SNMP parameters. - Specify a mapping from RADIUS-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. This item may be a RADEXT work item last-aclled in both groups. And note this from the charter: Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. -- The RADIUS/SSHSM document should be describing how to use RADIUS to authenticate a "user" and to authorize the estabishment for that user of an snmp subsystem in SSH. The document needs to describe how to map from AAA-provisioned information (or from the SSH information derived from the AAA information) to securityName, securityModel, securityLevel, and other SNMP parameters that are required for establishing the SSH snmp subsystem. The SNMP securityname is deliberately human-friendly, so it can be used for purposes such as logging. The default mapping for the SNMP securityName parameter is to take it from the authenticated SSH USER_NAME, but as Jeff mentioned, AAA might have an attribute to provision a different securityName; this might be useful if the authenticated SSH "user" is some human-unfriendly thing. But "provisioning SNMP parameters" explicitly does not include mapping to the access control subsytem; that is a separate issue that is out of scope for the WG, and should be dealt with in a separate document when such a document is included in a subsequent ISMS charter. One task at a time. Please ask the chairs for their advice if this is fuzzy. Dbh > > > _______________________________________________ > 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 Jul 25 17:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UCQ-0005JE-8r; Tue, 25 Jul 2006 17:12:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UCO-0005J9-QG for isms@ietf.org; Tue, 25 Jul 2006 17:12:16 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5UCJ-0005dV-Id for isms@ietf.org; Tue, 25 Jul 2006 17:12:16 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 17:12:11 -0400 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] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 17:12:10 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219392@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQAADcQ4AAAJfPAAADsW/wAAF4ZB A= From: "Nelson, David" To: , X-OriginalArrivalTime: 25 Jul 2006 21:12:11.0256 (UTC) FILETIME=[FE915780:01C6B02E] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Dave Harrington writes... > But "provisioning SNMP parameters" explicitly does not include mapping > to the access control subsytem; ... I don't read that in the charter. You apparently read it between the lines. Defining a new Access Control Subsystem or making changes to VACM is explicitly out of scope. > ...that is a separate issue that is out of scope for the WG, > and should be dealt with in a separate document when such a > document is included in a subsequent ISMS charter. We've had this discussion many months ago. My opinion hasn't changed. I think that providing a way for RADIUS to provision group membership information that can be used to map into any Access Control Subsystem ought to be part of the work. Especially if it does not actually affect the architectural model, and is accomplished in an implementation dependent fashion. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 17:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UGl-00016z-Om; Tue, 25 Jul 2006 17:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UGk-00016X-72 for isms@ietf.org; Tue, 25 Jul 2006 17:16:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5UGh-0006HD-H1 for isms@ietf.org; Tue, 25 Jul 2006 17:16:46 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2006 14:16:42 -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.20060308/8.12.11) with ESMTP id k6PLGgYL027116; Tue, 25 Jul 2006 14:16:42 -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 k6PLGgiD018780; Tue, 25 Jul 2006 14:16:42 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:16:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:16:41 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597D9F@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawGC5Cd0U7Vo4FQ1iCsDPCDN/k2gAACYzQAAM/vAAAAHrdoAAB3X8Q From: "Glen Zorn \(gwz\)" To: "Nelson, David" X-OriginalArrivalTime: 25 Jul 2006 21:16:42.0294 (UTC) FILETIME=[A01E7560:01C6B02F] DKIM-Signature: a=rsa-sha1; q=dns; l=2176; t=1153862202; x=1154726202; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=aGQy48QN+hyclNVLIOSxwp5MIueCM0JLTx/G7ct6NzyouWM+Poo74tCyZa7DfLp8lz6ykn7g B2eXrqKRQs46J4UCbykRdS463g3SLONX/IIAtwGkXeO+MhL2vX1OmniT; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: isms@ietf.org, radiusext@ops.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 Nelson, David supposedly scribbled: > Glen Zorn writes... >=20 >> Aside from the fact that "Authorize Only" is hardly an authentication >> method, ... >=20 > It's been described as the "null" authentication method, purely from > a conceptual viewpoint.=20 >=20 >> ... it seems a bit silly to define a new attribute to indicate that >> other attributes are missing. The absence of User-Password, etc. >> would seem to be enough to implicitly select authorize-only... >=20 > Well, the new attribute need not be empty. I could contain an > identity string, for auditing purposes.=20 >=20 > I think that the use of User-Name to contain the auditing information > (as you posited in a separate post) is problematic. =20 Not sure I really understand this. > I also think > that omitting the User-Name as the only way to signal Authorize Only > is also problematic. =20 If User-Name is omitted, how do you know who is being authorized? > The problems I see are with existing RADIUS > server implementations. Since the _presence_ of a particular kind of > credential-bearing attribute has always selected the authentication > method, I'm concerned about the backwards compatibility aspects of > simply omitting any such. Perhaps others have thoughts on this?=20 Don't quite understand this either: if a server doesn't recognize the = postulated Asserted-Identity Attribute, it seems that as far as it is = concerned there will be no credential-bearing attribute in the message. = So just omitting any credential-bearing attribute (along with the = addition of the other stuff we've been talking about) should get just = the same response from a legacy server, right? =20 ... >=20 >> What's actually silly is talking about untrusted NASen at all: if a >> RADIUS client that has a valid shared secret has been compromised, >> life is pretty much over anyway. >=20 > I think we have rough consensus on that point. That's gratifying to hear! Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 17:20:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UKj-0002wX-Jc; Tue, 25 Jul 2006 17:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UKi-0002qE-AD for isms@ietf.org; Tue, 25 Jul 2006 17:20:52 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5UKg-0006oK-Uq for isms@ietf.org; Tue, 25 Jul 2006 17:20:52 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 25 Jul 2006 14:20:50 -0700 X-IronPort-AV: i="4.07,180,1151910000"; d="scan'208"; a="1841724792:sNHT26258276" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PLKosV007154; Tue, 25 Jul 2006 14:20:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6PLKo79007640; Tue, 25 Jul 2006 14:20:50 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:20: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:20:49 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597DA4@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawKjxGE7hbmDSbTJiMrvL6nM9eFQABZXKg From: "Glen Zorn \(gwz\)" To: "Jeffrey Hutzelman" , "Nelson, David" , , X-OriginalArrivalTime: 25 Jul 2006 21:20:49.0953 (UTC) FILETIME=[33BC3910:01C6B030] DKIM-Signature: a=rsa-sha1; q=dns; l=2842; t=1153862450; x=1154726450; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=RVnPzzFl5J/oodGIc/kOZ/eYv2Y+Iy1FZW+ZxXYIe4wvUvrdGKjmu0qxTKhICGYnltcczAY/ Ssc41MlAgn9f4VJbylDEnioKlX4Ipj5EmRbN6qEMHZrjZ5K0OI3d0sI8; Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Jeffrey Hutzelman supposedly scribbled: > On Tuesday, July 25, 2006 01:10:57 PM -0700 "Glen Zorn (gwz)" > wrote: >=20 >> Aside from the fact that "Authorize Only" is hardly an authentication >> method >=20 > It's not an authentication method, but it fills that role in the > protocol.=20 > Ordinarily, the RADIUS server must have some means of verifying the > user's identity, because the NAS is counting on it to do that. The > authentication method is simply the answer to the question "what is > that means?". What we're doing is defining a new possible answer, > which is "there is none; the NAS is not counting on you to verify the > user's identity, so you don't have to do it". =20 >=20 > Now, you've suggested that the way to represent that answer is simply > by not including the attributes required for some other method. The > problem with that is that such a request is indistinguishable to the > RADIUS server from a request using an authentication method it does > not understand. =20 Actually, no, at least in current usage an authentication type _always_ = has an associated attribute, which can be seen as something that the = server doesn't understand. > A RADIUS server which supports authorize-only will > probably want to return success for the request using that feature, > but still must return failure for requests using methods it doesn't > understand. To make the distinction, you need an affirmative > indication from the client that it wants authorize-only;=20 Is that not provided by the Service-Type of Authorize-Only? > that is, > that it is not depending on the RADIUS server to verify the user's > identity. =20 >=20 >=20 >>>> I must note, BTW, that if you are trying to restrict what >>>> information the RADIUS server gives out because you don't trust the >>>> NAS, then giving out informaton based on what service the NAS >>>> claims it is providing, or what port type the NAS claims the user >>>> came in on, is kind of silly. >>=20 >> What's actually silly is talking about untrusted NASen at all: if a >> RADIUS client that has a valid shared secret has been compromised, >> life is pretty much over anyway. >=20 > Not necessarily. With the kinds of authentication mechanisms which > make authorize-only RADIUS attractive, a NAS never gains the ability > to impersonate a user. So, the service that NAS is providing > probably has big problems, but the users' passwords haven't been > compromised, and neither have other RADIUS clients. The compromised > device can be turned off, and the problem is gone. =20 >=20 >=20 > -- Jeff Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 17:39:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Ucx-0006bJ-Fz; Tue, 25 Jul 2006 17:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Ucw-0006bD-TJ for isms@ietf.org; Tue, 25 Jul 2006 17:39:42 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Ucv-00089e-Kd for isms@ietf.org; Tue, 25 Jul 2006 17:39:42 -0400 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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Tue, 25 Jul 2006 17:40:00 -0400 Message-ID: In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262502597D07@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcavVaJ/o21kG28KT+62RlLcOC0YOAAAUmRQAAVawOAALYSREAAEBHdg From: "Avi Lior" To: "Glen Zorn \(gwz\)" , "David Harrington" , "Eliot Lear" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: isms@ietf.org, radiusext@ops.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 I proably did not make myself clear....or maybe I did and I am missing something. When the NAS sends the Access-Request Auth-Only message I agree that it MUST contain Message-Authenticator(80) etc... What I meant is that it would be nice if there was a token or an assertion that came from the place that did authenticate the user to indicate in a cryptographic way that this user was authenticated. The AAA server can use that token to verify that the user was authenticated by an entity that it trusts. Like a kerberose ticket. > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Sent: Tuesday, July 25, 2006 3:47 PM > To: Avi Lior; David Harrington; Eliot Lear > Cc: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Avi Lior supposedly scribbled: >=20 > > Hi, > >=20 > > If I was specifying how this is done: > >=20 > > It would be nice if the AAA client could return some sort=20 > of token to=20 > > the AAA server to assert that the user has been authenticated by an=20 > > entity that it trusts. The token can be generated by the > > Authentication Server. =20 > >=20 > > We need this assertion to make sure we deliver the correct profile. >=20 > I disagree: the fact that the message is being sent by an=20 > authenticated client at all says that the user has been=20 > authenticated elsewhere. Note that safety requires the=20 > inclusion of a MAC (either the Message-Authenticator or=20 > preferably the Message-Authentication-Code Attribute) in the=20 > Access-Request. =20 >=20 > Hope this helps, >=20 > ~gwz >=20 > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 18:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5V1g-00060E-DB; Tue, 25 Jul 2006 18:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5V1f-000604-Qf for isms@ietf.org; Tue, 25 Jul 2006 18:05:15 -0400 Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5V1e-0003xE-Jf for isms@ietf.org; Tue, 25 Jul 2006 18:05:15 -0400 Received: from h-68-166-38-156.snvacaid.dynamic.covad.net ([68.166.38.156] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1G5V1d-00071e-00 for isms@ietf.org; Tue, 25 Jul 2006 18:05:13 -0400 Message-ID: <008c01c6b036$9ecb8b60$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <3CFB564E055A594B82C4FE89D215656021938F@MABOSEVS2.ets.enterasys.com> Subject: Re: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 15:06:45 -0700 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.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 - > From: "Nelson, David" > To: ; > Sent: Tuesday, July 25, 2006 11:48 AM > Subject: RE: [Isms] RE: Follow up on Authorize Only issue ... > It is my understanding, and please correct me if I miss some details, > that the Transport Mapping Subsystem (e.g. the SSN server) has the > responsibility of enforcing "coarse granularity" authorization, i.e. > whether a SNMP subsystem may be spawned by the SSH server. ... This may be a nit, or it may be a fundamental disconnect. If we have SSH servers literally spawning SNMP subsystems, something is very very wrong. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 18:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5V2w-0006Yh-OV; Tue, 25 Jul 2006 18:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5V2v-0006Yc-8v for isms@ietf.org; Tue, 25 Jul 2006 18:06:33 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5V2s-0004Fr-V6 for isms@ietf.org; Tue, 25 Jul 2006 18:06:33 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060725220630b1300igsv0e>; Tue, 25 Jul 2006 22:06:30 +0000 From: "David Harrington" To: "'Nelson, David'" , , Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 18:05:07 -0400 Message-ID: <05a501c6b036$647464f0$0400a8c0@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: <3CFB564E055A594B82C4FE89D2156560219392@MABOSEVS2.ets.enterasys.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcawLwKWmK0/Pj9vSTW9PiPku4oKeAABCrRQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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, I was asked by the chairs at IETF66 to help unravel the confusion that surrounds the RADIUS work in ISMS. The charter is rather ambiguous about what consistutes SNMP parameters, but the charter seems to be crystal clear that mapping to the access control subsystem is out of scope: "Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group." I believe the confusion is being caused by your insistence that mapping to the access control subsystem ought to be part of the RADIUS/SSHSM work, AND you are fuzzy on the separation of authentication and authorization in the SNMP architecture. I absolutely agree that RADIUS provisioning of access control should be part of the ISMS work. But it is a distinct work that is independent of the RADIUS/SSHSM integration work, which should be about the authentication and authorization necessary to establish the SSH snmp subsystem. Trying to define one monolithic solution, rather than following the modular SNMP architecture approach, is causing lots of unnecessary confusion. The chairs came to the conclusion that the work of mapping to the access control subsystem was out of scope, per the charter. But the scope decision is for them to make clear, not me. That is the reason I included the following sentence in my email: "Please ask the chairs for their advice if this is fuzzy." David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Tuesday, July 25, 2006 5:12 PM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: [Isms] RE: Follow up on Authorize Only issue > > Dave Harrington writes... > > > But "provisioning SNMP parameters" explicitly does not > include mapping > > to the access control subsytem; ... > > I don't read that in the charter. You apparently read it between the > lines. Defining a new Access Control Subsystem or making changes to > VACM is explicitly out of scope. > > > ...that is a separate issue that is out of scope for the WG, > > and should be dealt with in a separate document when such a > > document is included in a subsequent ISMS charter. > > We've had this discussion many months ago. My opinion hasn't changed. > I think that providing a way for RADIUS to provision group membership > information that can be used to map into any Access Control Subsystem > ought to be part of the work. Especially if it does not > actually affect > the architectural model, and is accomplished in an implementation > dependent fashion. > > > _______________________________________________ > 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 Jul 25 18:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5V3T-0007bf-6b; Tue, 25 Jul 2006 18:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5V3R-0007bZ-SW for isms@ietf.org; Tue, 25 Jul 2006 18:07:05 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5V3Q-0004M7-Lb for isms@ietf.org; Tue, 25 Jul 2006 18:07:05 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PM70bD018324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 18:07:00 -0400 (EDT) Date: Tue, 25 Jul 2006 18:07:00 -0400 From: Jeffrey Hutzelman To: "Glen Zorn (gwz)" , "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: <24498AC6095EA03D49A9BEF9@sirius.fac.cs.cmu.edu> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262502597DA4@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB262502597DA4@xmb-sjc-215.amer.cisco .com> Originator-Info: login-token=Mulberry:01QS1sHKuV4ZCNeOSddKuci9ifo0fIYeWuopqBd60=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Jeffrey Hutzelman 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 On Tuesday, July 25, 2006 02:20:49 PM -0700 "Glen Zorn (gwz)" wrote: > Actually, no, at least in current usage an authentication type _always_ > has an associated attribute, which can be seen as something that the > server doesn't understand. Is there a requirement that a server reject a request which contains any attributes it doesn't understand? >> A RADIUS server which supports authorize-only will >> probably want to return success for the request using that feature, >> but still must return failure for requests using methods it doesn't >> understand. To make the distinction, you need an affirmative >> indication from the client that it wants authorize-only; > > Is that not provided by the Service-Type of Authorize-Only? Not if you want to use Service-Type to actually indicate the service type, instead of overloading it to mean something else. As I understand it, this attribute is _supposed_ to indicate the type of service the NAS is providing to the user, and overloading it to mean something else was a mistake. If this attribute is used for its intended purpose, to allow the RADIUS server to know what service to provision, then it cannot also be used to indicate authorize-only mode. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 18:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5V95-00087Y-TQ; Tue, 25 Jul 2006 18:12:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5V95-00087T-KS for isms@ietf.org; Tue, 25 Jul 2006 18:12:55 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5V94-0005Xy-DJ for isms@ietf.org; Tue, 25 Jul 2006 18:12:55 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PMCr4D018412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 18:12:53 -0400 (EDT) Date: Tue, 25 Jul 2006 18:12:53 -0400 From: Jeffrey Hutzelman To: Randy Presuhn , isms@ietf.org Subject: Re: [Isms] RE: Follow up on Authorize Only issue Message-ID: <79C035A4E47235B9F1F2E12B@sirius.fac.cs.cmu.edu> In-Reply-To: <008c01c6b036$9ecb8b60$6501a8c0@oemcomputer> References: <3CFB564E055A594B82C4FE89D215656021938F@MABOSEVS2.ets.enterasys.c om> <008c01c6b036$9ecb8b60$6501a8c0@oemcomputer> Originator-Info: login-token=Mulberry:01ik2Lh/S1APvWmAMIvcu79iG/wrIRgQT3wrnswM0=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Jeffrey Hutzelman 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 On Tuesday, July 25, 2006 03:06:45 PM -0700 Randy Presuhn wrote: > Hi - > >> From: "Nelson, David" >> To: ; >> Sent: Tuesday, July 25, 2006 11:48 AM >> Subject: RE: [Isms] RE: Follow up on Authorize Only issue > ... >> It is my understanding, and please correct me if I miss some details, >> that the Transport Mapping Subsystem (e.g. the SSN server) has the >> responsibility of enforcing "coarse granularity" authorization, i.e. >> whether a SNMP subsystem may be spawned by the SSH server. > ... > > This may be a nit, or it may be a fundamental disconnect. > If we have SSH servers literally spawning SNMP subsystems, > something is very very wrong. David is using "subsystem" in the SSH sense, to refer to a service provided over an SSH channel instead of a shell, via a particular protocol mechanism. Some implementations implement subsystems as separate programs which are spawned by the SSH server, but of course there is nothing that requires this. In practice, I suspect what we'll be seeing a lot of is SSH servers establishing links to a long-lived SNMP subsystem, through some implementation-dependent local communication channel. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 18:42:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Vc9-0004br-TB; Tue, 25 Jul 2006 18:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Vc8-0004bm-50 for isms@ietf.org; Tue, 25 Jul 2006 18:42:56 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Vc6-0006u3-Sw for isms@ietf.org; Tue, 25 Jul 2006 18:42:56 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PMgmeP019014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 18:42:49 -0400 (EDT) Date: Tue, 25 Jul 2006 18:42:48 -0400 From: Jeffrey Hutzelman To: Avi Lior , "Glen Zorn (gwz)" , David Harrington , Eliot Lear Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Message-ID: <273FD32409B4BC58A366218D@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01j1F9bfm58uHbnPXuws+t3CbDtJgWhfb8xqvSxdE=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Jeffrey Hutzelman , isms@ietf.org, radiusext@ops.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 On Tuesday, July 25, 2006 05:40:00 PM -0400 Avi Lior wrote: > I proably did not make myself clear....or maybe I did and I am missing > something. > > When the NAS sends the Access-Request Auth-Only message I agree that it > MUST contain Message-Authenticator(80) etc... > > What I meant is that it would be nice if there was a token or an > assertion that came from the place that did authenticate the user to > indicate in a cryptographic way that this user was authenticated. > > The AAA server can use that token to verify that the user was > authenticated by an entity that it trusts. Like a kerberose ticket. First, the user was authenticated by the NAS. That is all the RADIUS server needs to know. The RADIUS server provides service to the NAS, not the user, and the NAS has asked for information about what the user is allowed to do. Either the RADIUS server is willing to give that information to the NAS or it is not, but it is the NAS that is making the request, not the user. RADIUS servers provide authentication as a _service_ to the NAS, not as a means of determining whether the NAS is legitimate or should be given information. A NAS that is not interested in that service should not be required to use it in order to make use of the other services that the RADIUS server can provide, such as provisioning and accounting. Once again, the RADIUS server's relationship is with the NAS, not the user. Secondly, as I already said, the sort of token you describe simply does not exist for most authentication mechanisms. A Kerberos ticket is not cryptographic proof that a user has authenticated. It is an encrypted message from the Kerberos server to a particular service, and is useless to anyone else. And, it's not a message saying "this user authenticated". It's a message telling the service the keys it needs to know in order to conduct an exchange with a user and determine whether that user is real. Thirdly, as I've also said before, this is a serious abstraction violation. Even if every service had such a magic cookie, what you're suggesting would require defining what it is, for RADIUS, for every authentication mechanism that might be used by a NAS using authorize-only. What magic token are you going to use for TLS? What about USM? GSS-spkm? SSH public key? one-time passwords? SSH host-based public key? NTLM? IPsec? How about the Frobozz protocol I referred to in an earlier message? You don't even know how that works, so you'd basically guarantee that when I get a NAS that supports the Frobozz protocol, I can't use it until I define an extension to the RADIUS protocol and upgrade my server. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 19:13:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5W5u-0000Ef-C9; Tue, 25 Jul 2006 19:13:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5W5s-0000EX-Sx for isms@ietf.org; Tue, 25 Jul 2006 19:13:40 -0400 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5W5q-0004QS-IF for isms@ietf.org; Tue, 25 Jul 2006 19:13:40 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc12) with SMTP id <20060725231337b1200q5cfhe>; Tue, 25 Jul 2006 23:13:38 +0000 From: "David Harrington" To: Subject: RE: [Isms] using notifications with SNMP/SSH Date: Tue, 25 Jul 2006 19:12:15 -0400 Message-ID: <05ad01c6b03f$c4fc38d0$0400a8c0@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: <20060724093559.GA1450@boskop.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcavBJiBYqSVfvaoRqecLU/7h6lvPgAJWOcg X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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, Without having gone through the elements of procedure (EOP) in both the TMSM and SSHSM documents, using each of the three approaches described by Wes, I cannot say for sure we can still accomplish the separation of transport mapping from security model. I think there are two different concerns here. First is how to identify the target system and have a notification generator open a session. I think the EOP in the TMSM and SSHSM documents may be able to do this just fine already with no changes. Currently the documents say the information about the target system is taken from the LCD, withuot specifying what the LCD actually contains (and saying it is implementation-dependent). Adding an snmpSSHParamsTable will simply spell this out more clearly, and show how the correct entry in the LCD is identified using the existing snmpTargetParamsTable et al. The second issue is how to apply data access control appropriately, when authentication has two different principals (the server and the client). Wes says the NG must send notifications as a "notification responder". There is currently no such thing as a notification responder, only a generator or reciever.I do not know if this was a typo and he meant to say "receiver" rather than responder. Maybe he is proposing a new "snmnp application" to supplement the NG and NR applications. I think doing so might create bindings between the application and transport mapping, i.e. the application would need to know what transport sessions existed. I fear this would violate the modularity of the architecture. If Wes meant receiver rather than responder, then I have different concerns. I think a notification generator needs to send notifications as a notification generator, otherwise we will need to change how the EOP of RFC3413 work. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Monday, July 24, 2006 5:36 AM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] using notifications with SNMP/SSH > > On Tue, Jul 18, 2006 at 01:03:02PM -0400, David Harrington wrote: > > > I need some editorial guidance from the WG and the chairs. > > The consensus has been that the SSH particulars be hidden. > > As a result, we have not defined (in fact I have removed) a MIB to > > carry SSH-specific parameters. > > The current documents just say there is SSH-specific (or > > transport-specific) data stored in a Local Configuration Datastore. > > > > If that is all we need, then the documents may be close to done, but > > there is quite a bit of hand-waving about implementation-dependent > > configuration and parameter passing. I think this will make > it harder > > to get independent interoperable SSHSM model > implementations, but I am > > not implementing, so I could be wrong. > > > > Wes's email describes such an LCD and how it relates to the > snmpTarget > > tables. Does the WG want an snmpSSHParametersTable included in the > > SSHSM document? Should I put this into an appendix as a > sample of how > > an LCD might be designed? Should this be a normative MIB module to > > allow SNMP configuration of the security model (we cnosidered snmp > > configurability important for the snmpv3 standard)? I think > defining a > > MIB module, either informative or normative, might be > helpful to guide > > implementors, but we risk defining a model that is harder > to integrate > > with some implementations of SSH and SNMP. > > > > By relying on an implementation-dependent opaque datastore of > > transport parameters, we have been able to genericize the > > session-based security model wording to be transport independent. If > > we define a MIB module for SSHParameters, we may not be able to hide > > the security-model elements of procedure details behind an > opaque LCD. > > > > Should we define an snmpSSHParametersTable, and reference > the managed > > objects in the elements of procedure section? > > As far as I can tell, we first need to figure out how to ship > notifications and settle on hopefully just one mechanism. > > As a technical contributor and implementor, I would not mind to have > things spelled out in order to achieve interoperability. I assume that > MIB details will be transport specific (specific for SSH or for TLS) > and as such they are different from the MIB module that previously > existed in the session-based security model and which was transport > agnostic (correct me if I am wrong). > > /js > > -- > Juergen Schoenwaelder International 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 Tue Jul 25 19:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Wij-0000zO-AX; Tue, 25 Jul 2006 19:53:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Wih-0000zH-Bm for isms@ietf.org; Tue, 25 Jul 2006 19:53:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5VXH-0004yT-Ek for isms@ietf.org; Tue, 25 Jul 2006 18:37:55 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5VHu-0007wQ-H5 for isms@ietf.org; Tue, 25 Jul 2006 18:22:05 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6PMLnFD018560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 18:21:57 -0400 (EDT) Date: Tue, 25 Jul 2006 18:21:49 -0400 From: Jeffrey Hutzelman To: "Glen Zorn (gwz)" , "Nelson, David" Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: <24114725636DDF87620A473F@sirius.fac.cs.cmu.edu> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262502597D9F@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB262502597D9F@xmb-sjc-215.amer.cisco .com> Originator-Info: login-token=Mulberry:0105xXRz0EzLsf58/IBhqHtmoOjnJa0NBAEYWsCRw=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.6 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Jeffrey Hutzelman , isms@ietf.org, radiusext@ops.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 On Tuesday, July 25, 2006 02:16:41 PM -0700 "Glen Zorn (gwz)" wrote: > Don't quite understand this either: if a server doesn't recognize the > postulated Asserted-Identity Attribute, it seems that as far as it is > concerned there will be no credential-bearing attribute in the message. > So just omitting any credential-bearing attribute (along with the > addition of the other stuff we've been talking about) should get just the > same response from a legacy server, right? >From a _legacy_ server, yes. The concern is about how this would affect handling of some new authentication method invented in the future. Suppose there is a new method that requires a "Frobozz" attribute, and we have a client that sends a request using that method. A server which supports "Frobozz" will respond correctly, as will a server that does not support either "Frobozz" or authorize-only. However, a server that supports authorize-only but does _not_ support "Frobozz" will believe the client intended authorize-only, and will return a successful response on that basis, without verifying the user's identity. That's the situation which we need an "Asserted-Identity" attribute to avoid. The _contents_ of such an attribute are irrelevant; the important thing is an affirmative indication that the client meant authorize-only and not some unknown "Frobozz". -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 20:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Wqy-0005Q9-Rr; Tue, 25 Jul 2006 20:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Wqx-0005Q4-Lf for isms@ietf.org; Tue, 25 Jul 2006 20:02:19 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Wqw-0002RV-CB for isms@ietf.org; Tue, 25 Jul 2006 20:02:19 -0400 Received: from [192.168.1.129] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6F5AB1BAC4D; Wed, 26 Jul 2006 01:46:17 +0200 (CEST) Date: Wed, 26 Jul 2006 02:02:09 +0200 From: Juergen Quittek To: Jeffrey Hutzelman , "McDonald, Ira" , isms@ietf.org Subject: RE: [Isms] Thursday 27 July - Conference call on notifications an d call home Message-ID: <8DD1795E6A212CD376429219@[192.168.1.129]> In-Reply-To: <893B11E596FF5FD398DCA8A2@sirius.fac.cs.cmu.edu> References: <789E617C880666438EDEE30C2A3E8D10EE88@mailsrvnt05.enet.sharplabs .com> <893B11E596FF5FD398DCA8A2@sirius.fac.cs.cmu.edu> X-Mailer: Mulberry/3.1.6 (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: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Ira and Jeff, Thank you for this proper information. The last time I announced an appointment using "EDT" I got the reply "EDT? You probably mean EST DST?". Next time I will follow Jeff's recommendation and use the most precise but hardest to interpret UTC. I am already curious about the replies :-) Thanks, Juergen --On 25.07.2006 15:33 Uhr -0400 Jeffrey Hutzelman wrote: > > > On Tuesday, July 25, 2006 12:11:34 PM -0700 "McDonald, Ira" wrote: > >> Hi, >> >> Retitled with date to highlight the short notice. >> >> At some time I'm unable to determine from the ambiguous >> "Thursday, July 27, 10am EST (DST)" below - perhaps >> "EDT" (Eastern Daylight Savings Time)? > > Yeah; for the benefit of our friends in Europe, "EST" stands for "Eastern Standard Time", and refers specifically to the offset (UTC-5) used when daylight savings is _not_ in effect. > > To be clear, the proposed meeting time is UTC 1400. > > -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jul 25 21:05:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Xq7-0005ka-Iw; Tue, 25 Jul 2006 21:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Xq6-0005kV-4V for isms@ietf.org; Tue, 25 Jul 2006 21:05:30 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Xpz-0002z4-Sj for isms@ietf.org; Tue, 25 Jul 2006 21:05:30 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 21:05:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Thursday 27 July - Conference call on notifications an dcall home Date: Tue, 25 Jul 2006 21:02:29 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560412030@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Thursday 27 July - Conference call on notifications an dcall home Thread-Index: AcawRssHbSAehSqfRUCj1e/u0cQRkwACF+QK References: <789E617C880666438EDEE30C2A3E8D10EE88@mailsrvnt05.enet.sharplabs .com> <893B11E596FF5FD398DCA8A2@sirius.fac.cs.cmu.edu> <8DD1795E6A212CD376429219@[192.168.1.129]> From: "Nelson, David" To: "Juergen Quittek" , "Jeffrey Hutzelman" , "McDonald, Ira" , X-OriginalArrivalTime: 26 Jul 2006 01:05:22.0873 (UTC) FILETIME=[9238AA90:01C6B04F] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 last time I announced an appointment using "EDT" > I got the reply "EDT? You probably mean EST DST?". EDT is correct. Eastern Daylight-savings Time, as opposed to Eastern = Standard Time. =20 =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 00:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5b5v-00010Y-1S; Wed, 26 Jul 2006 00:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5b5t-00010T-Ni for isms@ietf.org; Wed, 26 Jul 2006 00:34:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5b5s-0005u6-DN for isms@ietf.org; Wed, 26 Jul 2006 00:34:01 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2006 21:33:59 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6Q4Xxv2020631; Tue, 25 Jul 2006 21:33:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6Q4XxHS025421; Tue, 25 Jul 2006 21:33:59 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 21:33:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 21:33:56 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597F79@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawOMAr3oPpsfszR46FFBYYv5ru/gAM7sZQ From: "Glen Zorn \(gwz\)" To: "Jeffrey Hutzelman" , "Nelson, David" X-OriginalArrivalTime: 26 Jul 2006 04:33:59.0184 (UTC) FILETIME=[B6862900:01C6B06C] DKIM-Signature: a=rsa-sha1; q=dns; l=1799; t=1153888439; x=1154752439; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=ObhMTwqu9X9VG2wrjKiHlEVyjha9qEjauP/hS63ZbJ1VU+iBfwPVT5NW1THH1fkiXhLf5OTX pz0BgELiMUQ3NdVHNFXgoBq68WvoQLu36P6hzqvVptSibnrdVB1dB1h9; Authentication-Results: sj-dkim-6.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: isms@ietf.org, radiusext@ops.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 Jeffrey Hutzelman supposedly scribbled: > On Tuesday, July 25, 2006 02:16:41 PM -0700 "Glen Zorn (gwz)" > wrote: >=20 >> Don't quite understand this either: if a server doesn't recognize the >> postulated Asserted-Identity Attribute, it seems that as far as it is >> concerned there will be no credential-bearing attribute in the >> message. So just omitting any credential-bearing attribute (along >> with the addition of the other stuff we've been talking about) >> should get just the same response from a legacy server, right? >=20 >> From a _legacy_ server, yes. The concern is about how this would >> affect > handling of some new authentication method invented in the future.=20 > Suppose there is a new method that requires a "Frobozz" attribute, > and we have a client that sends a request using that method. A > server which supports "Frobozz" will respond correctly, as will a > server that does not support either "Frobozz" or authorize-only. =20 >=20 >=20 > However, a server that supports authorize-only but does _not_ support > "Frobozz" will believe the client intended authorize-only, and will > return a successful response on that basis, without verifying the > user's identity. =20 > That's the situation which we need an "Asserted-Identity" attribute > to avoid. The _contents_ of such an attribute are irrelevant; the > important thing is an affirmative indication that the client meant > authorize-only and not some unknown "Frobozz". =20 OK, one more time: that seems to be what a Service-Type of = Authorize-Only would do.... >=20 > -- Jeff Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 00:49:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5bLG-0000dW-PJ; Wed, 26 Jul 2006 00:49:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5bLE-0000ZR-Rp for isms@ietf.org; Wed, 26 Jul 2006 00:49:52 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5bLD-0001cY-Je for isms@ietf.org; Wed, 26 Jul 2006 00:49:52 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6Q4nm8B025298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jul 2006 00:49:48 -0400 (EDT) Date: Wed, 26 Jul 2006 00:49:48 -0400 From: Jeffrey Hutzelman To: "Glen Zorn (gwz)" , "Nelson, David" Subject: RE: [Isms] RE: Follow up on Authorize Only issue Message-ID: <8578C54EEF8E7BB3ACA36108@sirius.fac.cs.cmu.edu> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262502597F79@xmb-sjc-215.amer.cisco.com> References: <4C0FAAC489C8B74F96BEAD85EAEB262502597F79@xmb-sjc-215.amer.cisco .com> Originator-Info: login-token=Mulberry:01APk2k2phqwdMRK4UM3dmApdrbb6HLa9tbmT4Nnk=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Jeffrey Hutzelman , isms@ietf.org, radiusext@ops.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 On Tuesday, July 25, 2006 09:33:56 PM -0700 "Glen Zorn (gwz)" wrote: > Jeffrey Hutzelman supposedly scribbled: > >> On Tuesday, July 25, 2006 02:16:41 PM -0700 "Glen Zorn (gwz)" >> wrote: >> >>> Don't quite understand this either: if a server doesn't recognize the >>> postulated Asserted-Identity Attribute, it seems that as far as it is >>> concerned there will be no credential-bearing attribute in the >>> message. So just omitting any credential-bearing attribute (along >>> with the addition of the other stuff we've been talking about) >>> should get just the same response from a legacy server, right? >> >>> From a _legacy_ server, yes. The concern is about how this would >>> affect >> handling of some new authentication method invented in the future. >> Suppose there is a new method that requires a "Frobozz" attribute, >> and we have a client that sends a request using that method. A >> server which supports "Frobozz" will respond correctly, as will a >> server that does not support either "Frobozz" or authorize-only. >> >> >> However, a server that supports authorize-only but does _not_ support >> "Frobozz" will believe the client intended authorize-only, and will >> return a successful response on that basis, without verifying the >> user's identity. >> That's the situation which we need an "Asserted-Identity" attribute >> to avoid. The _contents_ of such an attribute are irrelevant; the >> important thing is an affirmative indication that the client meant >> authorize-only and not some unknown "Frobozz". > > OK, one more time: that seems to be what a Service-Type of Authorize-Only > would do.... [repeating text from a previous message] Not if you want to use Service-Type to actually indicate the service type, instead of overloading it to mean something else. As I understand it, this attribute is _supposed_ to indicate the type of service the NAS is providing to the user, and overloading it to mean something else was a mistake. If this attribute is used for its intended purpose, to allow the RADIUS server to know what service to provision, then it cannot also be used to indicate authorize-only mode. Otherwise, how is the RADIUS server supposed to know whether my terminal server is asking about providing a user with dialup network access or SNMPv3 access? Some of my users are entitled to one but not the other. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 00:54:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5bPy-00039e-4w; Wed, 26 Jul 2006 00:54:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5bPw-00039T-PR for isms@ietf.org; Wed, 26 Jul 2006 00:54:44 -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 1G5bPv-0002Ws-FK for isms@ietf.org; Wed, 26 Jul 2006 00:54:44 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2006 21:54:43 -0700 X-IronPort-AV: i="4.07,181,1151910000"; d="scan'208"; a="436416410:sNHT26988686" 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.20060308/8.12.11) with ESMTP id k6Q4sgbI027960; Tue, 25 Jul 2006 21:54:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6Q4sbJk011984; Tue, 25 Jul 2006 21:54:42 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 21:54:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 21:54:37 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597F90@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQ From: "Glen Zorn \(gwz\)" To: "Jeffrey Hutzelman" , "Nelson, David" , , X-OriginalArrivalTime: 26 Jul 2006 04:54:38.0643 (UTC) FILETIME=[994C9830:01C6B06F] DKIM-Signature: a=rsa-sha1; q=dns; l=1587; t=1153889682; x=1154753682; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=qSX9uegmeSmBSS09oKQYhl2IQguZ9/FPdYUzbgPvqXDrwkxzP+4gVhAjyJ5sC5c/3cjt5lb/ 0Cika4ehIh/KLs7EA84TGahB/SozvpFraDANJ+GU+KFuF1M710UqH6X6; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Jeffrey Hutzelman supposedly scribbled: > On Tuesday, July 25, 2006 02:20:49 PM -0700 "Glen Zorn (gwz)" > wrote: >=20 >> Actually, no, at least in current usage an authentication type >> _always_ has an associated attribute, which can be seen as something >> that the server doesn't understand. >=20 > Is there a requirement that a server reject a request which contains > any attributes it doesn't understand?=20 >=20 >=20 >=20 >>> A RADIUS server which supports authorize-only will >>> probably want to return success for the request using that feature, >>> but still must return failure for requests using methods it doesn't >>> understand. To make the distinction, you need an affirmative >>> indication from the client that it wants authorize-only; >>=20 >> Is that not provided by the Service-Type of Authorize-Only? >=20 > Not if you want to use Service-Type to actually indicate the service > type,=20 > instead of overloading it to mean something else. As I understand > it, this=20 > attribute is _supposed_ to indicate the type of service the NAS is > providing to the user, and overloading it to mean something else was a > mistake. If this attribute is used for its intended purpose, to > allow the=20 > RADIUS server to know what service to provision, then it cannot also > be=20 > used to indicate authorize-only mode. Too late, it already is. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 03:13:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5daC-00021k-Cj; Wed, 26 Jul 2006 03:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5daA-00021d-P9 for isms@ietf.org; Wed, 26 Jul 2006 03:13:26 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5da8-0002Pw-9x for isms@ietf.org; Wed, 26 Jul 2006 03:13:26 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 630754D36A; Wed, 26 Jul 2006 09:13:23 +0200 (CEST) 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 07379-04; Wed, 26 Jul 2006 09:13:20 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 144734D578; Wed, 26 Jul 2006 09:13:20 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 4783D7A52CE; Wed, 26 Jul 2006 09:13:17 +0200 (CEST) Date: Wed, 26 Jul 2006 09:13:17 +0200 From: Juergen Schoenwaelder To: "Nelson, David" Subject: Re: [Isms] RE: Follow up on Authorize Only issue Message-ID: <20060726071317.GA6315@boskop.local> Mail-Followup-To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org References: <3CFB564E055A594B82C4FE89D2156560219392@MABOSEVS2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219392@MABOSEVS2.ets.enterasys.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: isms@ietf.org, radiusext@ops.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 Tue, Jul 25, 2006 at 05:12:10PM -0400, Nelson, David wrote: > We've had this discussion many months ago. My opinion hasn't changed. > I think that providing a way for RADIUS to provision group membership > information that can be used to map into any Access Control Subsystem > ought to be part of the work. Especially if it does not actually affect > the architectural model, and is accomplished in an implementation > dependent fashion. My understanding is that the concept of a group name is specific to VACM. The ASIs into the ACM subsystem do not carry such a thing as a group name. As such, mappings of security names to group names is VACM specific and clearly happens within VACM from an architectural point of view. While I do see interest in addressing this VACM security name to group name mapping issue, I do indeed see this work item in conflict with the current ISMS charter: : Work on new access control models or centralized administration of : View-based Access Control Model (VACM) rules and mappings is outside : the scope of the working group. Given our current charter, I like to see the RADIUS document we are chartered to produce focus on the RADIUS SSH user authentication and RADIUS authorization of the SSH SNMP subsystem. Another document detailing how RADIUS can be used by VACM to obtain security name to group name mappings might be written and become a WG item in the future once we have completed our current work items and we can re-charter and take on new work. Note that this does of course not impact the RADEXT document which may define all attributes needed to address all the RADIUS related ISMS requirements. I actually like to encourage people to write a document which explains how VACM can utilize RADIUS to provision the security name to group name mapping and to post such a document as an individual draft. But as explained above, this work can't become an official WG work item under the current charter. /js -- Juergen Schoenwaelder International 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 Wed Jul 26 07:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hpb-0001o6-Vw; Wed, 26 Jul 2006 07:45:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hpZ-0001no-AZ for isms@ietf.org; Wed, 26 Jul 2006 07:45:37 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5hpT-0002Q1-27 for isms@ietf.org; Wed, 26 Jul 2006 07:45:37 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 07:45:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 07:45:29 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560412031@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQAA4edMI= References: <4C0FAAC489C8B74F96BEAD85EAEB262502597F90@xmb-sjc-215.amer.cisco .com> From: "Nelson, David" To: , X-OriginalArrivalTime: 26 Jul 2006 11:45:30.0836 (UTC) FILETIME=[FF26B940:01C6B0A8] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Glen Zorn writes... =20 > > If this attribute is used for its intended purpose, to allow the > > RADIUS server to know what service to provision, then it=20 > > cannot also be used to indicate authorize-only mode. > Too late, it already is. Yes, for the Dynamic RADIUS Change of Authorization use case, as = specified in RFC 3576. It has no formally specified usage outside 3576, = that I recall. We need not use that method for the "general" = authorization only case. We could devise a new method, such as the = Asserted-Identity attribute, and relegate the Service-Type =3D = "Authorize Only" usage to CoA only. I tend to agree with Jeff that this portion if RFC 3576 was probably a = "mistake". I can say that as I had nothing to do with that document. = Whether it was or wasn't, we are not obligated to carry that particular = usage into other areas of application for RADIUS. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 11:26:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lHm-0001ET-PJ; Wed, 26 Jul 2006 11:26:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lHl-0001EO-TP for isms@ietf.org; Wed, 26 Jul 2006 11:26:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5lHk-0003pk-Gy for isms@ietf.org; Wed, 26 Jul 2006 11:26:57 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Jul 2006 08:26:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6QFQuuh013505; Wed, 26 Jul 2006 08:26:56 -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 k6QFQtK2015947; Wed, 26 Jul 2006 08:26:55 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 08:26:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 08:26:38 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625025F3ACC@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQAA4edMIAB6ENIA== From: "Glen Zorn \(gwz\)" To: "Nelson, David" X-OriginalArrivalTime: 26 Jul 2006 15:26:40.0966 (UTC) FILETIME=[E4C3DE60:01C6B0C7] DKIM-Signature: a=rsa-sha1; q=dns; l=2111; t=1153927616; x=1154791616; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=CfzLecCuCUZnMCr0rQ/fP9Ij8SuYhMVV17B0Vinm3cpEIlgOXDuwmKFrTJcy5edofItXqcoR KjIXc/s7Ni/YEYOYc1/Z9kyZoeeH1F54sFM5skbSV2KXFJyY3JynvHBB; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: isms@ietf.org, radiusext@ops.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 Nelson, David supposedly scribbled: > Glen Zorn writes... >=20 >>> If this attribute is used for its intended purpose, to allow the >>> RADIUS server to know what service to provision, then it cannot also >>> be used to indicate authorize-only mode. >=20 >> Too late, it already is. >=20 > Yes, for the Dynamic RADIUS Change of Authorization use case, as > specified in RFC 3576. It has no formally specified usage outside > 3576, that I recall. We need not use that method for the "general" > authorization only case. We could devise a new method, such as the > Asserted-Identity attribute, and relegate the Service-Type =3D > "Authorize Only" usage to CoA only. =20 We could, but it seems like a waste of attribute space since the value = if any would of necessity be identical to that carried by the User-Name = Attribute. =20 >=20 > I tend to agree with Jeff that this portion if RFC 3576 was probably > a "mistake". =20 Perhaps, but if so, it lines up very well with the original definition = of the Service-Type Attribute. In fact, I can't find any trace of the = architectural purity imputed to the Attribute by Jeff: only some of the = values of Service-Type are related to service as he has defined it. = Although I wasn't involved (except as a critic ;-) with the development = of RFC 3576 either, it would make perfect sense to me to add a value of = "Authorize Only" to an Attribute that already had values of = "Authenticate Only" & "Call Check" defined, the latter being purely = authorizational in character. > I can say that as I had nothing to do with that > document. Whether it was or wasn't, we are not obligated to carry > that particular usage into other areas of application for RADIUS. =20 >=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 13:25:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5n8r-0000z7-8g; Wed, 26 Jul 2006 13:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5n8q-0000z2-CO for isms@ietf.org; Wed, 26 Jul 2006 13:25:52 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5n8p-0005Bo-2M for isms@ietf.org; Wed, 26 Jul 2006 13:25:52 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 4B5581E155B; Wed, 26 Jul 2006 10:25:50 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Jul 2006 10:25:50 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE8B@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Juergen Quittek' , Jeffrey Hutzelman , isms@ietf.org Subject: RE: [Isms] Thursday 27 July - Conference call on notifications an d call home Date: Wed, 26 Jul 2006 10:25:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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, I use the following link to figure out times in Japan, Europe, and North America (and elsewhere) for Free Stds Group teleconferences: http://www.timeanddate.com/worldclock/ Works well and explains the idiosyncracies of various daylight savings times. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > Sent: Tuesday, July 25, 2006 8:02 PM > To: Jeffrey Hutzelman; McDonald, Ira; isms@ietf.org > Subject: RE: [Isms] Thursday 27 July - Conference call on > notifications > an d call home > > > Ira and Jeff, > > Thank you for this proper information. > > The last time I announced an appointment using "EDT" > I got the reply "EDT? You probably mean EST DST?". > > Next time I will follow Jeff's recommendation and use the > most precise but hardest to interpret UTC. I am already > curious about the replies :-) > > Thanks, > > Juergen > > --On 25.07.2006 15:33 Uhr -0400 Jeffrey Hutzelman wrote: > > > > > > > On Tuesday, July 25, 2006 12:11:34 PM -0700 "McDonald, Ira" > wrote: > > > >> Hi, > >> > >> Retitled with date to highlight the short notice. > >> > >> At some time I'm unable to determine from the ambiguous > >> "Thursday, July 27, 10am EST (DST)" below - perhaps > >> "EDT" (Eastern Daylight Savings Time)? > > > > Yeah; for the benefit of our friends in Europe, "EST" > stands for "Eastern Standard Time", and refers specifically > to the offset (UTC-5) used when daylight savings is _not_ in effect. > > > > To be clear, the proposed meeting time is UTC 1400. > > > > -- Jeff > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/399 - Release Date: 7/25/2006 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 13:41:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nNx-0000Bh-UV; Wed, 26 Jul 2006 13:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nNw-0000Bb-Ua for isms@ietf.org; Wed, 26 Jul 2006 13:41:28 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5nNu-0006WU-Jc for isms@ietf.org; Wed, 26 Jul 2006 13:41:28 -0400 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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Wed, 26 Jul 2006 13:41:49 -0400 Message-ID: In-Reply-To: <44C72DEA.1070406@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcawkV/xhIdQshPITY6tHkixAtQnrAASOKSg From: "Avi Lior" To: "Hannes Tschofenig" X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: radiusext@ops.ietf.org, 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 Hannes, When I wrote the word "assertion" I was thinking a SAML assertion. A word of caution though, everytime I mention XML to my AAA developers they conspire to kill me. XML, parsing strings etc are performance killers for a AAA server. =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, July 26, 2006 4:55 AM > To: Avi Lior > Cc: Glen Zorn (gwz); David Harrington; Eliot Lear;=20 > isms@ietf.org; radiusext@ops.ietf.org > Subject: Re: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Hi Avi, >=20 > I like the idea of using some information to tie the=20 > authentication and the authorization process/exchange=20 > together. In fact we discussed this at the last IETF meeting=20 > when David gave his presentation. >=20 > I suggested to use an existing mechanism to accomplish this=20 > binding, namely SAML. I can elaborate a bit more about the=20 > details if someone case about it. >=20 > Ciao > Hannes >=20 > Avi Lior wrote: > > I proably did not make myself clear....or maybe I did and I=20 > am missing=20 > > something. > >=20 > > When the NAS sends the Access-Request Auth-Only message I=20 > agree that=20 > > it MUST contain Message-Authenticator(80) etc... > >=20 > > What I meant is that it would be nice if there was a token or an=20 > > assertion that came from the place that did authenticate=20 > the user to=20 > > indicate in a cryptographic way that this user was authenticated. > >=20 > > The AAA server can use that token to verify that the user was=20 > > authenticated by an entity that it trusts. Like a kerberose ticket. > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > >>Sent: Tuesday, July 25, 2006 3:47 PM > >>To: Avi Lior; David Harrington; Eliot Lear > >>Cc: isms@ietf.org; radiusext@ops.ietf.org > >>Subject: RE: Follow up on Authorize Only issue (was RE:=20 > >>[Isms] ISMS session > >> > >>Avi Lior supposedly scribbled: > >> > >> > >>>Hi, > >>> > >>>If I was specifying how this is done: > >>> > >>>It would be nice if the AAA client could return some sort > >> > >>of token to > >> > >>>the AAA server to assert that the user has been=20 > authenticated by an=20 > >>>entity that it trusts. The token can be generated by the > >>>Authentication Server. =20 > >>> > >>>We need this assertion to make sure we deliver the correct profile. > >> > >>I disagree: the fact that the message is being sent by an=20 > >>authenticated client at all says that the user has been=20 > authenticated=20 > >>elsewhere. Note that safety requires the inclusion of a=20 > MAC (either=20 > >>the Message-Authenticator or preferably the=20 > >>Message-Authentication-Code Attribute) in the Access-Request. > >> > >>Hope this helps, > >> > >>~gwz > >> > >>Why is it that most of the world's problems can't be solved=20 > by simply > >> listening to John Coltrane? -- Henry Gabriel > >> > >=20 > >=20 > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 > >=20 >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 14:09:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nop-0001UW-MQ; Wed, 26 Jul 2006 14:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5noo-0001UR-76 for isms@ietf.org; Wed, 26 Jul 2006 14:09:14 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5non-0000P8-QY for isms@ietf.org; Wed, 26 Jul 2006 14:09:14 -0400 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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Wed, 26 Jul 2006 14:09:37 -0400 Message-ID: In-Reply-To: <273FD32409B4BC58A366218D@sirius.fac.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcawO89aduzcpUlvQ765NRtR82tFEwAoBKug From: "Avi Lior" To: "Jeffrey Hutzelman" , "Glen Zorn \(gwz\)" , "David Harrington" , "Eliot Lear" X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: isms@ietf.org, radiusext@ops.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 Jeffrey. =20 > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 > Sent: Tuesday, July 25, 2006 6:43 PM > To: Avi Lior; Glen Zorn (gwz); David Harrington; Eliot Lear > Cc: isms@ietf.org; radiusext@ops.ietf.org; Jeffrey Hutzelman > Subject: RE: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 >=20 >=20 > On Tuesday, July 25, 2006 05:40:00 PM -0400 Avi Lior=20 > wrote: >=20 > > I proably did not make myself clear....or maybe I did and I=20 > am missing=20 > > something. > > > > When the NAS sends the Access-Request Auth-Only message I=20 > agree that=20 > > it MUST contain Message-Authenticator(80) etc... > > > > What I meant is that it would be nice if there was a token or an=20 > > assertion that came from the place that did authenticate=20 > the user to=20 > > indicate in a cryptographic way that this user was authenticated. > > > > The AAA server can use that token to verify that the user was=20 > > authenticated by an entity that it trusts. Like a kerberose ticket. >=20 > First, the user was authenticated by the NAS. That is all=20 > the RADIUS server needs to know. The RADIUS server provides=20 > service to the NAS, not the user, and the NAS has asked for=20 > information about what the user is allowed to do. Either the=20 > RADIUS server is willing to give that information to the NAS=20 > or it is not, but it is the NAS that is making the request,=20 > not the user. I don't have a problem with that. But it would be better if the NAS can prove to the AAA server that the user was authenticated. Normally it is the AAA that authenticates the user and provides authorization attributes. >=20 > RADIUS servers provide authentication as a _service_ to the=20 > NAS, not as a means of determining whether the NAS is=20 > legitimate or should be given information. A NAS that is not=20 > interested in that service should not be required to use it=20 > in order to make use of the other services that the RADIUS=20 > server can provide, such as provisioning and accounting. =20 > Once again, the RADIUS server's relationship is with the NAS,=20 > not the user. Not true. Normally the RADIUS server (in particular the home RADIUS server) owns the user. Therefore it has a trust relationship with the user. The mechanism for that trust relationship is a credential (password or shared key) known only to those two parties. The RADIUS server trusts the NAS directly or via a trust chain. The trust mechanism is a shared secret or in the case of a trust chain, a set of trust secrets. >=20 > Secondly, as I already said, the sort of token you describe=20 > simply does not exist for most authentication mechanisms. A=20 > Kerberos ticket is not cryptographic proof that a user has=20 > authenticated. It is an encrypted message from the Kerberos=20 > server to a particular service, and is useless to anyone=20 > else. And, it's not a message saying "this user authenticated".=20 > It's a message telling the service the keys it needs to know=20 > in order to conduct an exchange with a user and determine=20 > whether that user is real. Well if that token did exist then it will be useful to use it.=20 I stand corrected on Kerberose. However, there are tokens that are used for single-sign-on that do prove the authenticity of the token holder. Why can't something like that be used? =20 >=20 > Thirdly, as I've also said before, this is a serious=20 > abstraction violation.=20 > Even if every service had such a magic cookie, what you're=20 > suggesting would require defining what it is, for RADIUS, for=20 > every authentication mechanism that might be used by a NAS=20 > using authorize-only. What magic token are you going to use=20 > for TLS? What about USM? GSS-spkm? SSH public key?=20 > one-time passwords? SSH host-based public key? NTLM? =20 > IPsec? How about the Frobozz protocol I referred to in an=20 > earlier message? You don't even know how that works, so=20 > you'd basically guarantee that when I get a NAS that supports=20 > the Frobozz protocol, I can't use it until I define an=20 > extension to the RADIUS protocol and upgrade my server. Perhaps I missled you and I am sorry. So let me clarify... First and foremost I am in favour of supporting the scheme that a NAS ought to be able to peform an Authorize-Only to a AAA sever regardless if that AAA server has authenticated the user or not. There are a huge security issues but so be it. Those security issue can be managed in many ways. The scheme is useful!!! The second part of my email was about one method of managing that security. Again, I would not want to mandate that method and mandate that that would be the only way to design such a system. In general my philosophy is that the IETF should build tools. Some of these tools can be dangerous if not used properly. The IETF should provide its wisdom on how one may use these tools and identify the risks as best it can. =20 >=20 > -- Jeff >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 14:21:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5o0E-00079R-TQ; Wed, 26 Jul 2006 14:21:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5o0E-00079J-4o for isms@ietf.org; Wed, 26 Jul 2006 14:21:02 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5o07-0000y7-St for isms@ietf.org; Wed, 26 Jul 2006 14:21:02 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 14:20:54 -0400 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] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 14:20:54 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219397@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplg From: "Nelson, David" To: , X-OriginalArrivalTime: 26 Jul 2006 18:20:54.0750 (UTC) FILETIME=[3BB4B7E0:01C6B0E0] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 writes... =20 > Given our current charter, I like to see the RADIUS document we are > chartered to produce focus on the RADIUS SSH user authentication and > RADIUS authorization of the SSH SNMP subsystem. We'll omit any discussion of "fine grained" access control, i.e. anything other than whether the SSH server should offer to make a connection to the SNMP engine, in the -01 version. > Note that this does of course not impact the RADEXT document which > may define all attributes needed to address all the RADIUS related=20 > ISMS requirements. OK, thanks. > I actually like to encourage people to write a document which=20 > explains how VACM can utilize RADIUS to provision the security=20 > name to group name mapping and to post such a document as an=20 > individual draft. I also think that would be useful, and predict that folks are likely to implement such a scheme, whether ISMS takes it up or not. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 15:55:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pTY-0004nI-MR; Wed, 26 Jul 2006 15:55:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pTX-0004n0-Iq for isms@ietf.org; Wed, 26 Jul 2006 15:55:23 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5pTV-0002fi-2c for isms@ietf.org; Wed, 26 Jul 2006 15:55:23 -0400 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] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 15:55:43 -0400 Message-ID: In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625025F3ACC@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQAA4edMIAB6ENIAAJia2A From: "Avi Lior" To: "Glen Zorn \(gwz\)" , "Nelson, David" X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: isms@ietf.org, radiusext@ops.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 I agree with Glen.... If the using Service-Type to convey Authorize-Only was a mistake that mistake was made a long time before 3576. During 3576 I did bring up the issue of putting Authorize-Only in service type. My concern then was exaclty what we are facing today. It becomes hard for us to express both that we want to Authenticate or Authorize or and what service this applies to. But 3576 and WG decided not to go there. In hindsight, Authorize/Authetnication/Callcheck/etc should have used an attribute specifically for that purpose. The lesson is that we should be learning is not to overload attributes. I think introducing another Authorize-Only semantic is bad as well. I think that saying that Authorize-Only is only a 3576 think flies in the nature of all RADIUS RFCs. Finally, in view of the overloading of Service-Type, the use of NAS-Port-Type to provide a context for the type of service being requested is not ideal but it does work.=20 Avi > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn (gwz) > Sent: Wednesday, July 26, 2006 11:27 AM > To: Nelson, David > Cc: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: [Isms] RE: Follow up on Authorize Only issue >=20 > Nelson, David supposedly scribbled: >=20 > > Glen Zorn writes... > >=20 > >>> If this attribute is used for its intended purpose, to allow the=20 > >>> RADIUS server to know what service to provision, then it=20 > cannot also=20 > >>> be used to indicate authorize-only mode. > >=20 > >> Too late, it already is. > >=20 > > Yes, for the Dynamic RADIUS Change of Authorization use case, as=20 > > specified in RFC 3576. It has no formally specified usage outside=20 > > 3576, that I recall. We need not use that method for the "general" > > authorization only case. We could devise a new method, such as the=20 > > Asserted-Identity attribute, and relegate the Service-Type =3D=20 > > "Authorize Only" usage to CoA only. >=20 > We could, but it seems like a waste of attribute space since=20 > the value if any would of necessity be identical to that=20 > carried by the User-Name Attribute. > =20 > >=20 > > I tend to agree with Jeff that this portion if RFC 3576 was=20 > probably a=20 > > "mistake". >=20 > Perhaps, but if so, it lines up very well with the original=20 > definition of the Service-Type Attribute. In fact, I can't=20 > find any trace of the architectural purity imputed to the=20 > Attribute by Jeff: only some of the values of Service-Type=20 > are related to service as he has defined it. Although I=20 > wasn't involved (except as a critic ;-) with the development=20 > of RFC 3576 either, it would make perfect sense to me to add=20 > a value of "Authorize Only" to an Attribute that already had=20 > values of "Authenticate Only" & "Call Check" defined, the=20 > latter being purely authorizational in character. >=20 > > I can say that as I had nothing to do with that document. =20 > Whether it=20 > > was or wasn't, we are not obligated to carry > > that particular usage into other areas of application for RADIUS. =20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms >=20 > Hope this helps, >=20 > ~gwz >=20 > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 15:56:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pUL-0005VA-8d; Wed, 26 Jul 2006 15:56:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pUK-0005RZ-4E for isms@ietf.org; Wed, 26 Jul 2006 15:56:12 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5pUE-0002oA-QD for isms@ietf.org; Wed, 26 Jul 2006 15:56:12 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 15:56:05 -0400 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: Wed, 26 Jul 2006 15:56:04 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219398@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/A= From: "Nelson, David" To: , X-OriginalArrivalTime: 26 Jul 2006 19:56:05.0245 (UTC) FILETIME=[876D1AD0:01C6B0ED] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Isms] Summary of Authorize Only issue 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 Let me see if I can summarize the discussion so far, and if folks agree that I've summarized accurately. (1) There are three basic SNMP over SSH use cases: (a) RADIUS provides initial authentication and=20 base-service authorization of SNMPv3 over SSH. (b) Some other authentication mechanism/service=20 provides initial authentication (and no authorization) of SNMPv3 over SSH. (c) Some other authentication mechanism/service=20 provides initial authentication (and no authorization) of SNMPv3 over SSH. RADIUS provides base-service authorization of SNMPv3 over SSH (but no authentication). Note that "base-service" authorization means that the SSH server in the NAS is allowed to provide connectivity via SSH to the SNMPv3 engine of the NAS. In case (1a) we require the existing RADIUS authentication methods, primarily the password authentication, plus some attributes to authorize the service, such as Service-Type =3D Framed-Management, and Framed-Management-Protocol =3D SNMPv3-over-SSH. In case (1b) there are no requirements for RADIUS. In case (1c) we require the ability for RADIUS to provide an Authorize Only service for SNMP usage. The provisioning attributes are the same as for case (1a). We have seen a considerable amount of discussion on the mailing list of the issues and properties of an Authorize Only service in RADIUS. Many of those discussions focus on potential solutions, but I've restricted this posting to requirements.=20 (2) There are two extended SNMP over SSH use cases: (a) RADIUS provides initial authentication and=20 authorization of SNMPv3 over SSH, base-service authorization, and (optionally) granular access control authorization. (b) Some other authentication mechanism/service=20 provides initial authentication (and no authorization) of SNMPv3 over SSH. RADIUS provides base-service authorization and=20 (optionally) granular access control authorization. Note that "granular access control" means a mapping to the VACM or some other Access Control Subsystem. These use cases are currently out of scope for the ISMS WG charter, but might be added at a later date. In case (2a) the additional RADIUS requirement is for an attribute to authorize granular access control, for example by providing a mapping of securityName to securityGroup, for use with the VACM. An example of such an attribute is Management-Policy-ID, conceptually similar to Filter-ID. In case (2b) the additional requirements for RADIUS include those of case (2a) plus the ability for RADIUS to provide an Authorize Only service for SNMP usage. (3) The basic RADIUS trust model dictates that if a NAS, that possess a valid shared secret with a RADIUS Server, is compromised, nothing in the RADIUS protocol can mitigate that breach, at least in terms of the services to which the NAS mediates access. (4) RADIUS Servers SHOULD exercise appropriate policy enforcement in terms of providing any NAS with attributes that might disclose security sensitive information related to a user, e.g. keys, unless that user has been successfully authenticated to the RADIUS Server via the NAS in question. This affects RADIUS Server behavior during any Authorize Only service provisioning. In any of the use cases, it is important that the NAS, i.e. the RADIUS Client, be able to communicate the kind of service being sought via hint attributes to the RADIUS Server, in the Access-Request message. This has implications on the use of the Service-Type in Authorize Only operations, in which it would otherwise be used as a hint of the requested service, and not the request authentication method. It is also important that the RADIUS Server be able to specify the provisioning of SNMPv3 over SSH service to the NAS in the Access-Accept message. Does this accurately summarize the consensus on this issue? Especially in terms of requirements that ISMS has of RADEXT? Please advise, with suggestions for improvement. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 16:12:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pkS-0000c0-Iy; Wed, 26 Jul 2006 16:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pkR-0000bq-Ls for isms@ietf.org; Wed, 26 Jul 2006 16:12:51 -0400 Received: from bay0-omc3-s15.bay0.hotmail.com ([65.54.246.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5pkQ-0004hx-6V for isms@ietf.org; Wed, 26 Jul 2006 16:12:51 -0400 Received: from hotmail.com ([65.54.161.42]) by bay0-omc3-s15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 13:12:49 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 26 Jul 2006 13:12:49 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 26 Jul 2006 20:12:46 GMT X-Originating-IP: [24.16.73.85] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219398@MABOSEVS2.ets.enterasys.com> From: "Bernard Aboba" To: dnelson@enterasys.com, isms@ietf.org, radiusext@ops.ietf.org Bcc: Date: Wed, 26 Jul 2006 13:12:46 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Jul 2006 20:12:49.0318 (UTC) FILETIME=[DDE67C60:01C6B0EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Isms] RE: Summary of Authorize Only issue 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 >(4) RADIUS Servers SHOULD exercise appropriate policy enforcement in >terms of providing any NAS with attributes that might disclose security >sensitive information related to a user, e.g. keys, unless that user has >been successfully authenticated to the RADIUS Server via the NAS in >question. This affects RADIUS Server behavior during any Authorize Only >service provisioning. For this to be successful, the RADIUS server needs to know what service is being requested by the NAS, so that it can limit the attributes to those relevant to that service (or refuse to authorize the service). The service cannot be characterized by saying it is "authorize-only" -- that is merely a particular (authorize-only) mode of a particular service which needs to be specified by the NAS. >In any of the use cases, it is important that the NAS, i.e. the RADIUS >Client, be able to communicate the kind of service being sought via hint >attributes to the RADIUS Server, in the Access-Request message. Service-Type is not a "hint". A RADIUS client that receives an Access-Accept with an unknown Service-Type does not treat the attribute as a "hint" -- it treats it as an Access-Reject. This is mandatory behavior in RFC 2865. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 18:44:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5s7J-00006h-Pp; Wed, 26 Jul 2006 18:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5s7I-0008Rm-1Z for isms@ietf.org; Wed, 26 Jul 2006 18:44:36 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5s7G-0008GB-Md for isms@ietf.org; Wed, 26 Jul 2006 18:44:36 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id C7A9811D390; Wed, 26 Jul 2006 15:44:31 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Subject: Re: [Isms] transport subsystem and new terminology Organization: Sparta References: <048901c6af65$28d0ad40$0400a8c0@china.huawei.com> Date: Wed, 26 Jul 2006 15:44:31 -0700 In-Reply-To: <048901c6af65$28d0ad40$0400a8c0@china.huawei.com> (David Harrington's message of "Mon, 24 Jul 2006 17:07:23 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'Dave Harrington' , 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 >>>>> On Mon, 24 Jul 2006 17:07:23 -0400, "David Harrington" said: David> I have committed my time for this coming week to work on company David> projects, so I will probably not have a lot of time to analyze the David> impact on TMSM and SSHSM of Wes's three approaches. His approaches are David> not described in terms of RFC3411 architectural modularity, and I David> would like to better understand how his stuff fits into the RFC3411 David> architecture, and the EOP I have in the current documents. David, since you don't have time to do an analysis (and I just got back into town from vacation and don't have time to write much up quickly), I'll answer your questions: 1) the architecture described in my message does fit into 3411 models. I need more details about which of the 341x architectures you think don't fit. 2) based on another message, there may be a typo or two in the message (it was mostly un-proof-read) at least in the usage of the terms NG and NR. I need to review it along side your comments on the subject. I don't believe I proposed anything that violates 3411 architectural concepts. The only potential break is who opens the transport through which SNMPv3 messages get sent (EG, either the NG or the NR could). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 18:48:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sBX-0002Fi-HV; Wed, 26 Jul 2006 18:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sBW-0002FO-96 for isms@ietf.org; Wed, 26 Jul 2006 18:48:58 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5sBU-0000WF-JB for isms@ietf.org; Wed, 26 Jul 2006 18:48:58 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id AD73411D3EB; Wed, 26 Jul 2006 15:48:51 -0700 (PDT) From: Wes Hardaker To: Sam Hartman Subject: Re: [Isms] snmpwalk, snmpget and notifications Organization: Sparta References: Date: Wed, 26 Jul 2006 15:48:51 -0700 In-Reply-To: (Sam Hartman's message of "Wed, 12 Jul 2006 16:01:57 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 >>>>> On Wed, 12 Jul 2006 16:01:57 -0400, Sam Hartman said: Sam> That means that if I use a command like snmpget to open up an ssh Sam> session to send a command then I need to be prepared to receive and Sam> deal with a notification on that session. Unless such notifications aren't sent unless a "signal" is passed to turn them on. Sam> I think that's a change from how SNMP works today. Unless a signal is passed, in which case I think it wouldn't cause problems. Actually, based on the way snmp clients are supposed to be built it based on the protocol specs it shouldn't be a problem anyway. Specifically, a snmp stack is already expected to discard unexpected messages. But a signaling mechanism would be far Superior and is needed, IMHO. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 18:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sC1-0003XP-SI; Wed, 26 Jul 2006 18:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sC0-0003XK-J3 for isms@ietf.org; Wed, 26 Jul 2006 18:49:28 -0400 Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5sBy-0000Yw-BW for isms@ietf.org; Wed, 26 Jul 2006 18:49:28 -0400 Received: from h-68-165-5-186.snvacaid.dynamic.covad.net ([68.165.5.186] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #1) id 1G5sBx-00024r-00 for isms@ietf.org; Wed, 26 Jul 2006 18:49:25 -0400 Message-ID: <004201c6b105$f7bdc600$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <3CFB564E055A594B82C4FE89D2156560219392@MABOSEVS2.ets.enterasys.com> <20060726071317.GA6315@boskop.local> Subject: Re: [Isms] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 15:51:00 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 - > From: "Juergen Schoenwaelder" > To: "Nelson, David" > Cc: ; > Sent: Wednesday, July 26, 2006 12:13 AM > Subject: Re: [Isms] RE: Follow up on Authorize Only issue ... > I actually like to encourage people to write a document which explains > how VACM can utilize RADIUS to provision the security name to group > name mapping and to post such a document as an individual draft. But > as explained above, this work can't become an official WG work item > under the current charter. ... Bottom line: without this out-of-charter work, whatever isms produces will have, from a provisioning perspective, the same characteristics as existing USM. Specifically, for each user, every box to which that user is to have any access rights will need to be configured before that user will be able to do anything with that box. The only change from what we have today is that the number of configuration PDUs will be somewhat smaller. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 19:06:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sSM-0005wC-KW; Wed, 26 Jul 2006 19:06:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sSL-0005vx-FK for isms@ietf.org; Wed, 26 Jul 2006 19:06:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5pqm-0005RM-7I for isms@ietf.org; Wed, 26 Jul 2006 16:19:24 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5pbN-0000C9-Qq for isms@ietf.org; Wed, 26 Jul 2006 16:03:33 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 16:03:22 -0400 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] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 16:03:22 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219399@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQAA4edMIAB6ENIAAJia2AAABScO A= From: "Nelson, David" To: , X-OriginalArrivalTime: 26 Jul 2006 20:03:22.0985 (UTC) FILETIME=[8C56ED90:01C6B0EE] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: -2.6 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Avi Lior writes... > But 3576 and WG decided not to go there. Unless I'm mistaken, RFC 3576 was not the work product of any WG. It occurred after the RADIUS WG closed, and prior to the RADEXT WG opening. > In hindsight, Authorize/Authetnication/Callcheck/etc should have used an > attribute specifically for that purpose. Perhaps. > The lesson is that we should be learning is not to overload attributes. I agree. =20 > I think introducing another Authorize-Only semantic is bad as well. I > think that saying that Authorize-Only is only a 3576 think flies in the > nature of all RADIUS RFCs. There are potential disadvantages, primarily in terms of how existing RADIUS servers are implemented, but I don't see this as quite so much of a problem. > Finally, in view of the overloading of Service-Type, the use of > NAS-Port-Type to provide a context for the type of service being > requested is not ideal but it does work. IMHO, overloading NAS-Port-Type is as bad as, if not worse than, overloading Service-Type. Overloading is overloading. Overloading is bad. ;-) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 19:25:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5skd-0002V2-VV; Wed, 26 Jul 2006 19:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5skd-0002Ux-Gp for isms@ietf.org; Wed, 26 Jul 2006 19:25:15 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5skc-00052R-1z for isms@ietf.org; Wed, 26 Jul 2006 19:25:15 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 7D3DE11D390; Wed, 26 Jul 2006 16:25:11 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Subject: Re: [Isms] RE: Follow up on Authorize Only issue Organization: Sparta References: <3CFB564E055A594B82C4FE89D2156560219392@MABOSEVS2.ets.enterasys.com> <20060726071317.GA6315@boskop.local> <004201c6b105$f7bdc600$6501a8c0@oemcomputer> Date: Wed, 26 Jul 2006 16:25:11 -0700 In-Reply-To: <004201c6b105$f7bdc600$6501a8c0@oemcomputer> (Randy Presuhn's message of "Wed, 26 Jul 2006 15:51:00 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 >>>>> On Wed, 26 Jul 2006 15:51:00 -0700, "Randy Presuhn" said: >> I actually like to encourage people to write a document which explains >> how VACM can utilize RADIUS to provision the security name to group >> name mapping and to post such a document as an individual draft. But >> as explained above, this work can't become an official WG work item >> under the current charter. Randy> Bottom line: without this out-of-charter work, whatever isms Randy> produces will have, from a provisioning perspective, the same Randy> characteristics as existing USM. Specifically, for each user, Randy> every box to which that user is to have any access rights will Randy> need to be configured before that user will be able to do Randy> anything with that box. The only change from what we have Randy> today is that the number of configuration PDUs will be somewhat Randy> smaller. That's close, but not correct. Yes, there will have to be some level of configuration to allow a given user to access the device over SNMP. The big gain by ISMS without USM is the ability to use the existing users and the user authentication management system they already have in place. That's a big win. Would it be nice to have an automated ACM population mechanism in place as well? certainly. Do I even think the work should be added to the charter? sure. But, the resulting work MUST NOT be married together. I've stated this before many times (including during both BOFs) but I'll restate it because it's the one thing that I think would actually decrease the usability of the results. I'm all for developing a radius extension to populate the VACM (or however you want to think about it) as long as the SSH half of the ISMS mechanisms doesn't require it. My largest customers don't use RADIUS today but would like SNMP/SSH and don't care too much about the configuration load since there is already a zillion things that need to be bootstrapped in the device. IMHO, the biggest problem with USM is not the initialization it's the continued maintenance. (bootstrapping is a big issue to, mind you, but secondary to the long term planning). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 20:07:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tPl-0003W6-Ag; Wed, 26 Jul 2006 20:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tPj-0003VR-Kp for isms@ietf.org; Wed, 26 Jul 2006 20:07:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5o8S-0001it-Dw for isms@ietf.org; Wed, 26 Jul 2006 14:29:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5nxi-0006hz-NK for isms@ietf.org; Wed, 26 Jul 2006 14:18:30 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2006 11:18:25 -0700 X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="308189357:sNHT7247894190" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6QIINDR025662; Wed, 26 Jul 2006 11:18:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6QIIN79027581; Wed, 26 Jul 2006 11:18:23 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Jul 2006 11:18:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Wed, 26 Jul 2006 11:18:21 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625025F3BF5@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcawkV/xhIdQshPITY6tHkixAtQnrAASOKSgAAD36qA= From: "Glen Zorn \(gwz\)" To: "Avi Lior" , "Hannes Tschofenig" X-OriginalArrivalTime: 26 Jul 2006 18:18:22.0897 (UTC) FILETIME=[E131CA10:01C6B0DF] DKIM-Signature: a=rsa-sha1; q=dns; l=4384; t=1153937903; x=1154801903; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session; X=v=3Dcisco.com=3B=20h=3DEvtPMlNbcxEdOSYlFBdUnxJo5Vs=3D; b=fmckMKsI0sMKqbFW9gKAfV1cGR7VsRGVCUp54HBWsV9WBW1P6hkela/uprE3936ManPGEh6M YVMbpMVVOMpBPRRhhjsBwBf02kH9jlysdX0SML9fGk0nQis8l8swxX9/; Authentication-Results: sj-dkim-6.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: isms@ietf.org, radiusext@ops.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 Avi Lior supposedly scribbled: > Hi Hannes, >=20 > When I wrote the word "assertion" I was thinking a SAML assertion. In order for this to have any meaning at all, the source of this = assertion would need to be trusted by both the RADIUS client and = server. This seems to imply a bunch of new keys, at a minimum, unless = you don't care to authenticate the token/assertion/whatever (in which = case why bother?). In addition, the token/assertion/whatever would need = to be somehow delivered from something, somewhere in a secure fashion to = the RADIUS client for forwarding to the RADIUS server. Aside from those = minor nits (modifying both the RADIUS entities to receive, transmit & = understand the token/assertion/whatever & more than likely the = SSH/Kerberos/whatever entities to actually generate & deliver the = token/assertion/whatever), I think this is a great idea. >=20 > A word of caution though, everytime I mention XML to my AAA > developers they conspire to kill me.=20 Good people & wise! >=20 > XML, parsing strings etc are performance killers for a AAA server. >=20 >=20 >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, July 26, 2006 4:55 AM >> To: Avi Lior >> Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; isms@ietf.org; >> radiusext@ops.ietf.org Subject: Re: Follow up on Authorize Only >> issue (was RE: [Isms] ISMS session=20 >>=20 >> Hi Avi, >>=20 >> I like the idea of using some information to tie the authentication >> and the authorization process/exchange together. In fact we discussed >> this at the last IETF meeting when David gave his presentation. >>=20 >> I suggested to use an existing mechanism to accomplish this binding, >> namely SAML. I can elaborate a bit more about the details if someone >> case about it.=20 >>=20 >> Ciao >> Hannes >>=20 >> Avi Lior wrote: >>> I proably did not make myself clear....or maybe I did and I am >>> missing something.=20 >>>=20 >>> When the NAS sends the Access-Request Auth-Only message I agree that >>> it MUST contain Message-Authenticator(80) etc... >>>=20 >>> What I meant is that it would be nice if there was a token or an >>> assertion that came from the place that did authenticate the user=20 >>> to indicate in a cryptographic way that this user was authenticated. >>>=20 >>> The AAA server can use that token to verify that the user was >>> authenticated by an entity that it trusts. Like a kerberose ticket. >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Glen Zorn (gwz) [mailto:gwz@cisco.com] >>>> Sent: Tuesday, July 25, 2006 3:47 PM >>>> To: Avi Lior; David Harrington; Eliot Lear >>>> Cc: isms@ietf.org; radiusext@ops.ietf.org >>>> Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] >>>> ISMS session=20 >>>>=20 >>>> Avi Lior supposedly scribbled: >>>>=20 >>>>=20 >>>>> Hi, >>>>>=20 >>>>> If I was specifying how this is done: >>>>>=20 >>>>> It would be nice if the AAA client could return some sort >>>>=20 >>>> of token to >>>>=20 >>>>> the AAA server to assert that the user has been authenticated by >>>>> an entity that it trusts. The token can be generated by the >>>>> Authentication Server.=20 >>>>>=20 >>>>> We need this assertion to make sure we deliver the correct >>>>> profile.=20 >>>>=20 >>>> I disagree: the fact that the message is being sent by an >>>> authenticated client at all says that the user has been >>>> authenticated elsewhere. Note that safety requires the inclusion >>>> of a MAC (either the Message-Authenticator or preferably the >>>> Message-Authentication-Code Attribute) in the Access-Request. >>>>=20 >>>> Hope this helps, >>>>=20 >>>> ~gwz >>>>=20 >>>> Why is it that most of the world's problems can't be solved by >>>> simply listening to John Coltrane? -- Henry Gabriel >>>>=20 >>>=20 >>>=20 >>> -- >>> to unsubscribe send a message to >> radiusext-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 21:01:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uFL-0005Uc-Gy; Wed, 26 Jul 2006 21:01:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uFK-0005O2-1Q for isms@ietf.org; Wed, 26 Jul 2006 21:01:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5q7W-0000N8-6e for isms@ietf.org; Wed, 26 Jul 2006 16:36:42 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5pqy-0000ma-1e for isms@ietf.org; Wed, 26 Jul 2006 16:19:42 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 16:19:32 -0400 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: Wed, 26 Jul 2006 16:19:32 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021939A@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of Authorize Only issue Thread-Index: Acaw7+IqQclqiKSMT+eqChmbGAxJygAADkig From: "Nelson, David" To: , X-OriginalArrivalTime: 26 Jul 2006 20:19:32.0716 (UTC) FILETIME=[CE5822C0:01C6B0F0] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: -2.6 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Isms] RE: Summary of Authorize Only issue 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 Bernard Aboba writes... > For this to be successful, the RADIUS server needs to know what=20 > service is being requested by the NAS, so that it can limit the=20 > attributes to those relevant to that service (or refuse to=20 > authorize the service). The service cannot be characterized by > saying it is "authorize-only" -- that is merely a particular=20 > (authorize-only) mode of a particular service which needs to > be specified by the NAS. I agree (100%). =20 > >In any of the use cases, it is important that the NAS, i.e. > >the RADIUS Client, be able to communicate the kind of service > >being sought via hint attributes to the RADIUS Server, in the > >Access-Request message. >=20 > Service-Type is not a "hint".=20 It is when it appears in an Access-Request message. This is the context of the foregoing paragraph. > A RADIUS client that receives=20 > an Access-Accept with an unknown Service-Type does not treat=20 > the attribute as a "hint" -- it treats it as an Access-Reject.=20 > This is mandatory behavior in RFC 2865. I agree, when it appears in an Access-Accept message. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jul 26 22:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5vfr-000568-PX; Wed, 26 Jul 2006 22:32:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5vfq-000560-1q for isms@ietf.org; Wed, 26 Jul 2006 22:32:30 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5vfp-0007bp-Kq for isms@ietf.org; Wed, 26 Jul 2006 22:32:30 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060727023228b1300ig7gfe>; Thu, 27 Jul 2006 02:32:29 +0000 From: "David Harrington" To: "'Nelson, David'" , , Subject: RE: [Isms] Summary of Authorize Only issue Date: Wed, 26 Jul 2006 22:31:05 -0400 Message-ID: <064801c6b124$b66b4460$0400a8c0@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: <3CFB564E055A594B82C4FE89D2156560219398@MABOSEVS2.ets.enterasys.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/AAAsddQA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 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, Comments inline. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Wednesday, July 26, 2006 3:56 PM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: [Isms] Summary of Authorize Only issue > > Let me see if I can summarize the discussion so far, and if > folks agree > that I've summarized accurately. > > (1) There are three basic SNMP over SSH use cases: > > (a) RADIUS provides initial authentication and > base-service authorization of SNMPv3 over > SSH. I think "SNMP over SSH" would be appropriate. I do not see a reason to limit it to SNMPv3. While only SNMPv3 is beig fitted to the SSH transport today, other versions of SNMP could be supported in the future. The message version should not make a difference. > > (b) Some other authentication mechanism/service > provides initial authentication (and no > authorization) of SNMPv3 over SSH. Whether the other services provides authorization or not is immaterial. > > (c) Some other authentication mechanism/service > provides initial authentication (and no > authorization) of SNMPv3 over SSH. RADIUS > provides base-service authorization of > SNMPv3 over SSH (but no authentication). I'm not sure anybody has asked for this combination, but I suppose we don't need to rule it out. > > Note that "base-service" authorization means that the SSH > server in the > NAS is allowed to provide connectivity via SSH to the SNMPv3 engine of > the NAS. I would like to make sure everybody understands that the NAS is the managed device, not only edge devices providing network access services; Every SNMP-manageable device in the network might be considered a NAS in this scenario. > > In case (1a) we require the existing RADIUS authentication methods, > primarily the password authentication, plus some attributes > to authorize > the service, such as Service-Type = Framed-Management, and > Framed-Management-Protocol = SNMPv3-over-SSH. Educate me. Why primarily the password authentication? Does this imply a (plaintext) password? I think that might be undesirable if it requires the pass-through of a human interaction, or storage of a password at the management application or the managed system. It is highly likely the "user" might be a management application like HP OpenView or Spectrum, rather than a user working with snmp command line tools. Other authentication mechanisms might be preferable to passwords; I assume RADIUS supports a wide range of authentication mechanisms. > > In case (1b) there are no requirements for RADIUS. > > In case (1c) we require the ability for RADIUS to provide an Authorize > Only service for SNMP usage. The provisioning attributes are the same > as for case (1a). > > We have seen a considerable amount of discussion on the > mailing list of > the issues and properties of an Authorize Only service in > RADIUS. Many > of those discussions focus on potential solutions, but I've restricted > this posting to requirements. > > (2) There are two extended SNMP over SSH use cases: I think there are three extended SNMP use cases that involve RADIUS > > (a) RADIUS provides initial authentication and > authorization of SNMPv3 over SSH, base-service > authorization, and (optionally) granular access > control authorization. > > (b) Some other authentication mechanism/service > provides initial authentication (and no > authorization) of SNMPv3 over SSH. RADIUS > provides base-service authorization and > (optionally) granular access control > authorization. (c) RADIUS does not perform authentication or base-service authorization. Some other authentication mechanism/service provides initial authentication and presumably base service authorization for SNMP over whatever secure transport, such as SNMP using USM over UDP, or SNMP using USM and TCP/IPv6, or SNMP using Kerberos and SCTP, or SNMP using 802.1AE and Ethernet. The access control subsystem requests from RADIUS ONLY the granular access control authorization associated with the otherwise-authenticated user. (e.g., hey RADIUS, which group is this guy in?) > > Note that "granular access control" means a mapping to the > VACM or some > other Access Control Subsystem. > > These use cases are currently out of scope for the ISMS WG > charter, but > might be added at a later date. Yes. I think demand for this is high and should definitely be added at a later date. > > In case (2a) the additional RADIUS requirement is for an attribute to > authorize granular access control, for example by providing a > mapping of > securityName to securityGroup, for use with the VACM. An example of > such an attribute is Management-Policy-ID, conceptually similar to > Filter-ID. > > In case (2b) the additional requirements for RADIUS include those of > case (2a) plus the ability for RADIUS to provide an Authorize Only > service for SNMP usage. In case (2c) the ONLY requirement for the RADIUS server is to provide to the trusted RADIUS client an attribute such as a Management-Policy-ID, for a user identity that was authenticated and base-authorized by some other service. > > (3) The basic RADIUS trust model dictates that if a NAS, that > possess a > valid shared secret with a RADIUS Server, is compromised, > nothing in the > RADIUS protocol can mitigate that breach, at least in terms of the > services to which the NAS mediates access. > > (4) RADIUS Servers SHOULD exercise appropriate policy enforcement in > terms of providing any NAS with attributes that might > disclose security > sensitive information related to a user, e.g. keys, unless > that user has > been successfully authenticated to the RADIUS Server via the NAS in > question. This affects RADIUS Server behavior during any > Authorize Only > service provisioning. Who sets the policy the RADIUS server will enforce? i.e., how does the RADIUS server know which attributes contain security-sensitive information related to a user? > > In any of the use cases, it is important that the NAS, i.e. the RADIUS > Client, be able to communicate the kind of service being > sought via hint > attributes to the RADIUS Server, in the Access-Request message. This > has implications on the use of the Service-Type in Authorize Only > operations, in which it would otherwise be used as a hint of the > requested service, and not the request authentication method. > > It is also important that the RADIUS Server be able to specify the > provisioning of SNMPv3 over SSH service to the NAS in the > Access-Accept > message. > > Does this accurately summarize the consensus on this issue? > Especially > in terms of requirements that ISMS has of RADEXT? Please advise, with > suggestions for improvement. > > > _______________________________________________ > 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 Jul 26 22:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5vyA-00033w-TJ; Wed, 26 Jul 2006 22:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5vy9-00033r-H4 for isms@ietf.org; Wed, 26 Jul 2006 22:51:25 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5vy8-0001cz-7S for isms@ietf.org; Wed, 26 Jul 2006 22:51:25 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id AE5F011D390; Wed, 26 Jul 2006 19:51:20 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Subject: Re: [Isms] Summary of Authorize Only issue Organization: Sparta References: <064801c6b124$b66b4460$0400a8c0@china.huawei.com> Date: Wed, 26 Jul 2006 19:51:20 -0700 In-Reply-To: <064801c6b124$b66b4460$0400a8c0@china.huawei.com> (David Harrington's message of "Wed, 26 Jul 2006 22:31:05 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org, radiusext@ops.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 > > (c) Some other authentication mechanism/service > provides initial authentication (and no > authorization) of SNMPv3 over SSH. RADIUS > provides base-service authorization of > SNMPv3 over SSH (but no authentication). David> I'm not sure anybody has asked for this combination, but I suppose we David> don't need to rule it out. That's useful for ssh public-key authentication with RADIUS auto-authorization configuration. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 03:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60eN-0008WC-JI; Thu, 27 Jul 2006 03:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60eM-0008Sn-Ec for isms@ietf.org; Thu, 27 Jul 2006 03:51:18 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G60eK-0003la-0c for isms@ietf.org; Thu, 27 Jul 2006 03:51:18 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 04AAD4D454; Thu, 27 Jul 2006 09:51:15 +0200 (CEST) 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 29960-05; Thu, 27 Jul 2006 09:51:12 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 4E3414D578; Thu, 27 Jul 2006 09:50:13 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 942637A9C23; Thu, 27 Jul 2006 09:50:12 +0200 (CEST) Date: Thu, 27 Jul 2006 09:50:12 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] RE: Follow up on Authorize Only issue Message-ID: <20060727075012.GA27196@boskop.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <3CFB564E055A594B82C4FE89D2156560219392@MABOSEVS2.ets.enterasys.com> <20060726071317.GA6315@boskop.local> <004201c6b105$f7bdc600$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004201c6b105$f7bdc600$6501a8c0@oemcomputer> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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, Jul 26, 2006 at 03:51:00PM -0700, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Nelson, David" > > Cc: ; > > Sent: Wednesday, July 26, 2006 12:13 AM > > Subject: Re: [Isms] RE: Follow up on Authorize Only issue > ... > > I actually like to encourage people to write a document which explains > > how VACM can utilize RADIUS to provision the security name to group > > name mapping and to post such a document as an individual draft. But > > as explained above, this work can't become an official WG work item > > under the current charter. > ... > > Bottom line: without this out-of-charter work, whatever isms produces > will have, from a provisioning perspective, the same characteristics > as existing USM. Specifically, for each user, every box to which > that user is to have any access rights will need to be configured > before that user will be able to do anything with that box. The only > change from what we have today is that the number of configuration > PDUs will be somewhat smaller. True. And this is why this out-of-charter work is important and should be undertaken and kept in mind for a potential followup work item. But even without this completed in the first step, SNMP over SSH allows operators to use established key management procedures that are on many boxes already used to secure the access to the CLI and this by itself is a big plus we should not forget. /js -- Juergen Schoenwaelder International 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 Thu Jul 27 04:04:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60qe-0001JL-GR; Thu, 27 Jul 2006 04:04:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60qd-0001Gn-H9 for isms@ietf.org; Thu, 27 Jul 2006 04:03:59 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G60qc-00051p-2E for isms@ietf.org; Thu, 27 Jul 2006 04:03:59 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8F2D2395A8; Thu, 27 Jul 2006 10:03:57 +0200 (CEST) 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 31006-07; Thu, 27 Jul 2006 10:03:54 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id D12FD3956F; Thu, 27 Jul 2006 10:03:49 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id F2B597A9C58; Thu, 27 Jul 2006 10:03:47 +0200 (CEST) Date: Thu, 27 Jul 2006 10:03:47 +0200 From: Juergen Schoenwaelder To: "Nelson, David" Subject: Re: [Isms] Summary of Authorize Only issue Message-ID: <20060727080347.GB27196@boskop.local> Mail-Followup-To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org References: <3CFB564E055A594B82C4FE89D2156560219398@MABOSEVS2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219398@MABOSEVS2.ets.enterasys.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: isms@ietf.org, radiusext@ops.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, Jul 26, 2006 at 03:56:04PM -0400, Nelson, David wrote: > (2) There are two extended SNMP over SSH use cases: > > (a) RADIUS provides initial authentication and > authorization of SNMPv3 over SSH, base-service > authorization, and (optionally) granular access > control authorization. > > (b) Some other authentication mechanism/service > provides initial authentication (and no > authorization) of SNMPv3 over SSH. RADIUS > provides base-service authorization and > (optionally) granular access control > authorization. > > Note that "granular access control" means a mapping to the VACM or some > other Access Control Subsystem. > > These use cases are currently out of scope for the ISMS WG charter, but > might be added at a later date. Note that the reference "these use cases" is somewhat ambiguous. I assume you refer to (2a) and (2b). But even with this interpretation, it is only the optional part which is out of scope for the ISMS WG. Personally, I consider provisioning of SNMP access control mappings via RADIUS authorization a functionality which is totally independent of authentication and base-service authorization. So perhaps (2a) and (2b) should be combined into an SNMP access control provisioning use case: (2) There is an SNMP access control provisioning use case: RADIUS provides authorization information to be used by SNMP access control models, for example by providing a mapping of securityName to securityGroup, for use with the VACM. An example of such an attribute is Management-Policy-ID, conceptually similar to Filter-ID. Due to the strict separation of access control from authentication in the SNMP architecture, this requires that RADIUS provides an Authorize Only service for SNMP usage. /js -- Juergen Schoenwaelder International 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 Thu Jul 27 07:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G64OK-0003Xg-Qz; Thu, 27 Jul 2006 07:51:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G64OJ-0003Xa-IX for isms@ietf.org; Thu, 27 Jul 2006 07:50:59 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G64OI-000541-8S for isms@ietf.org; Thu, 27 Jul 2006 07:50:59 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 86AFB4D36A for ; Thu, 27 Jul 2006 13:50:57 +0200 (CEST) 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 16328-10; Thu, 27 Jul 2006 13:50:55 +0200 (CEST) Received: from boskop.local (unknown [10.50.243.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 3A3FC4D298; Thu, 27 Jul 2006 13:50:55 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id CE0BB7AA0E2; Thu, 27 Jul 2006 13:50:53 +0200 (CEST) Date: Thu, 27 Jul 2006 13:50:53 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060727115053.GA28253@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Isms] Conference call on notifications and call home 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 Hi, I am forwarding the conference call information just in case Juergen Quittek's email gets delayed again (has happened before): : Below please find the access parameters for the conference : call. I apologize for the late announcement. My original call : reservation failed for strange reasons. I had to take another : provider that unfortunately only offers a German dial-in : number: : : Tel.: +49 69 2711 0800 : code: 32784# : : The first greeting is in German (sorry) but followed by an English one. : We have made good experiences with participation via Skype Out. : : I have already started negotiating a contract with another conference : bridge provider. Follow-up conference calls will most probably be more : convenient. : : Thanks, : : Juergen Q. /js -- Juergen Schoenwaelder International 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 Thu Jul 27 08:41:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65BV-0003BP-36; Thu, 27 Jul 2006 08:41:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65BU-0003BK-7f for isms@ietf.org; Thu, 27 Jul 2006 08:41:48 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65BT-0003I7-0q for isms@ietf.org; Thu, 27 Jul 2006 08:41:48 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C6172E0079; Thu, 27 Jul 2006 08:42:25 -0400 (EDT) From: Sam Hartman To: Wes Hardaker Subject: Re: [Isms] snmpwalk, snmpget and notifications References: Date: Thu, 27 Jul 2006 08:42:25 -0400 In-Reply-To: (Wes Hardaker's message of "Wed, 26 Jul 2006 15:48:51 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 >>>>> "Wes" == Wes Hardaker writes: Wes> Actually, based on the way snmp clients are supposed to be Wes> built it based on the protocol specs it shouldn't be a Wes> problem anyway. Specifically, a snmp stack is already The client may well discard the message. The issue is that the message then doesn't get to the manager, which is bad. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 09:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66L7-0002le-Sx; Thu, 27 Jul 2006 09:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66L6-0002lZ-Fg for isms@ietf.org; Thu, 27 Jul 2006 09:55:48 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G66L5-0004iP-6g for isms@ietf.org; Thu, 27 Jul 2006 09:55:48 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id AF3F211D390; Thu, 27 Jul 2006 06:55:43 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Subject: Re: [Isms] Conference call on notifications and call home Organization: Sparta References: <20060727115053.GA28253@boskop.local> Date: Thu, 27 Jul 2006 06:55:43 -0700 In-Reply-To: <20060727115053.GA28253@boskop.local> (Juergen Schoenwaelder's message of "Thu, 27 Jul 2006 13:50:53 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 >>>>> On Thu, 27 Jul 2006 13:50:53 +0200, Juergen Schoenwaelder said: Juergen> : Tel.: +49 69 2711 0800 Juergen> : code: 32784# Maybe a jabber room and assigned scribe would be good? -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 11:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67Zl-0004w9-8q; Thu, 27 Jul 2006 11:15:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67Zk-0004w2-Dw for isms@ietf.org; Thu, 27 Jul 2006 11:15:00 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G67Zf-0007pj-3X for isms@ietf.org; Thu, 27 Jul 2006 11:15:00 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:14:53 -0400 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] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 11:14:53 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021939B@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Summary of Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/AAAsddQAAmTqxA From: "Nelson, David" To: , X-OriginalArrivalTime: 27 Jul 2006 15:14:53.0900 (UTC) FILETIME=[69BBE8C0:01C6B18F] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Dave Harrington writes... > I think "SNMP over SSH" would be appropriate. I do not see a reason to > limit it to SNMPv3. That's fine by me, if that's the consensus. In the past, I've been encouraged to omit support for v1 and v2c in I-Ds, as those versions have been deprecated. The comment was from Bert Wijnen, in relation to protocol selection attributes I'd included for v1 and v2c in the NAS-Management draft. > > > > (b) Some other authentication mechanism/service > > provides initial authentication (and no > > authorization) of SNMPv3 over SSH. >=20 > Whether the other services provides authorization or not is > immaterial. Perhaps immaterial to RADIUS requirements, per se, but certainly not immaterial to the security considerations for SNMP over SSH as a whole. > > (c) Some other authentication mechanism/service > > provides initial authentication (and no > > authorization) of SNMPv3 over SSH. RADIUS > > provides base-service authorization of > > SNMPv3 over SSH (but no authentication). >=20 > I'm not sure anybody has asked for this combination, but I suppose we > don't need to rule it out. Included for completeness. Wes H. has indicated, in a separate post, that this might be useful. > I would like to make sure everybody understands that the NAS is the > managed device, not only edge devices providing network access > services; Every SNMP-manageable device in the network might be > considered a NAS in this scenario. Yes. In "RADIUS-speak", the terms "NAS" and "RADIUS Client" are often used interchangeably. In this use case, it would probably be desirable to favor the term "RADIUS Client", for added clarity. > Educate me. Why primarily the password authentication? Because this is the RADIUS authentication method most commonly used for SSH deployments today, I believe. > Does this imply a (plaintext) password? Yes, although RADIUS encrypts that password on the wire, on a hop-by-hop basis, using the shared secret. > Other authentication mechanisms might be preferable to passwords; > I assume RADIUS supports a wide range of authentication mechanisms. No, it does not. The existing RADIUS authentication methods are: -- password -- textual challenge / response -- CHAP (MD5 Digest) -- EAP (basically any EAP method) -- HTTP Digest (newly added) We already know that EAP is not permissible for use with network management authentication, because of its narrow applicability statement. Practically speaking, that leaves us with password and CHAP. I believe most of the current SSH usage of RADIUS for network management uses password. > I think there are three extended SNMP use cases that involve RADIUS =20 > (c) RADIUS does not perform authentication or > base-service authorization. > Some other authentication mechanism/service > provides initial authentication and presumably > base service authorization for SNMP over whatever > secure transport, such as SNMP using USM over UDP, > or SNMP using USM and TCP/IPv6, or SNMP using Kerberos > and SCTP, or SNMP using 802.1AE and Ethernet. > The access control subsystem requests from RADIUS > ONLY the granular access control authorization > associated with the otherwise-authenticated user. > (e.g., hey RADIUS, which group is this guy in?) Juergen S., in a separate post, suggests that the two be collapsed into one. I'll ponder this a bit and propose something that attempts to address both suggestions. =20 > Who sets the policy the RADIUS server will enforce? The system administrator. > i.e., how does the RADIUS server know which attributes contain > security-sensitive information related to a user? That is an implementation detail of the RADIUS Server, and not an on-the-wire protocol issue. I suggest that the document include implementation guidance on this issue, perhaps in the security considerations section, and that the protocol be designed so as to provide sufficient information for an implementation to be capable of accomplishing this goal. It would certainly be possible to make a (non-exhaustive) list of sensitive attributes, much as we make a list of sensitive objects in the security considerations section of MIBs. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 11:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67o3-0008WS-0G; Thu, 27 Jul 2006 11:29:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67o2-0008WI-6G for isms@ietf.org; Thu, 27 Jul 2006 11:29:46 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G67o0-0004LB-TU for isms@ietf.org; Thu, 27 Jul 2006 11:29:46 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6RFOv25031510 for ; Thu, 27 Jul 2006 11:24:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 18:29:42 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Summary of Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/AAAsddQAAmTqxAAAG/iNA= From: "Romascanu, Dan \(Dan\)" To: "Nelson, David" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 =20 =20 > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com]=20 > Sent: Thursday, July 27, 2006 6:15 PM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: [Isms] Summary of Authorize Only issue >=20 > Dave Harrington writes... >=20 > > I think "SNMP over SSH" would be appropriate. I do not see=20 > a reason to=20 > > limit it to SNMPv3. >=20 > That's fine by me, if that's the consensus. In the past,=20 > I've been encouraged to omit support for v1 and v2c in I-Ds,=20 > as those versions have been deprecated. The comment was from=20 > Bert Wijnen, in relation to protocol selection attributes I'd=20 > included for v1 and v2c in the NAS-Management draft. >=20 I believe that that recommendation was correct and continues to stand. The name does not bother me too much, as SNMPv3 is the only standard version of SNMP but defining special attributes or features for v1 and v2c should need some strong argumentation.=20 Dan _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 12:07:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68Oy-0001gD-7r; Thu, 27 Jul 2006 12:07:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68Ox-0001g5-Rd for isms@ietf.org; Thu, 27 Jul 2006 12:07:55 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G68Ov-0003fp-FN for isms@ietf.org; Thu, 27 Jul 2006 12:07:55 -0400 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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Thu, 27 Jul 2006 12:08:16 -0400 Message-ID: In-Reply-To: <44C87454.9020007@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcaxU+p7BvrYxGjrRsuTecazVZeRSwAQsGuw From: "Avi Lior" To: "Hannes Tschofenig" X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: radiusext@ops.ietf.org, 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 I know, but AAA and Liberty Alliance perform different functions and probably have different performance requirements. But you are probably right. My developers will have to cave one day. The question is, will they kill me first or will I manage to survive.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, July 27, 2006 4:08 AM > To: Avi Lior > Cc: Glen Zorn (gwz); David Harrington; Eliot Lear;=20 > isms@ietf.org; radiusext@ops.ietf.org > Subject: Re: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Hi Avi, >=20 > your developers might need to get used to XML sooner or later=20 > anyway based on the excitement for Liberty Alliance nowadays.=20 > The functionality of the asserting party in SAML is very=20 > close to what a AA(A) does today. >=20 > Ciao > Hannes >=20 > Avi Lior wrote: > > Hi Hannes, > >=20 > > When I wrote the word "assertion" I was thinking a SAML assertion. > >=20 > > A word of caution though, everytime I mention XML to my AAA=20 > developers=20 > > they conspire to kill me. > >=20 > > XML, parsing strings etc are performance killers for a AAA server. > >=20 > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: Wednesday, July 26, 2006 4:55 AM > >>To: Avi Lior > >>Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; isms@ietf.org;=20 > >>radiusext@ops.ietf.org > >>Subject: Re: Follow up on Authorize Only issue (was RE:=20 > >>[Isms] ISMS session > >> > >>Hi Avi, > >> > >>I like the idea of using some information to tie the authentication=20 > >>and the authorization process/exchange together. In fact we=20 > discussed=20 > >>this at the last IETF meeting when David gave his presentation. > >> > >>I suggested to use an existing mechanism to accomplish this=20 > binding,=20 > >>namely SAML. I can elaborate a bit more about the details=20 > if someone=20 > >>case about it. > >> > >>Ciao > >>Hannes > >> > >>Avi Lior wrote: > >> > >>>I proably did not make myself clear....or maybe I did and I > >> > >>am missing > >> > >>>something. > >>> > >>>When the NAS sends the Access-Request Auth-Only message I > >> > >>agree that > >> > >>>it MUST contain Message-Authenticator(80) etc... > >>> > >>>What I meant is that it would be nice if there was a token or an=20 > >>>assertion that came from the place that did authenticate > >> > >>the user to > >> > >>>indicate in a cryptographic way that this user was authenticated. > >>> > >>>The AAA server can use that token to verify that the user was=20 > >>>authenticated by an entity that it trusts. Like a=20 > kerberose ticket. > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > >>>>Sent: Tuesday, July 25, 2006 3:47 PM > >>>>To: Avi Lior; David Harrington; Eliot Lear > >>>>Cc: isms@ietf.org; radiusext@ops.ietf.org > >>>>Subject: RE: Follow up on Authorize Only issue (was RE:=20 > >>>>[Isms] ISMS session > >>>> > >>>>Avi Lior supposedly scribbled: > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>If I was specifying how this is done: > >>>>> > >>>>>It would be nice if the AAA client could return some sort > >>>> > >>>>of token to > >>>> > >>>> > >>>>>the AAA server to assert that the user has been > >> > >>authenticated by an > >> > >>>>>entity that it trusts. The token can be generated by the > >>>>>Authentication Server. =20 > >>>>> > >>>>>We need this assertion to make sure we deliver the=20 > correct profile. > >>>> > >>>>I disagree: the fact that the message is being sent by an=20 > >>>>authenticated client at all says that the user has been > >> > >>authenticated > >> > >>>>elsewhere. Note that safety requires the inclusion of a > >> > >>MAC (either > >> > >>>>the Message-Authenticator or preferably the=20 > >>>>Message-Authentication-Code Attribute) in the Access-Request. > >>>> > >>>>Hope this helps, > >>>> > >>>>~gwz > >>>> > >>>>Why is it that most of the world's problems can't be solved > >> > >>by simply > >> > >>>> listening to John Coltrane? -- Henry Gabriel > >>>> > >>> > >>> > >>>-- > >>>to unsubscribe send a message to > >> > >>radiusext-request@ops.ietf.org with > >> > >>>the word 'unsubscribe' in a single line as the message text body. > >>>archive: > >>> > >>> > >> > >=20 > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 > >=20 >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 12:13:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68UQ-0004q1-3Q; Thu, 27 Jul 2006 12:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68UO-0004oT-J9 for isms@ietf.org; Thu, 27 Jul 2006 12:13:32 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G68UL-00050u-BS for isms@ietf.org; Thu, 27 Jul 2006 12:13:32 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6RGDNCf011442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jul 2006 12:13:23 -0400 (EDT) Date: Thu, 27 Jul 2006 12:13:23 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] Summary of Authorize Only issue Message-ID: In-Reply-To: <3CFB564E055A594B82C4FE89D215656021939B@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D215656021939B@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01ObfIkaMfPQWFAkASbDX4ANAp/7zA60GmLPb2bzc=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Jeffrey Hutzelman 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 On Thursday, July 27, 2006 11:14:53 AM -0400 "Nelson, David" wrote: >> Other authentication mechanisms might be preferable to passwords; >> I assume RADIUS supports a wide range of authentication mechanisms. > > No, it does not. The existing RADIUS authentication methods are: > > -- password > -- textual challenge / response > -- CHAP (MD5 Digest) > -- EAP (basically any EAP method) > -- HTTP Digest (newly added) > > We already know that EAP is not permissible for use with network > management authentication, because of its narrow applicability > statement. > > Practically speaking, that leaves us with password and CHAP. I believe > most of the current SSH usage of RADIUS for network management uses > password. In fact, of the mechanisms you list, only the first two are defined for SSH (as are quite a few that are not listed here). -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 12:30:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68kn-0002Rk-5r; Thu, 27 Jul 2006 12:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68kl-0002Rf-7s for isms@ietf.org; Thu, 27 Jul 2006 12:30:28 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G68kj-0006KZ-W1 for isms@ietf.org; Thu, 27 Jul 2006 12:30:27 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc12) with SMTP id <2006072716302501200si00ke>; Thu, 27 Jul 2006 16:30:25 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Nelson, David'" , , Subject: RE: [Isms] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 12:29:03 -0400 Message-ID: <002c01c6b199$c5f2e3a0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/AAAsddQAAmTqxAAAG/iNAAAGEboA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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, I did not say it should support SNMPv1 or SNMPv2. We separated the security and transport mappings from the message format in the RFC3411 architecture; SNMPv3 refers to a message format. Please do not bind these concepts unnecessarily in your RADIUS proposal. There is growing desire to share designs across IETF NM protocols, and I can envision an SNMPv4 message processing model that uses an XML message encoding to improve compatibility with netconf and with data models from other SDOs. Why should RADIUS care which message format or which encoding is used for the on-the-wire SNMP message? Will it impact whether SSH is told it is OK to establish the "snmp" subsystem? I do not see a technical engineering reason to limit the RADIUS authorization to SNMPv3 over SSH, as compared to SNMP over SSH. Dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, July 27, 2006 11:30 AM > To: Nelson, David; isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: [Isms] Summary of Authorize Only issue > > > > > > > > -----Original Message----- > > From: Nelson, David [mailto:dnelson@enterasys.com] > > Sent: Thursday, July 27, 2006 6:15 PM > > To: isms@ietf.org; radiusext@ops.ietf.org > > Subject: RE: [Isms] Summary of Authorize Only issue > > > > Dave Harrington writes... > > > > > I think "SNMP over SSH" would be appropriate. I do not see > > a reason to > > > limit it to SNMPv3. > > > > That's fine by me, if that's the consensus. In the past, > > I've been encouraged to omit support for v1 and v2c in I-Ds, > > as those versions have been deprecated. The comment was from > > Bert Wijnen, in relation to protocol selection attributes I'd > > included for v1 and v2c in the NAS-Management draft. > > > > I believe that that recommendation was correct and continues to stand. > The name does not bother me too much, as SNMPv3 is the only standard > version of SNMP but defining special attributes or features for v1 and > v2c should need some strong argumentation. > > Dan > > > _______________________________________________ > 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 Jul 27 13:00:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69DZ-0007JK-FQ; Thu, 27 Jul 2006 13:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69DY-0007JB-Dc for isms@ietf.org; Thu, 27 Jul 2006 13:00:12 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G69DS-0000A0-4p for isms@ietf.org; Thu, 27 Jul 2006 13:00:12 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 13:00:05 -0400 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] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 13:00:04 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021939D@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Summary of Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/AAAsddQAAmTqxAAAG/iN AAAGEboAACrY7Q From: "Nelson, David" To: , X-OriginalArrivalTime: 27 Jul 2006 17:00:05.0023 (UTC) FILETIME=[1B74DAF0:01C6B19E] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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... > We separated the security and transport mappings from the message > format in the RFC3411 architecture; SNMPv3 refers to a message format. It also implies the only version with any real security. > Please do not bind these concepts unnecessarily in your RADIUS > proposal. I think we can simplify the naming, as Dan suggests, and refer to SNMP over SSH. We can add a statement in the security considerations section that strongly recommends use only with SNMP versions that have real security, i.e. v3 (and higher). > I can envision an SNMPv4 message processing model that uses an XML > message encoding to improve compatibility with netconf and with data > models from other SDOs. Good luck with that! :-) =20 > I do not see a technical engineering reason to limit the RADIUS > authorization to SNMPv3 over SSH, as compared to SNMP over SSH. Right, but I think it might be fodder for the security considerations section. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 13:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69Q8-0000ga-7j; Thu, 27 Jul 2006 13:13:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69Q7-0000gO-8s for isms@ietf.org; Thu, 27 Jul 2006 13:13:11 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G69Q5-0001LK-Rv for isms@ietf.org; Thu, 27 Jul 2006 13:13:11 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k6RHD5C9013491; Thu, 27 Jul 2006 10:13:05 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k6RHD5mr013484; Thu, 27 Jul 2006 10:13:05 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 27 Jul 2006 10:13:04 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: David Harrington Subject: RE: [Isms] Summary of Authorize Only issue In-Reply-To: <002c01c6b199$c5f2e3a0$0400a8c0@china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: radiusext@ops.ietf.org, 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, It looks like David Harrington (DBH) is trying to be funny below. There is one "real" issue. That is the confusion of using 1) SSH for a VPN with port redirect with 2) SNMPv3/ISMS-SSH. For #1 (a VPN), this is outside the scope of this WG discussion. However, the docs need to be clear that SNMPv3/ISMS-SSH is not #1. On Thu, 27 Jul 2006, David Harrington wrote: > Hi, > > I did not say it should support SNMPv1 or SNMPv2. > > We separated the security and transport mappings from the message > format in the RFC3411 architecture; SNMPv3 refers to a message format. > Please do not bind these concepts unnecessarily in your RADIUS > proposal. Yes, the SNMPv3 Protocol definition is a message format. SNMPv3 is also a framework that includes the SNMPv1 and SNMPv2c protocols. Yes, this is somewhat confusing. > There is growing desire to share designs across IETF NM protocols, and > I can envision an SNMPv4 message processing model that uses an XML > message encoding to improve compatibility with netconf and with data > models from other SDOs. I'm assuming that DBH is trying out ideas here for an April 1 RFC. > Why should RADIUS care which message format or > which encoding is used for the on-the-wire SNMP message? Will it > impact whether SSH is told it is OK to establish the "snmp" subsystem? > > I do not see a technical engineering reason to limit the RADIUS > authorization to SNMPv3 over SSH, as compared to SNMP over SSH. Since using RADIUS for setting up #1 is outside the scope, I don't see why it is relevant? > > Dbh > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Thursday, July 27, 2006 11:30 AM > > To: Nelson, David; isms@ietf.org; radiusext@ops.ietf.org > > Subject: RE: [Isms] Summary of Authorize Only issue > > > > > -----Original Message----- > > > From: Nelson, David [mailto:dnelson@enterasys.com] > > > Sent: Thursday, July 27, 2006 6:15 PM > > > To: isms@ietf.org; radiusext@ops.ietf.org > > > Subject: RE: [Isms] Summary of Authorize Only issue > > > > > > Dave Harrington writes... > > > > > > > I think "SNMP over SSH" would be appropriate. I do not see > > > a reason to > > > > limit it to SNMPv3. > > > > > > That's fine by me, if that's the consensus. In the past, > > > I've been encouraged to omit support for v1 and v2c in I-Ds, > > > as those versions have been deprecated. The comment was from > > > Bert Wijnen, in relation to protocol selection attributes I'd > > > included for v1 and v2c in the NAS-Management draft. > > > > > > > I believe that that recommendation was correct and continues to > stand. > > The name does not bother me too much, as SNMPv3 is the only standard > > version of SNMP but defining special attributes or features for v1 > and > > v2c should need some strong argumentation. > > > > Dan > > > > > > _______________________________________________ > > 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 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 13:47:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69xV-0003n3-Jj; Thu, 27 Jul 2006 13:47:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69xU-0003my-97 for isms@ietf.org; Thu, 27 Jul 2006 13:47:40 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G69xS-0004fv-2E for isms@ietf.org; Thu, 27 Jul 2006 13:47:40 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc13) with SMTP id <2006072717473501300a7mope>; Thu, 27 Jul 2006 17:47:35 +0000 From: "David Harrington" To: "'David T. Perkins'" Subject: RE: [Isms] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 13:46:12 -0400 Message-ID: <003901c6b1a4$8d8a93e0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaxn+2NGdRrLA63QKqZnE5AwslvwAAA41yA X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: radiusext@ops.ietf.org, 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, I'm not sure how a SSH-VPN is configured, i.e. whether it uses a subsystem to carry snmp. If we changed "SNMP over SSH" to "SSH snmp subsystem", would that be clear? That is the service we are requesting. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 14:11:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AKG-0006UR-Ao; Thu, 27 Jul 2006 14:11:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AKE-0006UM-Kd for isms@ietf.org; Thu, 27 Jul 2006 14:11:10 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AK9-0007IH-Cm for isms@ietf.org; Thu, 27 Jul 2006 14:11:10 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 14:11:04 -0400 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] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 14:11:04 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193A2@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Summary of Authorize Only issue Thread-Index: Acaxn+2NGdRrLA63QKqZnE5AwslvwAAA41yAAABcZAA= From: "Nelson, David" To: X-OriginalArrivalTime: 27 Jul 2006 18:11:04.0734 (UTC) FILETIME=[06712BE0:01C6B1A8] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 (Dropping RADEXT from the distribution.) Dave Harrington writes... > I'm not sure how a SSH-VPN is configured, i.e. whether > it uses a subsystem to carry snmp. In response to a comment from Dave Perkins... > There is one "real" issue. That is the confusion of=20 > using 1) SSH for a VPN with port redirect with=20 > 2) SNMPv3/ISMS-SSH. For #1 (a VPN), this is outside the=20 > scope of this WG discussion. However, the docs need to=20 > be clear that SNMPv3/ISMS-SSH is not #1. I'm not sure what VPNs have to do with the work of ISMS. I understand that VPNs are a form of encrypted tunnel, and one could characterize the protected transport service that SSH provides fro various application protocols as an encrypted tunnel. Still, there is a lot of added functionality entailed in VPNs that is not needed (or specified) for SNMP over SSH. Is all this a red herring? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 15:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B65-0008OT-Ps; Thu, 27 Jul 2006 15:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B64-0008HU-QS for isms@ietf.org; Thu, 27 Jul 2006 15:00:36 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6B63-0003qq-IN for isms@ietf.org; Thu, 27 Jul 2006 15:00:36 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc14) with SMTP id <2006072719003501400cg28ce>; Thu, 27 Jul 2006 19:00:35 +0000 From: "David Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 14:59:12 -0400 Message-ID: <004501c6b1ae$c015ae30$0400a8c0@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: <3CFB564E055A594B82C4FE89D21565602193A2@MABOSEVS2.ets.enterasys.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaxn+2NGdRrLA63QKqZnE5AwslvwAAA41yAAABcZAAAAdoycA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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, David said and David responded and David asked ... Hmmm. It is not a red herring. DP simply pointed out that some people already use an "SNMP over SSH" solution, using SSH with a port-redirect approach. This is sometimes referred to as an SSH "VPN". DP asked that we use terminology that unambiguously refers to the service ISMS is working on, and not the other "VPN"-style of "SNMP over SSH" service. The SSHSM draft requests an "snmp" subsystem from SSH, so I suggest we use "SSH snmp subsystem" in the RADIUS attribute for the base-authorization. Dbh > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Thursday, July 27, 2006 2:11 PM > To: isms@ietf.org > Subject: RE: [Isms] Summary of Authorize Only issue > > (Dropping RADEXT from the distribution.) > > Dave Harrington writes... > > > I'm not sure how a SSH-VPN is configured, i.e. whether > > it uses a subsystem to carry snmp. > > In response to a comment from Dave Perkins... > > > There is one "real" issue. That is the confusion of > > using 1) SSH for a VPN with port redirect with > > 2) SNMPv3/ISMS-SSH. For #1 (a VPN), this is outside the > > scope of this WG discussion. However, the docs need to > > be clear that SNMPv3/ISMS-SSH is not #1. > > I'm not sure what VPNs have to do with the work of ISMS. I understand > that VPNs are a form of encrypted tunnel, and one could > characterize the > protected transport service that SSH provides fro various application > protocols as an encrypted tunnel. Still, there is a lot of added > functionality entailed in VPNs that is not needed (or specified) for > SNMP over SSH. > > Is all this a red herring? > > > _______________________________________________ > 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 Jul 27 15:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B6u-00014p-6h; Thu, 27 Jul 2006 15:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B6t-00014k-76 for isms@ietf.org; Thu, 27 Jul 2006 15:01:27 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6B6n-0003vV-Uh for isms@ietf.org; Thu, 27 Jul 2006 15:01:27 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 15:01:21 -0400 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] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 15:01:20 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193A5@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Summary of Authorize Only issue Thread-Index: Acaxrne+4Pd1Cjh7QOms/8YaMiOjrwAACYRw From: "Nelson, David" To: X-OriginalArrivalTime: 27 Jul 2006 19:01:21.0272 (UTC) FILETIME=[0C705780:01C6B1AF] X-imss-version: 2.041 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Jeffrey Hutzelman writes... =20 > The word "VPN" might be. The point David is trying to get at is that > there's a difference between SNMPv3 with SSHSM, and SNMPv3 with USM over > TCP tunnelled through an SSH port forwarder, but both can be described as > "SNMP over SSH". Ah. Point well taken. > The solution to this is that we call the thing "SNMP over SSH (RFCxxxx)". Right. The "branding" issue. :-) Maybe "SNMP via SSH Transport Mapping Method"? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jul 27 16:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Cq7-0004kq-H9; Thu, 27 Jul 2006 16:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Cq5-0004kh-K6 for isms@ietf.org; Thu, 27 Jul 2006 16:52:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BIL-0005nJ-Cz for isms@ietf.org; Thu, 27 Jul 2006 15:13:17 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G6B2m-000256-Qz for isms@ietf.org; Thu, 27 Jul 2006 14:57:13 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6RIv6OL017627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jul 2006 14:57:06 -0400 (EDT) Date: Thu, 27 Jul 2006 14:57:06 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] Summary of Authorize Only issue Message-ID: <8A83DC6EA5A9D86C83725DDB@sirius.fac.cs.cmu.edu> In-Reply-To: <3CFB564E055A594B82C4FE89D21565602193A2@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D21565602193A2@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:013PxeIkZk05YoR9ajD3qOkXNulU1jMNdJcYyHEnw=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Jeffrey Hutzelman 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 On Thursday, July 27, 2006 02:11:04 PM -0400 "Nelson, David" wrote: > (Dropping RADEXT from the distribution.) > > Dave Harrington writes... > >> I'm not sure how a SSH-VPN is configured, i.e. whether >> it uses a subsystem to carry snmp. > > In response to a comment from Dave Perkins... > >> There is one "real" issue. That is the confusion of >> using 1) SSH for a VPN with port redirect with >> 2) SNMPv3/ISMS-SSH. For #1 (a VPN), this is outside the >> scope of this WG discussion. However, the docs need to >> be clear that SNMPv3/ISMS-SSH is not #1. > > I'm not sure what VPNs have to do with the work of ISMS. I understand > that VPNs are a form of encrypted tunnel, and one could characterize the > protected transport service that SSH provides fro various application > protocols as an encrypted tunnel. Still, there is a lot of added > functionality entailed in VPNs that is not needed (or specified) for > SNMP over SSH. > > Is all this a red herring? The word "VPN" might be. The point David is trying to get at is that there's a difference between SNMPv3 with SSHSM, and SNMPv3 with USM over TCP tunnelled through an SSH port forwarder, but both can be described as "SNMP over SSH". The solution to this is that we call the thing "SNMP over SSH (RFCxxxx)". -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jul 28 16:52:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ZJS-0002UH-6f; Fri, 28 Jul 2006 16:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ZJQ-0002UB-Bi for isms@ietf.org; Fri, 28 Jul 2006 16:52:00 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6ZJN-0008MU-Ou for isms@ietf.org; Fri, 28 Jul 2006 16:52:00 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D49E055D19 for ; Fri, 28 Jul 2006 22:51:56 +0200 (CEST) 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 04570-04; Fri, 28 Jul 2006 22:51:53 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 4445055D2E; Fri, 28 Jul 2006 22:51:51 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 8B4F97AB4A2; Fri, 28 Jul 2006 22:51:49 +0200 (CEST) Date: Fri, 28 Jul 2006 22:51:49 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060728205149.GA1697@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Subject: [Isms] isms conference call minutes 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 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are minutes from the conference call yesterday. I tried to organize the various statements I could track into a hopefully more meaningful structure. Personally, I have the feeling that we have a list of evaluation criteria and none of the proposals on the table seems to address them all or be a clear winner. For some of the proposals, the details are not really understood well enough to actually evaluate them. So more work is needed to flesh out the details of at least some of the proposals. I will be offline the coming two weeks - so please report any issues with the minutes to Juergen Quittek or simply the mailing list. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-call-notes.txt" Minutes of the ISMS conference call on July 27 14:00-15:00 UTC Participants: Wes Hardaker David Harrington Sam Hartmann Jeff Hutzelman Eliot Lear David Perkins Juergen Quittek Dan Romascanu Juergen Schoenwaelder Bert Wijnen Agenda: 1. Agenda bashing 2. Call Home for SSH Main subject will be agent initiated channels for notifications. Juergen S. raised this issue in our last session. Please find his slides at The main question to be answered is: "Is the reverse creation of an SSH session as suggested in the slides an acceptable solution for ISMS notifications? 3. Alternative approaches If call home for SSH does not work, alternatives need to be discussed. Wes listed three of them in his email from July 17: . We will have as look at all three and try to identify pros and cons for each of them. 4. Summary of technical results Approaches: Short summary of the alternatives on the table: (1) ssh connection initiated by the NO (agent), authentication using user credentials provisioned on the agent (2) ssh connection initiated by the NO (agent), authentication using host keys (readily available on the agent) (3) ssh connection initiated by the NR (manager), authentication using normal user credentials (no credentials needs to be provisioned) A perhaps impossible but interesing solution would be: (4) ssh connection initiated by the NO (agent), authentication using normal user credentials from the NR side (no credentials needs to be provisioned) Another solution discussed (but not really liked): (5) Out-of-band signaling to the NR to initiate a ssh connection, authentication using normal user credentials from the NR side (no credentials needs to be provisioned) General Clarifications: - Once an SNMP engine sends a notification, it pretty much knows the targets. Access control then filters based on the identity of the receiver on the targets. - SNMP always forces access control on outgoing notifications, even if you implement SNMPv1/SNMPv2c according to the RFC 3411 architecture. (Of course, there are implementations out there which don't do this.) Evaluation Criteria: - Which credentials needs to be provisioned where? - What needs to be configured to make the notification target selection mechanism do the right thing? - Which user identity is used for access control? - How do notifications get delivered when there is no existing connection? - How do things work with short-lived notification orignators? - What specifically needs to be known where in the Elements of Procedure to make it work? Specific Comments: - Approach (5) sounds fragile. Not only does it allow easy DoS attacks, it also allows attackers to fool managers to connect to devices they should not connect to. - Approach (5) also has NAT traversal problems - the manager might not be able to connect back to the agent. - Approach (3) requires to be able to point to existing sessions in the target table. This either requires a wildcard transport address type (where for example the port number is not relevant) or table entries must be generated dynamically when sessions are established which may carry notifications. Some concerns were raised about adding targets automatically. The phone was closed at 15:00 UTC. I was agreed that the approaches need to be worked out in more details. Once we have more details, we might be able to evaluate them using criteria (an initial list was created during the call). It might be the case that no proposal addresses all criterias and we have to make a trade-off decision. --bg08WKrSYDhXBjb5 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 --bg08WKrSYDhXBjb5-- From isms-bounces@lists.ietf.org Sat Jul 29 20:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6zVn-0005Kj-QY; Sat, 29 Jul 2006 20:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6zVm-0005Ke-Tb for isms@ietf.org; Sat, 29 Jul 2006 20:50:30 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6zVl-0004YE-JC for isms@ietf.org; Sat, 29 Jul 2006 20:50:30 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BBB74E00C1; Sat, 29 Jul 2006 20:51:06 -0400 (EDT) From: Sam Hartman To: isms@ietf.org Date: Sat, 29 Jul 2006 20:51:06 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Subject: [Isms] [Sam Hartman] Formal consultation prior to closing the secsh working group 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 don't think the secsh working group closing will impact ISMS but it is at least something you should be aware of. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Sat, 29 Jul 2006 20:29:16 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by suchdamage.org (Postfix) with ESMTP id C526513172 for ; Sat, 29 Jul 2006 20:29:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1CBD263B319; Sun, 30 Jul 2006 00:29:08 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 3627763B318 for ; Sun, 30 Jul 2006 00:29:07 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BAD89E00C1; Sat, 29 Jul 2006 19:15:10 -0400 (EDT) From: Sam Hartman To: ietf-ssh@netbsd.org Cc: housley@vigilsec.com Subject: Formal consultation prior to closing the secsh working group Date: Sat, 29 Jul 2006 19:15:10 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.0.2 MIME-Version: 1.0 Hi folks. The ssh working group has accomplished its primary objective and has published the core protocol as RFCs. We've also published several related extensions. We have not managed to publish the filexfer, URI or X.509 drafts. However, I've come to the conclusion that there is insufficient energy in this working group to continue reviewing or producing documents. All of our milestones are from 2005. There seems to be no significant activity on anything other than the filexfer draft. I'm very concerned about the filexfer draft. It is well on the way to becoming a filesystem, not just an ftp-like protocol. I am concerned that we don't have enough reviewers to manage the complexity of the draft and to force us to make hard decisions about what features we really need. Instead, we're close to including everything. I have received several private comments to this effect. I am not sure that we have the skill set necessary to design and review a filesystem document and I think that is what filexfer is becoming. RFC 2418 defines procedures for creating, managing and terminating of working groups. That document stresses the importance of an active community of reviewers and subject matter experts. IT makes it clear that it is the responsibility of the working group to make sure the right people are available to do the work of the WG. I no longer think this working group has sufficient reviewers or contributors. So, I propose to close the working group. RFC 2418 requires a formal consultation prior to closing a working group. This message serves as the beginning of such a consultation. I'd like to solicit comments on the proposal to close the secsh working group by August 14, 2006. Thanks, Sam Hartman Security Area Director --=-=-= 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 --=-=-=--