From randy_presuhn@mindspring.com Wed Jun 2 11:40:45 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D57428C0F1 for ; Wed, 2 Jun 2010 11:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKrdU13M3wJD for ; Wed, 2 Jun 2010 11:40:42 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 9F8AF3A6A2B for ; Wed, 2 Jun 2010 11:40:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lKDdd+ledZm+eUXPKr7fFnEcA44vebRJN/vlZZL89IbomdVokFB7pcayE/4i67qt; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.147.130] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OJsrd-0007fR-Qh for isms@ietf.org; Wed, 02 Jun 2010 14:40:30 -0400 Message-ID: <000c01cb0283$336c54a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100515100842.GB215@elstar.local> <001801cafd3f$c2814860$6801a8c0@oemcomputer> <20100527061747.GB5882@elstar.local> <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> <20100528055631.GA8690@elstar.local> <01b701cafe8b$461b1650$dfb611ac@china.huawei.com> Date: Wed, 2 Jun 2010 11:41: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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035b35f0a4aad556902375066f90a6d3ae4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.147.130 Subject: Re: [Isms] last call to check the changes of the radius / vacm document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 18:40:45 -0000 Hi - As a technical contributor, I agree with David Harrington that I think the document could be clearer, and that it drags in stuff that there really is no need to talk about. I think it would benefit from radical simplification. Aside: As someone who has spent far too much time with the SNMPv3 specifications and implementations, I would like to remind folks that there is nothing sacred about the ASIs. They were introduced to help modularize those SPECIFICATIONS, and do NOT require implementations to be structured in the same way. Lacking specific text proposals, I'm going to take a stab at what I think David Harrington is requesting be done to the RADIUS/VACM document. Since this will be a *lot* of textual change (without any change to the actual implementation implications) I propose that as editor I should bundle up the changes into an individual I-D so folks can see whether the result is a step in the right direction. Ok? I hate introducing a lot of textual changes at this stage of the process, but I don't see any other reasonable way of addressing the comments. Randy From dnelson@elbrys.com Wed Jun 2 12:49:09 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1AE23A6A47 for ; Wed, 2 Jun 2010 12:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW3lPdgGEXKd for ; Wed, 2 Jun 2010 12:49:08 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id 119B53A6A43 for ; Wed, 2 Jun 2010 12:49:07 -0700 (PDT) Received: from source ([209.85.212.180]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTAa1p3VlGLLiZ8dESnLXibCbKbXINwxZ@postini.com; Wed, 02 Jun 2010 12:48:55 PDT Received: by mail-px0-f180.google.com with SMTP id 17so3576005pxi.11 for ; Wed, 02 Jun 2010 12:48:55 -0700 (PDT) Received: by 10.142.67.35 with SMTP id p35mr5434398wfa.203.1275508134791; Wed, 02 Jun 2010 12:48:54 -0700 (PDT) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id y15sm2386848wfd.10.2010.06.02.12.48.53 (version=SSLv3 cipher=RC4-MD5); Wed, 02 Jun 2010 12:48:54 -0700 (PDT) From: "David B. Nelson" To: "Randy Presuhn" In-Reply-To: <000c01cb0283$336c54a0$6801a8c0@oemcomputer> X-Priority: 3 References: <20100515100842.GB215@elstar.local> <001801cafd3f$c2814860$6801a8c0@oemcomputer> <20100527061747.GB5882@elstar.local> <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> <20100528055631.GA8690@elstar.local> <01b701cafe8b$461b1650$dfb611ac@china.huawei.com> <000c01cb0283$336c54a0$6801a8c0@oemcomputer> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Jun 2010 15:48:50 -0400 X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] last call to check the changes of the radius / vacm document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 19:49:09 -0000 On Jun 2, 2010, at 2:41 PM, Randy Presuhn wrote: > As a technical contributor, I agree with David Harrington that I think > the document could be clearer, and that it drags in stuff that there > really is no need to talk about. I think it would benefit from > radical > simplification. I think Einstein was reputed to have said "Everything should be made as simple as possible, but no simpler.", or something to that effect. I'm all for removing inappropriate material and model-instance- specific dependencies. The tricky part, I think, will be in correctly and completely generalizing the properties of security and transport models that the RADIUS/VACM work relies upon. I haven't had time to review the current draft in light of Dave's issues, but I know that the WG spent a lot of time discussing how RADIUS-provisioned information, e.g. authenticated principal identity and data access control policy, are communicated from the RADIUS client in the managed entity to the various places they are used in an SNMP engine implementation in the managed entity. In any generalized discussion of this data flow, we need to be sure that all of the security and correctness concerns are captured. I can certainly devote time to reviewing such a description, and can provide suggested text where problems arise. I don't have time in the immediate future to initially craft this text. > Lacking specific text proposals, I'm going to take a stab at what I > think > David Harrington is requesting be done to the RADIUS/VACM document. Excellent. From randy_presuhn@mindspring.com Wed Jun 2 23:05:10 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104F53A694F for ; Wed, 2 Jun 2010 23:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JUHQmY8M-R6 for ; Wed, 2 Jun 2010 23:05:06 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id A5B413A69D9 for ; Wed, 2 Jun 2010 23:05:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JDn/r489G9tlc8huxT3WiWKjKjw56jJVQtntkov9fZQFmK8IXo/mPxTxT7N3WQOD; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.227.68] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OK3Xv-0007PR-VF for isms@ietf.org; Thu, 03 Jun 2010 02:04:52 -0400 Message-ID: <001001cb02e2$ce654980$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Wed, 2 Jun 2010 23:05:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780354438a4bd1f1f5dff06c46ea609be942a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.227.68 Subject: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 06:05:10 -0000 Hi - I took a stab at trying to address David Harrington's comments. I've posted this in the form of an individual i-d. Please take a look at draft-presuhn-isms-radius-vacm-alt-00.txt; I'd appreciate feedback as to whether this might be a step forward or a step backwards, and whether it addresses your understanding of David's comments. http://www.ietf.org/internet-drafts/draft-presuhn-isms-radius-vacm-alt-00.txt Randy From wjhns1@hardakers.net Thu Jun 3 05:50:58 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1651728C14F for ; Thu, 3 Jun 2010 05:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZEHq9gw8VNM for ; Thu, 3 Jun 2010 05:50:45 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 49A483A68D4 for ; Thu, 3 Jun 2010 05:50:36 -0700 (PDT) Received: from localhost (unknown [166.129.141.24]) by mail.hardakers.net (Postfix) with ESMTPSA id 8895FA1EE8; Thu, 3 Jun 2010 05:50:11 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> Date: Thu, 03 Jun 2010 05:50:07 -0700 In-Reply-To: <001001cb02e2$ce654980$6801a8c0@oemcomputer> (Randy Presuhn's message of "Wed, 2 Jun 2010 23:05:43 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] IsmsAttempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 12:50:59 -0000 >>>>> On Wed, 2 Jun 2010 23:05:43 -0700, "Randy Presuhn" said: RP> I took a stab at trying to address David Harrington's comments. RP> I've posted this in the form of an individual i-d. Please RP> take a look at draft-presuhn-isms-radius-vacm-alt-00.txt; RP> I'd appreciate feedback as to whether this might be a step RP> forward or a step backwards, and whether it addresses your RP> understanding of David's comments. RP> http://www.ietf.org/internet-drafts/draft-presuhn-isms-radius-vacm-alt-00.txt Or for those that prefer diffs: http://tools.ietf.org//rfcdiff?url1=draft-ietf-isms-radius-vacm-06.txt&url2=draft-presuhn-isms-radius-vacm-alt-00.txt -- Wes Hardaker Cobham Analytic Solutions From dnelson@elbrys.com Thu Jun 3 11:59:15 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FAF328C0F7 for ; Thu, 3 Jun 2010 11:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl7EZu-ikc2C for ; Thu, 3 Jun 2010 11:59:14 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id C9BEB3A69CD for ; Thu, 3 Jun 2010 11:59:13 -0700 (PDT) Received: from source ([209.85.214.181]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTAf7dCfsVifGtiNEbtHOpsJ3vx1voYjb@postini.com; Thu, 03 Jun 2010 11:59:01 PDT Received: by mail-iw0-f181.google.com with SMTP id 33so361524iwn.12 for ; Thu, 03 Jun 2010 11:59:00 -0700 (PDT) Received: by 10.231.169.14 with SMTP id w14mr6431272iby.45.1275591540290; Thu, 03 Jun 2010 11:59:00 -0700 (PDT) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id t28sm1353766ibg.12.2010.06.03.11.58.59 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 11:58:59 -0700 (PDT) Message-Id: From: "David B. Nelson" To: Randy Presuhn In-Reply-To: <001001cb02e2$ce654980$6801a8c0@oemcomputer> Content-Type: multipart/alternative; boundary=Apple-Mail-5-931594207 Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Thu, 3 Jun 2010 14:58:57 -0400 References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 18:59:15 -0000 --Apple-Mail-5-931594207 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 4.2. Applicability Though this memo was motivated to support the use of specific Transport Models, such as [RFC5592], it MAY be used with other implementation environments satisfying these requirements: o use an AAA service for sign-on service authorization; DBN: RFC 5608 describes RADIUS service authorization. This document describes RADIUS data access control authorization. In point of fact, I believe that *both* service authorization and data access control authorization are prerequisite properties for applicability. o provide an indication of the start of of a session for a particular authenticated principal, identified using a SecurityName, and provide the corresponding value of vacmGroupName to be used, based on information provided by the AAA service in use; o provide an indication of the end of the need for being able to make access decisions for a particular authenticated principal, as at the end of a session, whether due to disconnection, termination due to timeout, or any other reason. Likewise, although this memo specifically refers to RADIUS, it MAY be used with other AAA services satisfying these requirements: o the service provides information semantically equivalent to the RADIUS Management-Policy-ID attribute [RFC5607], which corresponds to a GroupName; DBN: s/Management-Policy-ID/Management-Policy-Id/ o the service provides information semantically equivalent to the RADIUS User-Name Attribute [RFC2865], which corresponds to a SecurityName. 7.1. Sequencing Requirements These procedures assume that a transport model, such as [RFC5592], coordinates session establishment with AAA authorization. DBN: s/authorization/authentication and authorization/ They rely critically on the receipt by the AAA client of the RADIUS Management- Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their equivalents) from the RADIUS Access-Accept message (or equivalent). DBN: The RADIUS User-Name attribute is not provided in the Access- Accept message. The RADIUS client must remember it from the Access- Request message. In point of fact, this will typically come from some user identifier provided by the transport service that utilizes the RADIUS client, such as an SSH server. etc. --Apple-Mail-5-931594207 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit 
4.2.  Applicability

   Though this memo was motivated to support the use of specific
   Transport Models, such as [RFC5592], it MAY be used with other
   implementation environments satisfying these requirements:

   o  use an AAA service for sign-on service authorization;
DBN:  RFC 5608 describes RADIUS service authorization.  This document describes RADIUS data access control authorization.  In point of fact, I believe that *both* service authorization and data access control authorization are prerequisite properties for applicability.
   o  provide an indication of the start of of a session for a
      particular authenticated principal, identified using a
      SecurityName, and provide the corresponding value of vacmGroupName
      to be used, based on information provided by the AAA service in
      use;

   o  provide an indication of the end of the need for being able to
      make access decisions for a particular authenticated principal, as
      at the end of a session, whether due to disconnection, termination
      due to timeout, or any other reason.

   Likewise, although this memo specifically refers to RADIUS, it MAY be
   used with other AAA services satisfying these requirements:

   o  the service provides information semantically equivalent to the
      RADIUS Management-Policy-ID attribute [RFC5607], which corresponds
      to a GroupName;
DBN:  s/Management-Policy-ID/Management-Policy-Id/

   o  the service provides information semantically equivalent to the
      RADIUS User-Name Attribute [RFC2865], which corresponds to a
      SecurityName.

7.1.  Sequencing Requirements

   These procedures assume that a transport model, such as [RFC5592],
   coordinates session establishment with AAA authorization.
DBN: s/authorization/authentication and authorization/
   They rely
   critically on the receipt by the AAA client of the RADIUS Management-
   Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their
   equivalents) from the RADIUS Access-Accept message (or equivalent).
DBN:  The RADIUS User-Name attribute is not provided in the Access-Accept message.  The RADIUS client must remember it from the Access-Request message.  In point of fact, this will typically come from some user identifier provided by the transport service that utilizes the RADIUS client, such as an SSH server. etc.

--Apple-Mail-5-931594207-- From adonati@motorola.com Thu Jun 3 14:29:16 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0B73A6841 for ; Thu, 3 Jun 2010 14:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk-GXFNaTLfw for ; Thu, 3 Jun 2010 14:29:15 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id A48223A680A for ; Thu, 3 Jun 2010 14:29:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-3.tower-55.messagelabs.com!1275600535!17637419!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19525 invoked from network); 3 Jun 2010 21:28:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Jun 2010 21:28:56 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o53LSoAG028393 for ; Thu, 3 Jun 2010 14:28:55 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o53LSomi001100 for ; Thu, 3 Jun 2010 16:28:50 -0500 (CDT) Received: from de01exm62.ds.mot.com (de01exm62.am.mot.com [10.176.8.107]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o53LSoRU001093 for ; Thu, 3 Jun 2010 16:28:50 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0363.B55EE832" Date: Thu, 3 Jun 2010 17:28:26 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Attempt at addressing DBH's comments thread-index: AcsDTttkEvvQtgQxQDWAGxwGZnv2DwAENvMw References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> From: "Donati Andrew-MGIA0477" To: "David B. Nelson" , "Randy Presuhn" X-CFilter-Loop: Reflected Cc: isms@ietf.org Subject: Re: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:29:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0363.B55EE832 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 While discussing the RADIUS user name (or equivalent), it may be helpful to add more information in the description clause of extVacmSecurityName based on the following information. =20 Section 7.2.1 > extVacmSecurityName =3D RADIUS User-Name Attribute or equivalent =20 > DBN: The RADIUS User-Name attribute is not provided in the > Access-Accept message. The RADIUS client must remember > it from the Access-Request message. In point of fact, this will > typically come from some user identifier provided by the transport > service that utilizes the RADIUS client, such as an SSH server. etc. =20 Current implementation: =20 extVacmSecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Security Name of the principal associated with this session." ::=3D { extVacmSecurityToGroupEntry 2 } =20 - Andy Donati ________________________________ From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of David B. Nelson Sent: Thursday, June 03, 2010 2:59 PM To: Randy Presuhn Cc: isms@ietf.org Subject: Re: [Isms] Attempt at addressing DBH's comments 4.2. Applicability Though this memo was motivated to support the use of specific Transport Models, such as [RFC5592], it MAY be used with other implementation environments satisfying these requirements: o use an AAA service for sign-on service authorization; DBN: RFC 5608 describes RADIUS service authorization. This document describes RADIUS data access control authorization. In point of fact, I believe that *both* service authorization and data access control authorization are prerequisite properties for applicability. o provide an indication of the start of of a session for a particular authenticated principal, identified using a SecurityName, and provide the corresponding value of vacmGroupName to be used, based on information provided by the AAA service in use; o provide an indication of the end of the need for being able to make access decisions for a particular authenticated principal, as at the end of a session, whether due to disconnection, termination due to timeout, or any other reason. Likewise, although this memo specifically refers to RADIUS, it MAY be used with other AAA services satisfying these requirements: o the service provides information semantically equivalent to the RADIUS Management-Policy-ID attribute [RFC5607], which corresponds to a GroupName; DBN: s/Management-Policy-ID/Management-Policy-Id/ o the service provides information semantically equivalent to the RADIUS User-Name Attribute [RFC2865], which corresponds to a SecurityName. 7.1. Sequencing Requirements These procedures assume that a transport model, such as [RFC5592], coordinates session establishment with AAA authorization. DBN: s/authorization/authentication and authorization/ They rely critically on the receipt by the AAA client of the RADIUS Management- Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their equivalents) from the RADIUS Access-Accept message (or equivalent). DBN: The RADIUS User-Name attribute is not provided in the Access-Accept message. The RADIUS client must remember it from the Access-Request message. In point of fact, this will typically come from some user identifier provided by the transport service that utilizes the RADIUS client, such as an SSH server. etc. ------_=_NextPart_001_01CB0363.B55EE832 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
While discussing the RADIUS user name (or = equivalent), it may=20 be helpful to add more information in the description clause of=20 extVacmSecurityName
based = on the=20 following information.
 
Section=20 7.2.1
>=20 extVacmSecurityName =3D RADIUS User-Name Attribute or=20 equivalent
 
> =20 DBN:  The RADIUS User-Name attribute is not provided in=20 the
> =20 Access-Accept message.  The RADIUS client must = remember
> = it from=20 the Access-Request message.  In point of fact, this = will
>=20 typically come from some user identifier provided by the=20 transport
> = service=20 that utilizes the RADIUS client, such as an SSH server. = etc.
 
Current=20 implementation:
 
 extVacmSecurityName=20 OBJECT-TYPE
     =20 SYNTAX       SnmpAdminString=20 (SIZE(1..32))
      MAX-ACCESS  =20 not-accessible
     =20 STATUS      =20 current
      DESCRIPTION "The Security Name = of the=20 principal associated=20 with
           = ;       =20 this session."
      ::=3D {=20 extVacmSecurityToGroupEntry 2 }
 
- Andy = Donati
From: isms-bounces@ietf.org=20 [mailto:isms-bounces@ietf.org] On Behalf Of David B.=20 Nelson
Sent: Thursday, June 03, 2010 2:59 PM
To: = Randy=20 Presuhn
Cc: isms@ietf.org
Subject: Re: [Isms] = Attempt at=20 addressing DBH's comments

4.2.  Applicability

   Though this memo was motivated to support the use of specific
   Transport Models, such as [RFC5592], it MAY be used with other
   implementation environments satisfying these requirements:

   o  use an AAA service for sign-on service authorization;
DBN:  RFC 5608 describes RADIUS service =
authorization.  This document describes RADIUS data access control =
authorization.  In point of fact, I believe that *both* service =
authorization and data access control authorization are prerequisite =
properties for applicability.
 =
  o  provide an indication of the start of of a session for a
      particular authenticated principal, identified using a
      SecurityName, and provide the corresponding value of vacmGroupName
      to be used, based on information provided by the AAA service in
      use;

   o  provide an indication of the end of the need for being able to
      make access decisions for a particular authenticated principal, as
      at the end of a session, whether due to disconnection, termination
      due to timeout, or any other reason.

   Likewise, although this memo specifically refers to RADIUS, it MAY be
   used with other AAA services satisfying these requirements:

   o  the service provides information semantically equivalent to the
      RADIUS Management-Policy-ID attribute [RFC5607], which corresponds
      to a GroupName;
DBN:  =
s/Management-Policy-ID/Management-Policy-Id/

   o  the service provides information semantically equivalent to the
      RADIUS User-Name Attribute [RFC2865], which corresponds to a
      SecurityName.

7.1.  Sequencing Requirements

   These procedures assume that a transport model, such as [RFC5592],
   coordinates session establishment with AAA authorization.
DBN: s/authorization/authentication and =
authorization/
   They rely
   critically on the receipt by the AAA client of the RADIUS Management-
   Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their
   equivalents) from the RADIUS Access-Accept message (or =
equivalent).
DBN:  The RADIUS =
User-Name attribute is not provided in the Access-Accept message.  The =
RADIUS client must remember it from the Access-Request message.  In =
point of fact, this will typically come from some user identifier =
provided by the transport service that utilizes the RADIUS client, such =
as an SSH server. etc.

------_=_NextPart_001_01CB0363.B55EE832-- From j.schoenwaelder@jacobs-university.de Tue Jun 8 03:06:26 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E70E28C152 for ; Tue, 8 Jun 2010 03:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U48J3A2djdS for ; Tue, 8 Jun 2010 03:06:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0F28D28C155 for ; Tue, 8 Jun 2010 03:06:25 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D973EC0022; Tue, 8 Jun 2010 12:06:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id igUydPVs1JhX; Tue, 8 Jun 2010 12:06:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C70E1C0008; Tue, 8 Jun 2010 12:06:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 55D5412EA435; Tue, 8 Jun 2010 12:06:18 +0200 (CEST) Date: Tue, 8 Jun 2010 12:06:17 +0200 From: Juergen Schoenwaelder To: Dave Harrington Message-ID: <20100608100617.GA783@elstar.local> Mail-Followup-To: Dave Harrington , "isms@ietf.org" References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001001cb02e2$ce654980$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 10:06:26 -0000 On Thu, Jun 03, 2010 at 08:05:43AM +0200, Randy Presuhn wrote: > I took a stab at trying to address David Harrington's comments. > I've posted this in the form of an individual i-d. Please > take a look at draft-presuhn-isms-radius-vacm-alt-00.txt; > I'd appreciate feedback as to whether this might be a step > forward or a step backwards, and whether it addresses your > understanding of David's comments. > > http://www.ietf.org/internet-drafts/draft-presuhn-isms-radius-vacm-alt-00.txt David, can you take a look at this document and let us know whether this rewrite addresses your comments? If not, can you please provide concrete suggestions that help us/Randy to move forward? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dbharrington@comcast.net Tue Jun 8 14:25:11 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA79E3A680E for ; Tue, 8 Jun 2010 14:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8VRXhdo86cd for ; Tue, 8 Jun 2010 14:25:10 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id E736F3A65A6 for ; Tue, 8 Jun 2010 14:25:09 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id TWG91e0010SCNGk56ZRCZT; Tue, 08 Jun 2010 21:25:12 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta09.westchester.pa.mail.comcast.net with comcast id TZRB1e00G2JQnJT3VZRB5t; Tue, 08 Jun 2010 21:25:12 +0000 From: "David B Harrington" To: "'Juergen Schoenwaelder'" References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> <20100608100617.GA783@elstar.local> Date: Tue, 8 Jun 2010 17:25:10 -0400 Message-ID: <022401cb0751$135760b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <20100608100617.GA783@elstar.local> Thread-index: AcsG8kKi2sPDEKK8QV+hfbH0eCrPRwAGj5bQ Cc: isms@ietf.org Subject: Re: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 21:25:12 -0000 Hi, I looked at it, and it is much cleaner, but I have a real problem with the use of "session", which is a nebulous thing, and different references to session seem to refer to different things - a transport session, a transport model session (tmSessionID), the authentication of a principal, a AAA "policy" authorization. The existence and closing of a "session" triggers behaviors, and if interpretation of session differs, implementations might behave differently - in an externally visible way. So it is important to understand just what "session" means. in 4.1: OLD: [RFC5607]. When tracked using a suitable session identifier, such as tmSessionID [RFC5590], these provide sufficient information to compute dynamic updates to VACM. How this information is NEW: [RFC5607]. tmSessionID [RFC5590] is considered a suitable identifier of a AAA-authorized "session", because tmSessionID and tmSecurityName, assigned by a AAA-aware transport model, identify a specific transport session authorized to offer SNMP service, for which a principal has been AAA-authenticated. If present, a RADIUS-Management-Policy-ID attribute is bound to such a transport session and principal authentication. This binding provides sufficient information to compute dynamic updates to VACM. How this information is In 4.1, OLD o the service provides information semantically equivalent to the RADIUS User-Name Attribute [RFC2865], which corresponds to a SecurityName. NEW: o the service provides an authenticated principal identifier that can be transforned into an equivalent principal identifier in a SecurityName form. In 7.1, OLD: These procedures assume that a transport model, such as [RFC5592], coordinates session establishment with AAA authorization. They rely critically on the receipt by the AAA client of the RADIUS Management- Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their equivalents) from the RADIUS Access-Accept message (or equivalent). NEW: A transport model, such as [RFC5592], coordinates transport model session establishment with principal authentication and transport session authorization. The credentials and services used by a transport model to authenticate the principal are determined in an implementation-dependent manner. The procedures in this memo rely on implementation-specific use of AAA services to perform the principal authentication, and to provide AAA authorization policies such as the RADIUS Management-Policy-Id attribute [RFC5607]. in 7.1: OLD: To ensure correct processing of SNMP PDUs, the handling of the indication of the termination of a session in accordance with the elements of procedure below MUST NOT be initiated before all invocations of the IsAccessAllowed() abstract service interface have completed for all SNMP PDUs from that session. NEW: I am not sure how to reword this. The application subsystem processes the PDUs and calls the isAccessAllowed() ASI. The processing of a session termination is handled within the ACM subsystem. The current text is like saying "a session starts when you plug your phone into an RJ11 socket, and you cannot unplug the phone until everybody has finished calling you." What you really need to say is "if you unplug the phone before everybody has finished calling you, then any existing and subsequent calls may fail." If the handling of the termination of a session in accordance with the elements of procedure below removes the userToGroup mapping from the VACM table, before all invocations of the IsAccessAllowed() abstract service interface have completed for all SNMP PDUs from that session, those invocations MAY result in an access denied error. You could try to make this "Implementations SHOULD NOT terminate a session until all PDUs for a session have been processed, but I'm not sure that's the right AAA security property; it might be better to have the PDU fail if the authorization is revoked during processing. in 7.2: OLD: o the SnmpSecurityModel [RFC3411] NEW: o the SnmpSecurityModel [RFC3411] used to create the securityName used in the isAccessAllowed() invocation. OLD: o a session identifier, such as tmSessionID [RFC5590] NEW: o a session identifier, such as tmSessionID [RFC5590], that is a definitive identifier of the transport session that the AAA authorization is tied to. OLD: o extVacmSecurityName = RADIUS User-Name Attribute or equivalent NEW: o extVacmSecurityName = the securityName that will be used with isAccessAllowed() ASI in 7.3: OLD: Whenever a RADIUS (or other AAA) authenticated session ends for any reason, an indication is provided to this function. This indication MUST provide means of determining the SnmpSecurityModel and an identifier for the session, which MUST be unique at least within the scope of that SnmpSecurityModel. The manner in which this occurs is implementation dependent. NEW: Whenever a RADIUS (or other AAA) authorized session ends for any reason, an indication is provided to this VACM extension. This indication MUST provide means of determining the SnmpSecurityModel, securityName, and an identifier for the transport session tied to the AAA authorization. The manner in which this occurs is implementation dependent. in 7.3.1: OLD: When a session has been terminated, the extVacmSecurityToGroupTable is searched for a corresponding entry. (A "matching" entry is any entry for which the SnmpSecurityModel and session ID match the information associated with the session termination indication.) Any matching entries are deleted. It is possible that no entries will match; this is not an error, and no special processing is required in this case. NEW: When a session has been terminated, the extVacmSecurityToGroupTable is searched for a corresponding entry. A "matching" entry is any entry for which the SnmpSecurityModel, securityName, and session ID match the information associated with the session termination indication. It is possible that no entries will match; this is not an error, and no special processing is required in this case. extVacmSecurityModel OBJECT-TYPE SYNTAX SnmpSecurityModel(1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Security Model to which the session referred to by this entry belongs. This object cannot take the 'any' (0) value." ::= { extVacmSecurityToGroupEntry 1 } A session does not belong to a security model. A securityName is created by a security model. so I suppose you could say "The Security Model to which the securityName referred to by this entry belongs." It's not the way I would normally approach describing it, but I guess it's accurate. Maybe "The Security Model associated with the AAA binding represented by this entry." If you change this, then you might want to change the securityName and sessionID descriptions as well. I think a securityName is specific to the security model that generates it. USM and TSM can both generate a "dbh" securityname, so you always need to identify the securityModel associated with a securityName. Is tmSessionID specific to a transport model? I think so. If I have an SSH Transport model and a TLS transport model, can they both generate the same tmSessionID? RFC5590 requires the tmState to include the tmTransportDomain (and hence the transport model identifier) and the tmSessionID. per RFC5590, the tmSessionID "is only ever used by the Transport Model, so the format and interpretation of this field are model-specific and implementation-dependent." So I think the tmSessionID is only unique within a transport model (tmTransportDomain). It really wasn't designed to be used outside the cache/transportModel. Ergo, using tmSessionID in the index without a corresponding tmTransportDomain may not be viable. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, June 08, 2010 6:06 AM > To: Dave Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] Attempt at addressing DBH's comments > > On Thu, Jun 03, 2010 at 08:05:43AM +0200, Randy Presuhn wrote: > > > I took a stab at trying to address David Harrington's comments. > > I've posted this in the form of an individual i-d. Please > > take a look at draft-presuhn-isms-radius-vacm-alt-00.txt; > > I'd appreciate feedback as to whether this might be a step > > forward or a step backwards, and whether it addresses your > > understanding of David's comments. > > > > > http://www.ietf.org/internet-drafts/draft-presuhn-isms-radius- > vacm-alt-00.txt > > David, > > can you take a look at this document and let us know whether this > rewrite addresses your comments? If not, can you please provide > concrete suggestions that help us/Randy to move forward? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From j.schoenwaelder@jacobs-university.de Thu Jun 17 13:27:06 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD3B3A6887 for ; Thu, 17 Jun 2010 13:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uo0GB52Ln93J for ; Thu, 17 Jun 2010 13:27:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CC7A93A68CB for ; Thu, 17 Jun 2010 13:27:05 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA2A6C0004; Thu, 17 Jun 2010 22:27:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LWcPZFgnNgFo; Thu, 17 Jun 2010 22:27:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 076CDC000A; Thu, 17 Jun 2010 22:27:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0FA7D1349243; Thu, 17 Jun 2010 22:27:02 +0200 (CEST) Date: Thu, 17 Jun 2010 22:27:02 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100617202700.GA39045@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001001cb02e2$ce654980$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 20:27:07 -0000 On Thu, Jun 03, 2010 at 08:05:43AM +0200, Randy Presuhn wrote: > I took a stab at trying to address David Harrington's comments. > I've posted this in the form of an individual i-d. Please > take a look at draft-presuhn-isms-radius-vacm-alt-00.txt; > I'd appreciate feedback as to whether this might be a step > forward or a step backwards, and whether it addresses your > understanding of David's comments. There meanwhile have been a number of comments posted to the list. Randy, do you plan to post an updated version? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Fri Jun 25 14:36:43 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685383A6821 for ; Fri, 25 Jun 2010 14:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx8+AAzkls5D for ; Fri, 25 Jun 2010 14:36:42 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 632843A68F1 for ; Fri, 25 Jun 2010 14:36:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NFdUC2ywtV/0r7K55zL7DTTFOlEVrq+hkZG3p4xwQT2GLt605JSY/EL/1cezo70a; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.4.106] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OSGZu-0003r3-SZ for isms@ietf.org; Fri, 25 Jun 2010 17:36:51 -0400 Message-ID: <001501cb14ae$c3c936c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> Date: Fri, 25 Jun 2010 14:38:33 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035da2f11a442b0c7e77a1e812e0311e5c6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.4.106 Subject: Re: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 21:36:43 -0000 Hi - I've made edits corresponding to all of David Nelson's comments. An updated I-D should soon appear. Randy > From: "David B. Nelson" > To: "Randy Presuhn" > Cc: > Sent: Thursday, June 03, 2010 11:58 AM > Subject: Re: [Isms] Attempt at addressing DBH's comments > > 4.2. Applicability > > Though this memo was motivated to support the use of specific > Transport Models, such as [RFC5592], it MAY be used with other > implementation environments satisfying these requirements: > > o use an AAA service for sign-on service authorization; > DBN: RFC 5608 describes RADIUS service authorization. This document > describes RADIUS data access control authorization. In point of fact, > I believe that *both* service authorization and data access control > authorization are prerequisite properties for applicability. > o provide an indication of the start of of a session for a > particular authenticated principal, identified using a > SecurityName, and provide the corresponding value of > vacmGroupName > to be used, based on information provided by the AAA service in > use; > > o provide an indication of the end of the need for being able to > make access decisions for a particular authenticated principal, > as > at the end of a session, whether due to disconnection, > termination > due to timeout, or any other reason. > > Likewise, although this memo specifically refers to RADIUS, it MAY > be > used with other AAA services satisfying these requirements: > > o the service provides information semantically equivalent to the > RADIUS Management-Policy-ID attribute [RFC5607], which > corresponds > to a GroupName; > DBN: s/Management-Policy-ID/Management-Policy-Id/ > > o the service provides information semantically equivalent to the > RADIUS User-Name Attribute [RFC2865], which corresponds to a > SecurityName. > > 7.1. Sequencing Requirements > > These procedures assume that a transport model, such as [RFC5592], > coordinates session establishment with AAA authorization. > DBN: s/authorization/authentication and authorization/ > They rely > critically on the receipt by the AAA client of the RADIUS > Management- > Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their > equivalents) from the RADIUS Access-Accept message (or equivalent). > DBN: The RADIUS User-Name attribute is not provided in the Access- > Accept message. The RADIUS client must remember it from the Access- > Request message. In point of fact, this will typically come from some > user identifier provided by the transport service that utilizes the > RADIUS client, such as an SSH server. etc. > > From randy_presuhn@mindspring.com Fri Jun 25 14:41:08 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592943A69C3 for ; Fri, 25 Jun 2010 14:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6NY610WDqu0 for ; Fri, 25 Jun 2010 14:41:03 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 519113A6836 for ; Fri, 25 Jun 2010 14:41:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cY8f7N6L9UCO6ax6/nHvJATeAlADJUvCvpJHYqeYQTXEoj8CnZn+NAt7OA1dUh0q; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.4.106] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OSGe6-0002Ct-UJ for isms@ietf.org; Fri, 25 Jun 2010 17:41:11 -0400 Message-ID: <001d01cb14af$5f8560c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> Date: Fri, 25 Jun 2010 14:42:55 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035e27fc25221d2e7e1f994860bb5a5e28e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.4.106 Subject: Re: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 21:41:08 -0000 Hi - Ok, I've made corresponding changes. An updated I-D should appear shortly. Randy ----- Original Message ----- From: "Donati Andrew-MGIA0477" To: "David B. Nelson" ; "Randy Presuhn" Cc: Sent: Thursday, June 03, 2010 2:28 PM Subject: RE: [Isms] Attempt at addressing DBH's comments Hi, While discussing the RADIUS user name (or equivalent), it may be helpful to add more information in the description clause of extVacmSecurityName based on the following information. Section 7.2.1 > extVacmSecurityName = RADIUS User-Name Attribute or equivalent > DBN: The RADIUS User-Name attribute is not provided in the > Access-Accept message. The RADIUS client must remember > it from the Access-Request message. In point of fact, this will > typically come from some user identifier provided by the transport > service that utilizes the RADIUS client, such as an SSH server. etc. Current implementation: extVacmSecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Security Name of the principal associated with this session." ::= { extVacmSecurityToGroupEntry 2 } - Andy Donati ________________________________ From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of David B. Nelson Sent: Thursday, June 03, 2010 2:59 PM To: Randy Presuhn Cc: isms@ietf.org Subject: Re: [Isms] Attempt at addressing DBH's comments 4.2. Applicability Though this memo was motivated to support the use of specific Transport Models, such as [RFC5592], it MAY be used with other implementation environments satisfying these requirements: o use an AAA service for sign-on service authorization; DBN: RFC 5608 describes RADIUS service authorization. This document describes RADIUS data access control authorization. In point of fact, I believe that *both* service authorization and data access control authorization are prerequisite properties for applicability. o provide an indication of the start of of a session for a particular authenticated principal, identified using a SecurityName, and provide the corresponding value of vacmGroupName to be used, based on information provided by the AAA service in use; o provide an indication of the end of the need for being able to make access decisions for a particular authenticated principal, as at the end of a session, whether due to disconnection, termination due to timeout, or any other reason. Likewise, although this memo specifically refers to RADIUS, it MAY be used with other AAA services satisfying these requirements: o the service provides information semantically equivalent to the RADIUS Management-Policy-ID attribute [RFC5607], which corresponds to a GroupName; DBN: s/Management-Policy-ID/Management-Policy-Id/ o the service provides information semantically equivalent to the RADIUS User-Name Attribute [RFC2865], which corresponds to a SecurityName. 7.1. Sequencing Requirements These procedures assume that a transport model, such as [RFC5592], coordinates session establishment with AAA authorization. DBN: s/authorization/authentication and authorization/ They rely critically on the receipt by the AAA client of the RADIUS Management- Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their equivalents) from the RADIUS Access-Accept message (or equivalent). DBN: The RADIUS User-Name attribute is not provided in the Access-Accept message. The RADIUS client must remember it from the Access-Request message. In point of fact, this will typically come from some user identifier provided by the transport service that utilizes the RADIUS client, such as an SSH server. etc. From randy_presuhn@mindspring.com Sat Jun 26 00:40:45 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335E23A68DD for ; Sat, 26 Jun 2010 00:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRsUvJ73o1ZE for ; Sat, 26 Jun 2010 00:40:43 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 3AEE03A6405 for ; Sat, 26 Jun 2010 00:40:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PQYsGDpfjaSLWinAE6/THDq7iVeo/ZFxAjlMNxj0WPmBotV5Vdm0os345R2Q1jtM; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.227.73] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OSQ0R-00088l-V5 for isms@ietf.org; Sat, 26 Jun 2010 03:40:52 -0400 Message-ID: <001701cb1503$255c9220$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001001cb02e2$ce654980$6801a8c0@oemcomputer><20100608100617.GA783@elstar.local> <022401cb0751$135760b0$0600a8c0@china.huawei.com> Date: Sat, 26 Jun 2010 00:42:34 -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-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035ec5ab057b121704e94e1dd49397ab499350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.227.73 Subject: Re: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 07:40:45 -0000 Hi - Ok, I've applied most of the edits suggested. I've commented below on those few cases where I think what I've done differs in a significant way from what David suggested. Updated I-D should soon appear. > From: "David B Harrington" > To: "'Juergen Schoenwaelder'" > Cc: > Sent: Tuesday, June 08, 2010 2:25 PM > Subject: Re: [Isms] Attempt at addressing DBH's comments > > Hi, > > I looked at it, and it is much cleaner, but I have a real problem > with the use of "session", which is a nebulous thing, and different > references to session seem to refer to different things - a transport > session, a transport model session (tmSessionID), the authentication > of a principal, a AAA "policy" authorization. The existence and > closing of a "session" triggers behaviors, and if interpretation of > session differs, implementations might behave differently - in an > externally visible way. So it is important to understand just what > "session" means. > > in 4.1: > OLD: > [RFC5607]. When tracked using a suitable session identifier, such > as > tmSessionID [RFC5590], these provide sufficient information to > compute dynamic updates to VACM. How this information is > NEW: > [RFC5607]. > > tmSessionID [RFC5590] is considered a suitable identifier of a > AAA-authorized "session", > because tmSessionID and tmSecurityName, assigned by a AAA-aware > transport model, identify a > specific transport session authorized to offer SNMP service, for > which a principal has been > AAA-authenticated. If present, a RADIUS-Management-Policy-ID > attribute is bound to such a > transport session and principal authentication. This binding > provides sufficient information to > compute dynamic updates to VACM. How this information is ok > In 4.1, > OLD > o the service provides information semantically equivalent to the > RADIUS User-Name Attribute [RFC2865], which corresponds to a > SecurityName. > NEW: > o the service provides an authenticated principal identifier that > can > be transforned into an equivalent principal identifier in a > SecurityName form. ok > In 7.1, > OLD: > These procedures assume that a transport model, such as [RFC5592], > coordinates session establishment with AAA authorization. They > rely > critically on the receipt by the AAA client of the RADIUS > Management- > Policy-Id [RFC5607] and User-Name [RFC2865] Attributes (or their > equivalents) from the RADIUS Access-Accept message (or equivalent). > NEW: > A transport model, such as [RFC5592], coordinates transport model > session > establishment with principal authentication and transport session > authorization. > The credentials and services used by a transport model to > authenticate the principal > are determined in an implementation-dependent manner. > The procedures in this memo rely on implementation-specific use of > AAA > services to perform the principal authentication, and to provide > AAA authorization > policies such as the RADIUS Management-Policy-Id attribute > [RFC5607]. ok > in 7.1: > OLD: > To ensure correct processing of SNMP PDUs, the handling of the > indication of the termination of a session in accordance with the > elements of procedure below MUST NOT be initiated before all > invocations of the IsAccessAllowed() abstract service interface > have > completed for all SNMP PDUs from that session. > NEW: > I am not sure how to reword this. The application subsystem processes > the PDUs and calls the > isAccessAllowed() ASI. The processing of a session termination is > handled within the > ACM subsystem. The current text is like saying "a session starts when > you plug your phone into an RJ11 socket, and you cannot unplug the > phone until everybody has finished calling you." > What you really need to say is "if you unplug the phone before > everybody has finished calling you, then any existing and subsequent > calls may fail." > If the handling of the termination of a session in accordance with > the > elements of procedure below removes the userToGroup mapping from > the VACM table, > before all invocations of the IsAccessAllowed() abstract service > interface have completed > for all SNMP PDUs from that session, those invocations MAY result > in an access denied error. > You could try to make this "Implementations SHOULD NOT terminate a > session until all PDUs for a session have been processed, but I'm not > sure that's the right AAA security property; it might be better to > have the PDU fail if the authorization is revoked during processing. Ok, though I used different words. There are several possible approaches, and the question is just how much need there is to nail down implementations in this edge case (a session is torn down while a request is being processed). The new words actually permit more variation among implementations than what I had, but I don't feel any need to push for uniformity here. > in 7.2: > OLD: > o the SnmpSecurityModel [RFC3411] > NEW: > o the SnmpSecurityModel [RFC3411] used to create the securityName > used in the isAccessAllowed() invocation. > > OLD: > o a session identifier, such as tmSessionID [RFC5590] > NEW: > o a session identifier, such as tmSessionID [RFC5590], that is a > definitive identifier of the transport session that the AAA > authorization is tied to. > > OLD: > o extVacmSecurityName = RADIUS User-Name Attribute or equivalent > NEW: > o extVacmSecurityName = the securityName that will be used with > isAccessAllowed() ASI ok > in 7.3: > OLD: > > Whenever a RADIUS (or other AAA) authenticated session ends for any > reason, an indication is provided to this function. This > indication > MUST provide means of determining the SnmpSecurityModel and an > identifier for the session, which MUST be unique at least within > the > scope of that SnmpSecurityModel. The manner in which this occurs > is > implementation dependent. > NEW: > > Whenever a RADIUS (or other AAA) authorized session ends for any > reason, an indication is provided to this VACM extension. This > indication > MUST provide means of determining the SnmpSecurityModel, > securityName, and an > identifier for the transport session tied to the AAA authorization. > The manner > in which this occurs is implementation dependent. ok > in 7.3.1: > OLD: > When a session has been terminated, the extVacmSecurityToGroupTable > is searched for a corresponding entry. (A "matching" entry is any > entry for which the SnmpSecurityModel and session ID match the > information associated with the session termination indication.) > Any > matching entries are deleted. It is possible that no entries will > match; this is not an error, and no special processing is required > in > this case. > NEW: > When a session has been terminated, the extVacmSecurityToGroupTable > is searched for a corresponding entry. A "matching" entry is any > entry for which the SnmpSecurityModel, securityName, and session ID > > match the information associated with the session termination > indication. > It is possible that no entries will match; this is not an error, > and > no special processing is required in this case. I KEPT the sentence "Any matching entries are deleted." Without that sentence, the procedure will not function correctly. > extVacmSecurityModel OBJECT-TYPE > SYNTAX SnmpSecurityModel(1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION "The Security Model to which the session referred > to by this entry belongs. > This object cannot take the 'any' (0) value." > ::= { extVacmSecurityToGroupEntry 1 } > > A session does not belong to a security model. > A securityName is created by a security model. > so I suppose you could say "The Security Model to which the > securityName referred to by this entry belongs." > It's not the way I would normally approach describing it, but I guess > it's accurate. > Maybe "The Security Model associated with the AAA binding represented > by this entry." > If you change this, then you might want to change the securityName and > sessionID descriptions as well. ok > I think a securityName is specific to the security model that > generates it. USM and TSM can both generate a "dbh" securityname, so > you always need to identify the securityModel associated with a > securityName. that's why it's there (as well be being needed to find the right entries in VACM) > Is tmSessionID specific to a transport model? I think so. If I have an > SSH Transport model and a TLS transport model, can they both generate > the same tmSessionID? RFC5590 requires the tmState to include the > tmTransportDomain (and hence the transport model identifier) and the > tmSessionID. per RFC5590, the tmSessionID "is only ever used by the > Transport Model, so the format and interpretation of this field are > model-specific and implementation-dependent." So I think the > tmSessionID is only unique within a transport model > (tmTransportDomain). It really wasn't designed to be used outside the > cache/transportModel. Ergo, using tmSessionID in the index without a > corresponding tmTransportDomain may not be viable. Sooooooo (and this affects some of the above edits) Here's what I did on this one: - added a extVacmTransportModel INDEX to the table - I gave it a SYNTAX of SnmpAdminString, using as the value the 1-4 character transport domain prefix from the registry defined in RFC 5590. This seemed slightly less awkward than using the corresponding OID. - wherever the session ID was mentioned, I added words to make it relative to the transport model. Randy From randy_presuhn@mindspring.com Sat Jun 26 00:52:08 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD07928C0E7 for ; Sat, 26 Jun 2010 00:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpnr20fyZU36 for ; Sat, 26 Jun 2010 00:52:08 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 009C03A684B for ; Sat, 26 Jun 2010 00:52:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=arP2SB2UwL3s1DE7+ammlcEND9Wsv/c2nwkG9LROQhdyGwdq4jIzhGwH+mLJl6n9; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.227.73] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OSQBU-0002Ij-W9 for isms@ietf.org; Sat, 26 Jun 2010 03:52:17 -0400 Message-ID: <004301cb1504$bee19b60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Sat, 26 Jun 2010 00:54:02 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0040_01CB14CA.11BADF80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780353b6d7161c42c1e88c0a0f46860923caf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.227.73 Subject: [Isms] Fw: I-D Action:draft-presuhn-isms-radius-vacm-alt-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 07:52:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0040_01CB14CA.11BADF80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi - I've updated the individual i-d exploring how we might resolve David Harrington's WG last call comments on the RADIUS/VACM i-d. Randy > From: > To: > Sent: Saturday, June 26, 2010 12:45 AM > Subject: I-D Action:draft-presuhn-isms-radius-vacm-alt-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings > Author(s) : K. Narayan, et al. > Filename : draft-presuhn-isms-radius-vacm-alt-01.txt > Pages : 18 > Date : 2010-06-26 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols. It describes the use of > information provided by Authentication, Authorization, and Accounting > (AAA) services, such as the Remote Authentication Dial-In User > Service (RADIUS), to dynamically update user-to-group mappings in the > View-Based Access Control Model (VACM). > > Comments are solicited and should be addressed to the working group's > mailing list at isms@ietf.org. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-presuhn-isms-radius-vacm-alt-01.txt ... ------=_NextPart_000_0040_01CB14CA.11BADF80 Content-Type: text/plain; name="draft-presuhn-isms-radius-vacm-alt-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-presuhn-isms-radius-vacm-alt-01.txt" Content-Type: text/plain Content-ID: <2010-06-26004343.I-D@ietf.org> ------=_NextPart_000_0040_01CB14CA.11BADF80-- From ietfdbh@comcast.net Tue Jun 29 13:58:36 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BC43A695F for ; Tue, 29 Jun 2010 13:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-MI3losOLor for ; Tue, 29 Jun 2010 13:58:35 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 3A1DA3A67E7 for ; Tue, 29 Jun 2010 13:58:35 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta07.westchester.pa.mail.comcast.net with comcast id bsad1e0031wpRvQ57wymt1; Tue, 29 Jun 2010 20:58:46 +0000 Received: from 23FX1C1 ([68.65.79.146]) by omta18.westchester.pa.mail.comcast.net with comcast id bwya1e00p39QC6U3ewyd1j; Tue, 29 Jun 2010 20:58:44 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <001001cb02e2$ce654980$6801a8c0@oemcomputer><20100608100617.GA783@elstar.local><022401cb0751$135760b0$0600a8c0@china.huawei.com> <001701cb1503$255c9220$6801a8c0@oemcomputer> Date: Tue, 29 Jun 2010 16:58:35 -0400 Message-ID: <9B3E8EB20CCC43889121165228CFAADB@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsVAun9SnjkFMJpSFivzbMGCc2a3gCyktuw In-Reply-To: <001701cb1503$255c9220$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Isms] Attempt at addressing DBH's comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 20:58:36 -0000 Hi, I don't think I've replied yet. These proposed changes look good. > > Ok, though I used different words. There are several > possible approaches, and the question is just how much need > there is to nail down implementations in this edge case (a > session is torn down while a request is being processed). > The new words actually permit more variation among > implementations than what I had, but I don't feel any need to > push for uniformity here. ok. > I KEPT the sentence "Any matching entries are deleted." > Without that sentence, the procedure will not function correctly. ooh. typo on my part. good catch. > Sooooooo (and this affects some of the above edits) Here's > what I did on this one: > - added a extVacmTransportModel INDEX to the table > - I gave it a SYNTAX of SnmpAdminString, using as the > value the 1-4 character transport domain prefix from the > registry defined in RFC 5590. This seemed slightly > less awkward than using the corresponding OID. > - wherever the session ID was mentioned, I added words > to make it relative to the transport model. > good. thanks. > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From Robert.Story@cobham.com Tue Jun 29 17:23:43 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187793A6A35 for ; Tue, 29 Jun 2010 17:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUBhfYaAAEVL for ; Tue, 29 Jun 2010 17:23:42 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3CE343A69C8 for ; Tue, 29 Jun 2010 17:23:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5U0NqCO001382 for ; Tue, 29 Jun 2010 19:23:52 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5U0NqSE018421 for ; Tue, 29 Jun 2010 19:23:52 -0500 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 20:23:51 -0400 Date: Tue, 29 Jun 2010 20:23:38 -0400 From: Robert Story To: Message-ID: <20100629202338.5eaff6a8@sparta.com> Organization: SPARTA X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.9; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/6+DTAjirTPVnqc8URgHp9dx"; protocol="application/pgp-signature" X-OriginalArrivalTime: 30 Jun 2010 00:23:52.0053 (UTC) FILETIME=[845AF250:01CB17EA] Cc: Wes Hardaker Subject: [Isms] SNMP-TLS-TM-MIB errata X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 00:23:43 -0000 --Sig_/6+DTAjirTPVnqc8URgHp9dx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, While testing our SNMP-TLS-TM-MIB implementation I discovered a problem with the DISPLAY-HINT for SnmpTLSFingerprint. The current hint is "1x:254x", which one might think meant one hex byte, a colon, and up to 254 more hex bytes. But according to section 3.1 of 2579, 254 is a width specifier, so it is a one byte hex followed by a 254 byte wide hex number. I believe the hint should be "1x:1x", which will be one hex byte, a colon, and N hex bytes where N is the remaining length of the octet string. Hopefully this can be fixed before the rfc is finalized. It is a small change that doesn't affect anything in the protocol or on the wire. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/6+DTAjirTPVnqc8URgHp9dx Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkwqjpQACgkQ7/fVLLY1mnhgmQCfYBzMDtC84nopWDJl2WPiWHHp XrcAn08XAkiQCm8laWUwn1zyO9NGP3VH =H1by -----END PGP SIGNATURE----- --Sig_/6+DTAjirTPVnqc8URgHp9dx-- From wjhns1@hardakers.net Tue Jun 29 18:52:39 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95CE628C0D8 for ; Tue, 29 Jun 2010 18:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-HRuZhGXHIj for ; Tue, 29 Jun 2010 18:52:38 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id B9D0828C0CE for ; Tue, 29 Jun 2010 18:52:38 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id C7FE498142; Tue, 29 Jun 2010 18:52:48 -0700 (PDT) From: Wes Hardaker To: Robert Story Organization: Sparta References: <20100629202338.5eaff6a8@sparta.com> Date: Tue, 29 Jun 2010 18:52:48 -0700 In-Reply-To: <20100629202338.5eaff6a8@sparta.com> (Robert Story's message of "Tue, 29 Jun 2010 20:23:38 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org, Wes Hardaker Subject: Re: [Isms] IsmsSNMP-TLS-TM-MIB errata X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 01:52:39 -0000 Having just re-read the rules in RFC2579's 3.1, I agree with Robert's analysis and will make this change during AUTH48 unless I hear objections or other solution suggestions. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Tue Jun 29 20:17:00 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC47A3A682B for ; Tue, 29 Jun 2010 20:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nd9PWVOTndy for ; Tue, 29 Jun 2010 20:16:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C60F03A63CA for ; Tue, 29 Jun 2010 20:16:59 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58EFDC0004; Wed, 30 Jun 2010 05:17:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id amYcTXVk9BcT; Wed, 30 Jun 2010 05:17:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1993C0002; Wed, 30 Jun 2010 05:17:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A59651372F63; Wed, 30 Jun 2010 05:17:01 +0200 (CEST) Date: Wed, 30 Jun 2010 05:17:00 +0200 From: Juergen Schoenwaelder To: Robert Story Message-ID: <20100630031659.GA43495@elstar.local> Mail-Followup-To: Robert Story , "isms@ietf.org" , Wes Hardaker References: <20100629202338.5eaff6a8@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100629202338.5eaff6a8@sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" , Wes Hardaker Subject: Re: [Isms] SNMP-TLS-TM-MIB errata X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 03:17:01 -0000 On Wed, Jun 30, 2010 at 02:23:38AM +0200, Robert Story wrote: > While testing our SNMP-TLS-TM-MIB implementation I discovered a problem > with the DISPLAY-HINT for SnmpTLSFingerprint. The current hint is > "1x:254x", which one might think meant one hex byte, a colon, and up to > 254 more hex bytes. But according to section 3.1 of 2579, 254 is a > width specifier, so it is a one byte hex followed by a 254 byte wide hex > number. I believe the hint should be "1x:1x", which will be one hex > byte, a colon, and N hex bytes where N is the remaining length of the > octet string. Why do you believe 254 is a "width" specifier? RFC 2579 says: (2) the octet length: one or more decimal digits specifying the number of octets of the value to be used and formatted by this octet- specification. Note that the octet length can be zero. If less than this number of octets remain in the value, then the lesser number of octets are used. My reading of this is "take 254 bytes of the value and display it as a hexadecimal number". Your suggested hint says "take 1 byte of the value and display it as a hexadecimal number" and since RFC 2579 says [...] If additional octets remain in the value after interpreting all the octet-format specifications, then the last octet-format specification is re-interpreted to process the additional octets, until no octets remain in the value. you repeat taking a 1 byte value displaying it as a hexadecimal number until the bytes are exhausted. So are not both hints producing the same result? That said, I believe that "1x:1x" is a better choice given the variable length nature of the SnmpTLSFingerprint. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Robert.Story@cobham.com Tue Jun 29 22:13:57 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E873A6C2D for ; Tue, 29 Jun 2010 22:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT0hGm2VSVzR for ; Tue, 29 Jun 2010 22:13:52 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A8AE43A6C22 for ; Tue, 29 Jun 2010 22:13:50 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5U5E1P6002759; Wed, 30 Jun 2010 00:14:01 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5U5E1Yp023340; Wed, 30 Jun 2010 00:14:01 -0500 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jun 2010 01:14:01 -0400 Date: Wed, 30 Jun 2010 01:13:49 -0400 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20100630011349.00ae4e73@sparta.com> In-Reply-To: <20100630031659.GA43495@elstar.local> References: <20100629202338.5eaff6a8@sparta.com> <20100630031659.GA43495@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.9; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_//KuO0Rky1H9.Tzeo8293HM0"; protocol="application/pgp-signature" X-OriginalArrivalTime: 30 Jun 2010 05:14:01.0387 (UTC) FILETIME=[0D207FB0:01CB1813] Cc: "isms@ietf.org" , Wes Hardaker Subject: Re: [Isms] SNMP-TLS-TM-MIB errata X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 05:13:58 -0000 --Sig_//KuO0Rky1H9.Tzeo8293HM0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 30 Jun 2010 05:17:00 +0200 Juergen wrote: JS> Why do you believe 254 is a "width" specifier? RFC 2579 says: JS>=20 JS> (2) the octet length: one or more decimal digits specifying the number JS> of octets of the value to be used and formatted by this octet- JS> specification. Note that the octet length can be zero. If less JS> than this number of octets remain in the value, then the lesser JS> number of octets are used. JS>=20 JS> My reading of this is "take 254 bytes of the value and display it as a JS> hexadecimal number". Hmmm... I have to admit, I'm biased by the Net-SNMP implementation of display hint processing. But using your reading and a hint of "2d", given the value 0x0102, you could output a decimal number for each octet and get the output "12", but the output should be the decimal number represented by the two octets together: 258. It does seem to be a bit ambiguous... but the next item, (3) says the octet length is used in interpreting "the" value... i.e. a single value, which is how we interpret "2d" in the example I gave earlier. JS> So are not both hints producing the same result? Definitely not in Net-SNMP. :-) But I suppose I could be convinced that it is a bug in our processing code. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_//KuO0Rky1H9.Tzeo8293HM0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkwq0pYACgkQ7/fVLLY1mni0zwCeLsvQYMdz2d/AJDgYbV4nmXn6 0vgAnArbO8wjacaSayTPnp1P1iY/N0/l =we7M -----END PGP SIGNATURE----- --Sig_//KuO0Rky1H9.Tzeo8293HM0-- From j.schoenwaelder@jacobs-university.de Tue Jun 29 22:48:05 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40483A6C21 for ; Tue, 29 Jun 2010 22:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ03K0zd-pEN for ; Tue, 29 Jun 2010 22:48:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8D45E3A6AD1 for ; Tue, 29 Jun 2010 22:48:04 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30D05C0002; Wed, 30 Jun 2010 07:48:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3af3Rb2NoI5F; Wed, 30 Jun 2010 07:48:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A744C0007; Wed, 30 Jun 2010 07:48:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4DADF137330C; Wed, 30 Jun 2010 07:48:09 +0200 (CEST) Date: Wed, 30 Jun 2010 07:48:09 +0200 From: Juergen Schoenwaelder To: Robert Story Message-ID: <20100630054809.GB43772@elstar.local> Mail-Followup-To: Robert Story , "isms@ietf.org" , Wes Hardaker References: <20100629202338.5eaff6a8@sparta.com> <20100630031659.GA43495@elstar.local> <20100630011349.00ae4e73@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100630011349.00ae4e73@sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" , Wes Hardaker Subject: Re: [Isms] SNMP-TLS-TM-MIB errata X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 05:48:06 -0000 On Wed, Jun 30, 2010 at 07:13:49AM +0200, Robert Story wrote: > On Wed, 30 Jun 2010 05:17:00 +0200 Juergen wrote: > JS> Why do you believe 254 is a "width" specifier? RFC 2579 says: > JS> > JS> (2) the octet length: one or more decimal digits specifying the number > JS> of octets of the value to be used and formatted by this octet- > JS> specification. Note that the octet length can be zero. If less > JS> than this number of octets remain in the value, then the lesser > JS> number of octets are used. > JS> > JS> My reading of this is "take 254 bytes of the value and display it as a > JS> hexadecimal number". > > Hmmm... I have to admit, I'm biased by the Net-SNMP implementation of > display hint processing. But using your reading and a hint of "2d", > given the value 0x0102, you could output a decimal number for each > octet and get the output "12", but the output should be the decimal > number represented by the two octets together: 258. It does seem to be a > bit ambiguous... but the next item, (3) says the octet length is used > in interpreting "the" value... i.e. a single value, which is how we > interpret "2d" in the example I gave earlier. No, my reading matches yours. You take two bytes from the value and render the value into a decimal number. So in case 254x, you take 254 bytes and render them into hexadecimal notation. > JS> So are not both hints producing the same result? > > Definitely not in Net-SNMP. :-) But I suppose I could be convinced > that it is a bug in our processing code. Can you show by example what the difference is between repeating 4 times "1x" and say once "4x"? Perhaps I am just missing the point... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Robert.Story@cobham.com Wed Jun 30 10:22:00 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E88428C0F0 for ; Wed, 30 Jun 2010 10:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b92h6eCS7+FT for ; Wed, 30 Jun 2010 10:21:59 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4215928B56A for ; Wed, 30 Jun 2010 10:21:59 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5UHM9Ue009994; Wed, 30 Jun 2010 12:22:09 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5UHM9uG013674; Wed, 30 Jun 2010 12:22:09 -0500 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jun 2010 13:22:08 -0400 Date: Wed, 30 Jun 2010 11:44:51 -0400 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20100630114451.0dba9bc6@sparta.com> In-Reply-To: <20100630054809.GB43772@elstar.local> References: <20100629202338.5eaff6a8@sparta.com> <20100630031659.GA43495@elstar.local> <20100630011349.00ae4e73@sparta.com> <20100630054809.GB43772@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.9; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/f_vXVqJQHPoE2m/CiYLpzfo"; protocol="application/pgp-signature" X-OriginalArrivalTime: 30 Jun 2010 17:22:08.0861 (UTC) FILETIME=[C4E400D0:01CB1878] Cc: "isms@ietf.org" , Wes Hardaker Subject: Re: [Isms] SNMP-TLS-TM-MIB errata X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:22:01 -0000 --Sig_/f_vXVqJQHPoE2m/CiYLpzfo Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 30 Jun 2010 07:48:09 +0200 Juergen wrote: JS> > JS> So are not both hints producing the same result? JS> >=20 JS> > Definitely not in Net-SNMP. :-) But I suppose I could be convinced JS> > that it is a bug in our processing code. JS>=20 JS> Can you show by example what the difference is between repeating 4 JS> times "1x" and say once "4x"? Perhaps I am just missing the point... The only case that I can think of where it would make a difference for hex would be leading zeros. Given the input "0x00000004", 1x would output "00000004", while 4x would just output "4". So the Net-SNMP library uses a long value to build the value before printing it. This obviously doesn't work well for octet strings larger than 4 bytes (on 32 bit systems, 8 bytes on 64 bit systems). --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/f_vXVqJQHPoE2m/CiYLpzfo Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkwrZnkACgkQ7/fVLLY1mni+7wCfeGXr/JWoF3KYqNsgXwUYCrv4 EIoAoJ31jgkRT9zTRlIWRNBhDBjvScA9 =6OiR -----END PGP SIGNATURE----- --Sig_/f_vXVqJQHPoE2m/CiYLpzfo-- From j.schoenwaelder@jacobs-university.de Wed Jun 30 13:52:08 2010 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA5F3A6AE1 for ; Wed, 30 Jun 2010 13:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.294 X-Spam-Level: X-Spam-Status: No, score=0.294 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxs2smoKCceO for ; Wed, 30 Jun 2010 13:52:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECD473A6B1B for ; Wed, 30 Jun 2010 13:52:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71BFBC001D; Wed, 30 Jun 2010 22:52:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nJyaoi5T9n3Y; Wed, 30 Jun 2010 22:52:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2C1DC0019; Wed, 30 Jun 2010 22:52:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D77E61374561; Wed, 30 Jun 2010 22:52:13 +0200 (CEST) Date: Wed, 30 Jun 2010 22:52:13 +0200 From: Juergen Schoenwaelder To: Robert Story Message-ID: <20100630205213.GC45229@elstar.local> Mail-Followup-To: Robert Story , "isms@ietf.org" , Wes Hardaker References: <20100629202338.5eaff6a8@sparta.com> <20100630031659.GA43495@elstar.local> <20100630011349.00ae4e73@sparta.com> <20100630054809.GB43772@elstar.local> <20100630114451.0dba9bc6@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100630114451.0dba9bc6@sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" , Wes Hardaker Subject: Re: [Isms] SNMP-TLS-TM-MIB errata X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 20:52:09 -0000 On Wed, Jun 30, 2010 at 05:44:51PM +0200, Robert Story wrote: > On Wed, 30 Jun 2010 07:48:09 +0200 Juergen wrote: > JS> > JS> So are not both hints producing the same result? > JS> > > JS> > Definitely not in Net-SNMP. :-) But I suppose I could be convinced > JS> > that it is a bug in our processing code. > JS> > JS> Can you show by example what the difference is between repeating 4 > JS> times "1x" and say once "4x"? Perhaps I am just missing the point... > > The only case that I can think of where it would make a difference > for hex would be leading zeros. Given the input "0x00000004", 1x would > output "00000004", while 4x would just output "4". > > So the Net-SNMP library uses a long value to build the value before > printing it. This obviously doesn't work well for octet strings > larger than 4 bytes (on 32 bit systems, 8 bytes on 64 bit systems). Just looking at some old code I wrote. For OCTET STRINGs, I am always rendering with leading zeros. It looks like my code has an issue with a long conversion though. :-( I note that RFC 2579 is silent about leading zeros in case of OCTET STRING values. (For 'x' it might make sense to not suppress them, for 'd' and 'o' it likely makes sense to suppress them. Isn't it fun that we still find questions like this? I agree we should use the 1x format to avoid this pitfall. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103