From ietfc@btconnect.com Fri Oct 1 01:56:14 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 B3A4D3A6C0A for ; Fri, 1 Oct 2010 01:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.913 X-Spam-Level: X-Spam-Status: No, score=-0.913 tagged_above=-999 required=5 tests=[AWL=-0.728, 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 O436O2G62xc9 for ; Fri, 1 Oct 2010 01:56:13 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id 55F813A6B41 for ; Fri, 1 Oct 2010 01:56:12 -0700 (PDT) Received: from host217-44-4-171.range217-44.btcentralplus.com (HELO pc6) ([217.44.4.171]) by c2beaomr06.btconnect.com with SMTP id AIY80213; Fri, 01 Oct 2010 09:56:53 +0100 (BST) Message-ID: <005a01cb613e$218dd140$4001a8c0@gateway.2wire.net> From: "t.petch" To: "isms" , "Lee, Yiu" References: <006c01cb5f18$de6e1040$4001a8c0@gateway.2wire.net><20100928203506.GC96620@elstar.local><015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net><007d01cb5ff5$f70de3e0$4001a8c0@gateway.2wire.net> Date: Fri, 1 Oct 2010 09:39:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CA5A248.01BF, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4CA5A25B.029E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [Isms] status and future of the isms working group 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, 01 Oct 2010 08:56:14 -0000 Just a final thought, a restatement of the problem I see, lest it not yet be clear to some. The currently defined secure Transport Models require tmStateReference to be set, else a Command Responder does not know where to send a Response. The 'UDP Transport Model' is undefined, and so tmStateReference must, I think, be indeterminate. A new Security Model, XSM, which wants to be Transport Model independent has a challenge; it must set tmStateReference, to work with secure Transport Models, and ignore it, to work with UTM, without knowing what Transport Model is in use. I see this as problematic. This issue arose with RFC5591 and was found by (me) working through the section fives (and fours) to check what information was available to what when. So any I-D for a new, XSM which lacks a section five will need one creating to establish whether or not it works with existing models. Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: "t.petch" Cc: "isms" ; "Lee, Yiu" Sent: Wednesday, September 29, 2010 8:47 PM Subject: Re: status and future of the isms working group > >>>>> On Wed, 29 Sep 2010 18:47:07 +0200, "t.petch" said: > > tp> I am saying that at the least, a KSM I-D has to parallel RFC5591 > tp> (not USM), covering all the topics that that covers. It will > tp> probably specify that all the additional parameters introduced by > tp> RFC5590 are ignored, but if it says anything else, then I think we > tp> will need a UDP Transport Model. > > Sounds like a one bullet incoming request saying "ignore the > tmStateReference" solves all your problems then. (and the outgoing > doesn't need anything since by not creating a tmStateReference on the > outgoing path, you're already ignoring it). > > tp> And then there are the interactions with Kerberos; shades of VACM > tp> and RADIUS perhaps, in that the Command Responder is setting up a > tp> connection(/session/transport) to a third party, which needs > tp> specifying? > > I think I'll stop suggesting solutions as we haven't agreed to do the > work. That being said, all of the above have already been accomplished > by two independent sets of folks so I know they can be worked out. > -- > Wes Hardaker > Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Fri Oct 1 02:18:51 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 95F633A6C3B for ; Fri, 1 Oct 2010 02:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.662 X-Spam-Level: X-Spam-Status: No, score=-101.662 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] 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 Pr0eN+37gJ7Z for ; Fri, 1 Oct 2010 02:18:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 367923A6BCE for ; Fri, 1 Oct 2010 02:18:50 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE089C000C; Fri, 1 Oct 2010 11:19:37 +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 zKbUVsEjHWqc; Fri, 1 Oct 2010 11:19:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF99FC000A; Fri, 1 Oct 2010 11:19:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EFBB914FE5DA; Fri, 1 Oct 2010 11:19:06 +0200 (CEST) Date: Fri, 1 Oct 2010 11:19:06 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20101001091906.GB3991@elstar.local> Mail-Followup-To: "t.petch" , isms , "Lee, Yiu" References: <006c01cb5f18$de6e1040$4001a8c0@gateway.2wire.net> <20100928203506.GC96620@elstar.local> <015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net> <007d01cb5ff5$f70de3e0$4001a8c0@gateway.2wire.net> <005a01cb613e$218dd140$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005a01cb613e$218dd140$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: isms , "Lee, Yiu" Subject: Re: [Isms] status and future of the isms working group 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: Fri, 01 Oct 2010 09:18:51 -0000 On Fri, Oct 01, 2010 at 09:39:01AM +0200, t.petch wrote: > Just a final thought, a restatement of the problem I see, lest it not yet be > clear to some. > > The currently defined secure Transport Models require > tmStateReference to be set, else a Command Responder does not know > where to send a Response. The 'UDP Transport Model' is undefined, > and so tmStateReference must, I think, be indeterminate. A new > Security Model, XSM, which wants to be Transport Model independent > has a challenge; it must set tmStateReference, to work with secure > Transport Models, and ignore it, to work with UTM, without knowing > what Transport Model is in use. I see this as problematic. As far as I understand things, we have two types of security models - those that outsource the security processing to a secure transport model (i.e. TSM) and those that don't because the provide security services within the security model itself (i.e. USM and CSM). I am not sure how useful a security model will be that combines both types. For the sake of this discussion, I believe people what a kerberos security model (lets call it KSM) that does security processing within the security model, so it falls into the same class as USM and CSM. So even if there would be a problem, it will not be any worse than what we have with USM and CSM. > This issue arose with RFC5591 and was found by (me) working through > the section fives (and fours) to check what information was > available to what when. So any I-D for a new, XSM which lacks a > section five will need one creating to establish whether or not it > works with existing models. I still do not see where the problem is. For a secure transport model, the tmStateReference needs to be available. For other transports, I believe you can ignore it. /js PS: The SNMP code I have seen always knows how to send a response back to where the request came from. The RFC3411 architecture decoupled things to a very large degree while most implementations are much tighter integrated. -- 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 Fri Oct 1 02:31:42 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 2DEA53A6C4E for ; Fri, 1 Oct 2010 02:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.962 X-Spam-Level: X-Spam-Status: No, score=-101.962 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 HoeJbX2s-Gdq for ; Fri, 1 Oct 2010 02:31:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 962A43A68A0 for ; Fri, 1 Oct 2010 02:31:40 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEE8FC000C; Fri, 1 Oct 2010 11:32:24 +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 nFhAG7xFpjcs; Fri, 1 Oct 2010 11:32:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C409C000A; Fri, 1 Oct 2010 11:32:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D34FD14FE6E6; Fri, 1 Oct 2010 11:31:52 +0200 (CEST) Date: Fri, 1 Oct 2010 11:31:52 +0200 From: Juergen Schoenwaelder To: "Yiu L. Lee" Message-ID: <20101001093152.GC3991@elstar.local> Mail-Followup-To: "Yiu L. Lee" , "isms@ietf.org" References: <015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "isms@ietf.org" Subject: Re: [Isms] status and future of the isms working group 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: Fri, 01 Oct 2010 09:31:42 -0000 On Wed, Sep 29, 2010 at 03:13:17PM +0200, Yiu L. Lee wrote: > Raj and I will continue to work hard to make sure to address all the > questions and issues in the mailing list. Please don't stop giving > us feedback! Section 3.2 talks about the PAC and I think some discussion is needed how that relates to SNMP's notion of a securityLevel and any other information that goes into the isAccessAllowed() ASI. I also like to better understand the structure of the resulting exchange. My understand of Kerberos is that KRB_AP_REQ and KRB_AP_REP are the exchange to establish a Kerberos session key. My reading of the ID is that you are not really interested in the session key but you only want to use it for a single SNMP request/response interaction. If my reading is correct, I would like to know what Kerberos people think about such an approach. I would also like to know the crypto performance impact of this if you have to walk a longer table using multiple SNMP request/response interactions. I am also missing a discussion how unconfirmed notifications (traps) are handled. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Fri Oct 1 06:16: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 5BA223A6E98 for ; Fri, 1 Oct 2010 06:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.006 X-Spam-Level: X-Spam-Status: No, score=-102.006 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] 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 tHG6qUmzr3gL for ; Fri, 1 Oct 2010 06:16:09 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id 6FB763A6D8A for ; Fri, 1 Oct 2010 06:16:09 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta12.westchester.pa.mail.comcast.net with comcast id DNZn1f00J0bG4ec5CRGyVn; Fri, 01 Oct 2010 13:16:58 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta03.westchester.pa.mail.comcast.net with comcast id DRGx1f00D2JQnJT3PRGxyT; Fri, 01 Oct 2010 13:16:58 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'t.petch'" References: <006c01cb5f18$de6e1040$4001a8c0@gateway.2wire.net><20100928203506.GC96620@elstar.local><015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net><007d01cb5ff5$f70de3e0$4001a8c0@gateway.2wire.net><005a01cb613e$218dd140$4001a8c0@gateway.2wire.net> <20101001091906.GB3991@elstar.local> Date: Fri, 1 Oct 2010 09:15:22 -0400 Message-ID: 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.5994 Thread-index: ActhSceirBkOywI9QsuirFVQUEWHrgAHn+3Q In-Reply-To: <20101001091906.GB3991@elstar.local> Cc: 'isms' , "'Lee, Yiu'" Subject: Re: [Isms] status and future of the isms working group 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, 01 Oct 2010 13:16:11 -0000 I concur. You need security parameters (security name, security level, etc.) established between two SNMP security model instances, and currently can do that 1) by including the information in the SNMP message, so a message-aware security model can generate the security parameters itself (USM, CSM) or 2) getting information from a security-providing transport (SSH, TLS), having a transport-security-aware transport model algothmically convert the transport security parameters into SNMP security parameters in tmStateReference form, and passing them to a transport-security-aware (tmStateReference-aware) SNMP security model. I haven't studied the KSM(?) proposal to see whether the data will be passed through a tmStateReference or in the message itself. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Friday, October 01, 2010 5:19 AM > To: t.petch > Cc: isms; Lee, Yiu > Subject: Re: [Isms] status and future of the isms working group > > On Fri, Oct 01, 2010 at 09:39:01AM +0200, t.petch wrote: > > Just a final thought, a restatement of the problem I see, > lest it not > > yet be clear to some. > > > > The currently defined secure Transport Models require > tmStateReference > > to be set, else a Command Responder does not know where to send a > > Response. The 'UDP Transport Model' is undefined, and so > > tmStateReference must, I think, be indeterminate. A new Security > > Model, XSM, which wants to be Transport Model independent has a > > challenge; it must set tmStateReference, to work with > secure Transport > > Models, and ignore it, to work with UTM, without knowing what > > Transport Model is in use. I see this as problematic. > > As far as I understand things, we have two types of security > models - those that outsource the security processing to a > secure transport model (i.e. TSM) and those that don't > because the provide security services within the security > model itself (i.e. USM and CSM). I am not sure how useful a > security model will be that combines both types. For the sake > of this discussion, I believe people what a kerberos security > model (lets call it KSM) that does security processing within > the security model, so it falls into the same class as USM and CSM. > > So even if there would be a problem, it will not be any worse > than what we have with USM and CSM. > > > This issue arose with RFC5591 and was found by (me) working through > > the section fives (and fours) to check what information was > available > > to what when. So any I-D for a new, XSM which lacks a section five > > will need one creating to establish whether or not it works with > > existing models. > > I still do not see where the problem is. For a secure > transport model, the tmStateReference needs to be available. > For other transports, I believe you can ignore it. > > /js > > PS: The SNMP code I have seen always knows how to send a response back > to where the request came from. The RFC3411 architecture decoupled > things to a very large degree while most implementations are much > tighter integrated. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From adonati@motorola.com Fri Oct 1 09:50: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 DBA463A6CC0 for ; Fri, 1 Oct 2010 09:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZnlruF7qKDB for ; Fri, 1 Oct 2010 09:50:26 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id E95F93A6AED for ; Fri, 1 Oct 2010 09:50:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1285951863!33892974!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17214 invoked from network); 1 Oct 2010 16:51:03 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2010 16:51:03 -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 o91Gp2cI015851 for ; Fri, 1 Oct 2010 09:51:02 -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 o91Gp23X028222 for ; Fri, 1 Oct 2010 11:51:02 -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 o91Gp2wn028219 for ; Fri, 1 Oct 2010 11:51:02 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2010 12:50:40 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] status and future of the isms working group Thread-Index: ActhSceirBkOywI9QsuirFVQUEWHrgAHn+3QAAfKEeA= References: <006c01cb5f18$de6e1040$4001a8c0@gateway.2wire.net><20100928203506.GC96620@elstar.local><015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net><007d01cb5ff5$f70de3e0$4001a8c0@gateway.2wire.net><005a01cb613e$218dd140$4001a8c0@gateway.2wire.net><20101001091906.GB3991@elstar.local> From: "Donati Andrew-MGIA0477" To: "David Harrington" , "Juergen Schoenwaelder" , "t.petch" X-CFilter-Loop: Reflected Cc: isms , "Lee, Yiu" Subject: Re: [Isms] status and future of the isms working group 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, 01 Oct 2010 16:50:27 -0000 Section 2 in http://datatracker.ietf.org/doc/rfc5590/ presents a good discussion on using either of these approaches. An important question to consider is which method will be the easiest for operators to implement. If operators can easily leverage their existing Kerberos infrastructure using the approach described in item 1, it can certainly be considered a viable option.=20 -- Andy Donati -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of David Harrington Sent: Friday, October 01, 2010 9:15 AM To: 'Juergen Schoenwaelder'; 't.petch' Cc: 'isms'; 'Lee, Yiu' Subject: Re: [Isms] status and future of the isms working group > You need security parameters (security name, security level, etc.) > established between two SNMP security model instances, and currently can do that > 1) by including the information in the SNMP message, so a message-aware security > model can generate the security parameters itself (USM, CSM) or > 2) getting information from a security-providing transport (SSH, TLS), having > a transport-security-aware transport model algothmically convert the transport > security parameters into SNMP security parameters in tmStateReference form, > and passing them to a transport-security-aware (tmStateReference-aware) SNMP security model. > I haven't studied the KSM(?) proposal to see whether the data will be > passed through a tmStateReference or in the message itself.=20 > dbh=20 From jhutz@cmu.edu Fri Oct 1 14:08:02 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 8CB533A6CEF for ; Fri, 1 Oct 2010 14:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 pOzi-SAOr9Te for ; Fri, 1 Oct 2010 14:08:01 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 8BBE83A6B3F for ; Fri, 1 Oct 2010 14:08:01 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o91L8ljt023609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2010 17:08:48 -0400 (EDT) Date: Fri, 01 Oct 2010 17:03:14 -0400 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , "Yiu L. Lee" Message-ID: <747CFA17760D0F340DE54797@minbar.fac.cs.cmu.edu> In-Reply-To: <24381_1285925553_o919WV4c002843_20101001093152.GC3991@elstar.local> References: <015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net> <24381_1285925553_o919WV4c002843_20101001093152.GC3991@elstar.local> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] status and future of the isms working group 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, 01 Oct 2010 21:08:02 -0000 --On Friday, October 01, 2010 11:31:52 AM +0200 Juergen Schoenwaelder wrote: > Section 3.2 talks about the PAC and I think some discussion is needed > how that relates to SNMP's notion of a securityLevel and any other > information that goes into the isAccessAllowed() ASI. > > I also like to better understand the structure of the resulting > exchange. My understand of Kerberos is that KRB_AP_REQ and KRB_AP_REP > are the exchange to establish a Kerberos session key. My reading of > the ID is that you are not really interested in the session key but > you only want to use it for a single SNMP request/response > interaction. If my reading is correct, I would like to know what > Kerberos people think about such an approach. I would also like to > know the crypto performance impact of this if you have to walk a > longer table using multiple SNMP request/response interactions. I haven't read this document yet, so I can't comment on its use of Kerberos. However, if the WG decides to adopt the work, I'll be happy to review it with that in mind. -- Jeff From j.schoenwaelder@jacobs-university.de Fri Oct 1 14:32:13 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 5CB583A6E43 for ; Fri, 1 Oct 2010 14:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 u-r2dH+cRzZ2 for ; Fri, 1 Oct 2010 14:32:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7BC533A6D91 for ; Fri, 1 Oct 2010 14:30:44 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 201AAC0076; Fri, 1 Oct 2010 23:31:33 +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 ntizXvPixK1M; Fri, 1 Oct 2010 23:31:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26CC3C0062; Fri, 1 Oct 2010 23:31:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B492414FF8E3; Fri, 1 Oct 2010 23:30:57 +0200 (CEST) Date: Fri, 1 Oct 2010 23:30:57 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20101001213057.GA5711@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , "Yiu L. Lee" , "isms@ietf.org" References: <015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net> <24381_1285925553_o919WV4c002843_20101001093152.GC3991@elstar.local> <747CFA17760D0F340DE54797@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <747CFA17760D0F340DE54797@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "isms@ietf.org" , "Yiu L. Lee" Subject: Re: [Isms] status and future of the isms working group 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: Fri, 01 Oct 2010 21:32:13 -0000 On Fri, Oct 01, 2010 at 11:03:14PM +0200, Jeffrey Hutzelman wrote: > I haven't read this document yet, so I can't comment on its use of > Kerberos. However, if the WG decides to adopt the work, I'll be happy to > review it with that in mind. Jeff, it might help us and the authors to get some early feedback whether the approach itself is leading into the right direction. So if you have some time available now... The core of the proposal is section 3, about 3 pages of text to read: draft-pejaver-ismi-kerberos-00 (The name is confusing since they misspelled isms.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yiu_lee@cable.comcast.com Fri Oct 1 14:35: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 C1CC43A6D01 for ; Fri, 1 Oct 2010 14:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=3.196, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] 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 vJLp13ML47sa for ; Fri, 1 Oct 2010 14:35:14 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 7EBB83A6B53 for ; Fri, 1 Oct 2010 14:35:13 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.95482702; Fri, 01 Oct 2010 17:35:52 -0400 Received: from PACDCEXCMB04.cable.comcast.com (24.40.15.86) by PACDCEXHUB02.cable.comcast.com (24.40.55.41) with Microsoft SMTP Server id 14.1.218.12; Fri, 1 Oct 2010 17:35:52 -0400 Received: from 24.40.15.86 ([24.40.15.86]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Oct 2010 21:35:50 +0000 References: <015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net> <24381_1285925553_o919WV4c002843_20101001093152.GC3991@elstar.local> <747CFA17760D0F340DE54797@minbar.fac.cs.cmu.edu> <20101001213057.GA5711@elstar.local> Message-ID: From: "Lee, Yiu" To: Juergen Schoenwaelder In-Reply-To: <20101001213057.GA5711@elstar.local> Content-Type: text/plain; charset="us-ascii" thread-topic: [Isms] status and future of the isms working group thread-index: ActhsJ3Y+enxjLycRBaCWHyL3yDQIA== Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (iPad Mail 7B367) Date: Fri, 1 Oct 2010 17:37:21 -0400 Cc: isms@ietf.org, Jeffrey Hutzelman Subject: Re: [Isms] status and future of the isms working group 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, 01 Oct 2010 21:35:16 -0000 Sorry for mis-spelled the WG name. We will fix it in next revision. We = are working on the new revision which tries to capture all the questions = posting on the list. Mostly importantly, we would like to listen to the = group and make sure we are heading to the right direction. =20 On Oct 1, 2010, at 5:31 PM, "Juergen Schoenwaelder" = wrote: > On Fri, Oct 01, 2010 at 11:03:14PM +0200, Jeffrey Hutzelman wrote: >=20 >> I haven't read this document yet, so I can't comment on its use of=20 >> Kerberos. However, if the WG decides to adopt the work, I'll be = happy to=20 >> review it with that in mind. >=20 > Jeff, >=20 > it might help us and the authors to get some early feedback whether > the approach itself is leading into the right direction. So if you > have some time available now... The core of the proposal is section 3, > about 3 pages of text to read: >=20 > draft-pejaver-ismi-kerberos-00 >=20 > (The name is confusing since they misspelled isms.) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From rajaram_pejaver@cable.comcast.com Mon Oct 4 11:38: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 EB7193A708C for ; Mon, 4 Oct 2010 11:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.949 X-Spam-Level: X-Spam-Status: No, score=-107.949 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 etX5KgcIOi7k for ; Mon, 4 Oct 2010 11:38:53 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 5425A3A70A9 for ; Mon, 4 Oct 2010 11:38:14 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.96059684; Mon, 04 Oct 2010 14:38:26 -0400 Received: from pacdcexcmb05.cable.comcast.com (24.40.15.116) by pacdcexhub03.cable.comcast.com (24.40.55.40) with Microsoft SMTP Server id 14.1.218.12; Mon, 4 Oct 2010 14:38:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Oct 2010 14:38:20 -0400 Message-ID: <029A504294520A4F84113D5C45B65A5202E30180@pacdcexcmb05.cable.comcast.com> In-Reply-To: <20101001093152.GC3991@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] status and future of the isms working group Thread-Index: ActhS5TrV9Sx8zEjSny8fAA5S8yT3AAH9d1w References: <015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net> <20101001093152.GC3991@elstar.local> From: "Pejaver, Rajaram" To: Juergen Schoenwaelder Cc: isms@ietf.org Subject: Re: [Isms] status and future of the isms working group 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: Mon, 04 Oct 2010 18:38:57 -0000 > Section 3.2 talks about the PAC and I think some discussion is needed > how that relates to SNMP's notion of a securityLevel and any other > information that goes into the isAccessAllowed() ASI. The PAC can be thought of as having exactly the same syntax & semantics as the role information retrieved from RADIUS in draft-ietf-isms-radius-vacm. The managed device should handle it in exactly the same way. I called it a PAC only because of where it is placed in the Kerberos ticket. It probably comes from RADIUS, though it takes a different path: - in draft-ietf-isms-radius-vacm, RADIUS delivers this directly to the managed device. - in the proposed ID, RADIUS delivers it to Kerberos, which encapsulates it securely in a ticket, which is given to the NMS, who presents it to the managed device. The semantics of securityLevel should remain unchanged: - authNoPriv =3D PDU not encrypted - authPriv =3D PDU is encrypted All this should be explained better in the next revision of the ID. > I also like to better understand the structure of the resulting > exchange. My understand of Kerberos is that KRB_AP_REQ and KRB_AP_REP > are the exchange to establish a Kerberos session key. My reading of > the ID is that you are not really interested in the session key but > you only want to use it for a single SNMP request/response > interaction. If my reading is correct, I would like to know what > Kerberos people think about such an approach. I would also like to > know the crypto performance impact of this if you have to walk a > longer table using multiple SNMP request/response interactions. We are interested in the session key as it is needed to encrypt the SNMP PDU. The same ticket+sessionkey will be used if there are multiple SNMP interactions between the NMS (Manager) & the managed device. > I am also missing a discussion how unconfirmed notifications (traps) > are handled. If the managed device needs to send traps securely, it would need to get a Kerberos ticket and a session key for each destination NMS (typically one). This can be done when the device initializes. Thanks for your comments. We will incorporate all the questions and suggestions into the next version of the draft. =20 Regards Rajaram Pejaver From j.schoenwaelder@jacobs-university.de Mon Oct 4 12:41: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 5995B3A7072 for ; Mon, 4 Oct 2010 12:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.974 X-Spam-Level: X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 pwUn5gYSiH2P for ; Mon, 4 Oct 2010 12:41:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A0BCD3A6E6B for ; Mon, 4 Oct 2010 12:41:14 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1102C0030; Mon, 4 Oct 2010 21:42:09 +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 y93g8DuHoBbU; Mon, 4 Oct 2010 21:42: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 0EC3FC001C; Mon, 4 Oct 2010 21:42:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 425B0150AA93; Mon, 4 Oct 2010 21:41:37 +0200 (CEST) Date: Mon, 4 Oct 2010 21:41:36 +0200 From: Juergen Schoenwaelder To: "Pejaver, Rajaram" Message-ID: <20101004194134.GA61887@elstar.local> Mail-Followup-To: "Pejaver, Rajaram" , "isms@ietf.org" References: <015901cb5faa$a1f5a320$4001a8c0@gateway.2wire.net> <20101001093152.GC3991@elstar.local> <029A504294520A4F84113D5C45B65A5202E30180@pacdcexcmb05.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <029A504294520A4F84113D5C45B65A5202E30180@pacdcexcmb05.cable.comcast.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "isms@ietf.org" Subject: Re: [Isms] status and future of the isms working group 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: Mon, 04 Oct 2010 19:41:17 -0000 On Mon, Oct 04, 2010 at 08:38:20PM +0200, Pejaver, Rajaram wrote: > > > Section 3.2 talks about the PAC and I think some discussion is needed > > how that relates to SNMP's notion of a securityLevel and any other > > information that goes into the isAccessAllowed() ASI. > > The PAC can be thought of as having exactly the same syntax & semantics > as the role information retrieved from RADIUS in > draft-ietf-isms-radius-vacm. > The managed device should handle it in exactly the same way. > I called it a PAC only because of where it is placed in the Kerberos > ticket. > It probably comes from RADIUS, though it takes a different path: > - in draft-ietf-isms-radius-vacm, RADIUS delivers this directly to the > > managed device. > - in the proposed ID, RADIUS delivers it to Kerberos, which > encapsulates > it securely in a ticket, which is given to the NMS, who presents it > to > the managed device. > > The semantics of securityLevel should remain unchanged: > - authNoPriv = PDU not encrypted > - authPriv = PDU is encrypted > > All this should be explained better in the next revision of the ID. The text needs to be more concrete and precise. Right now, the text in 3.2 consists of an acronym (PAC) and it says that "its structure and semantics may vary depending on the authorization model of the managed device". SNMP has a very clear authorization model so it should not be hard to be precise. > > I also like to better understand the structure of the resulting > > exchange. My understand of Kerberos is that KRB_AP_REQ and KRB_AP_REP > > are the exchange to establish a Kerberos session key. My reading of > > the ID is that you are not really interested in the session key but > > you only want to use it for a single SNMP request/response > > interaction. If my reading is correct, I would like to know what > > Kerberos people think about such an approach. I would also like to > > know the crypto performance impact of this if you have to walk a > > longer table using multiple SNMP request/response interactions. > > We are interested in the session key as it is needed to encrypt the SNMP > PDU. > The same ticket+sessionkey will be used if there are multiple SNMP > interactions > between the NMS (Manager) & the managed device. So do you establish session state? To me, it seems you do not but instead you pull the session key out of the ticket in each request/reply interaction. If my understanding is correct, I like to hear from Kerberos people whether they think this is a good approach. > > I am also missing a discussion how unconfirmed notifications (traps) > > are handled. > > If the managed device needs to send traps securely, it would need to > get a Kerberos ticket and a session key for each destination NMS > (typically one). This can be done when the device initializes. > > Thanks for your comments. We will incorporate all the questions and > suggestions into the next version of the draft. I am looking forward to the next revision. Please be reminded of the upcoming deadlines: 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (24:00 UTC) 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT (24:00 UTC) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yiu_lee@cable.comcast.com Mon Oct 4 12:43:35 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 ACC213A7073 for ; Mon, 4 Oct 2010 12:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.396 X-Spam-Level: X-Spam-Status: No, score=-106.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] 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 OgQnb763A5QE for ; Mon, 4 Oct 2010 12:43:34 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id C9DFE3A707E for ; Mon, 4 Oct 2010 12:43:33 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.96092380; Mon, 04 Oct 2010 15:44:28 -0400 Received: from PACDCEXCMB04.cable.comcast.com (24.40.15.86) by PACDCEXHUB02.cable.comcast.com (24.40.55.41) with Microsoft SMTP Server id 14.1.218.12; Mon, 4 Oct 2010 15:44:28 -0400 Received: from 192.35.167.84 ([192.35.167.84]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server legacywebmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 Oct 2010 19:44:11 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Mon, 4 Oct 2010 15:44:08 -0400 From: "Yiu L. Lee" To: Juergen Schoenwaelder , "Pejaver, Rajaram" Message-ID: Thread-Topic: [Isms] status and future of the isms working group Thread-Index: Actj/IJZ3aQCBZEnDU2WDWlwL2HwTQ== In-Reply-To: <20101004194134.GA61887@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: "isms@ietf.org" Subject: Re: [Isms] status and future of the isms working group 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: Mon, 04 Oct 2010 19:43:35 -0000 Hi Juergen, Thanks for the date reminder. I will submit the old one with the right WG name. Then we will submit the revision sometime next week. Thanks, Yiu On 10/4/10 3:41 PM, "Juergen Schoenwaelder" wrote: > On Mon, Oct 04, 2010 at 08:38:20PM +0200, Pejaver, Rajaram wrote: >> >>> Section 3.2 talks about the PAC and I think some discussion is needed >>> how that relates to SNMP's notion of a securityLevel and any other >>> information that goes into the isAccessAllowed() ASI. >> >> The PAC can be thought of as having exactly the same syntax & semantics >> as the role information retrieved from RADIUS in >> draft-ietf-isms-radius-vacm. >> The managed device should handle it in exactly the same way. >> I called it a PAC only because of where it is placed in the Kerberos >> ticket. >> It probably comes from RADIUS, though it takes a different path: >> - in draft-ietf-isms-radius-vacm, RADIUS delivers this directly to the >> >> managed device. >> - in the proposed ID, RADIUS delivers it to Kerberos, which >> encapsulates >> it securely in a ticket, which is given to the NMS, who presents it >> to >> the managed device. >> >> The semantics of securityLevel should remain unchanged: >> - authNoPriv = PDU not encrypted >> - authPriv = PDU is encrypted >> >> All this should be explained better in the next revision of the ID. > > The text needs to be more concrete and precise. Right now, the text in > 3.2 consists of an acronym (PAC) and it says that "its structure and > semantics may vary depending on the authorization model of the managed > device". SNMP has a very clear authorization model so it should not be > hard to be precise. > >>> I also like to better understand the structure of the resulting >>> exchange. My understand of Kerberos is that KRB_AP_REQ and KRB_AP_REP >>> are the exchange to establish a Kerberos session key. My reading of >>> the ID is that you are not really interested in the session key but >>> you only want to use it for a single SNMP request/response >>> interaction. If my reading is correct, I would like to know what >>> Kerberos people think about such an approach. I would also like to >>> know the crypto performance impact of this if you have to walk a >>> longer table using multiple SNMP request/response interactions. >> >> We are interested in the session key as it is needed to encrypt the SNMP >> PDU. >> The same ticket+sessionkey will be used if there are multiple SNMP >> interactions >> between the NMS (Manager) & the managed device. > > So do you establish session state? To me, it seems you do not but > instead you pull the session key out of the ticket in each > request/reply interaction. If my understanding is correct, I like to > hear from Kerberos people whether they think this is a good approach. > >>> I am also missing a discussion how unconfirmed notifications (traps) >>> are handled. >> >> If the managed device needs to send traps securely, it would need to >> get a Kerberos ticket and a session key for each destination NMS >> (typically one). This can be done when the device initializes. >> >> Thanks for your comments. We will incorporate all the questions and >> suggestions into the next version of the draft. > > I am looking forward to the next revision. Please be reminded of the > upcoming deadlines: > > 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) > submission by 17:00 PT (24:00 UTC) > > 2010-10-25 (Monday): Internet Draft final submission cut-off > by 17:00 PT (24:00 UTC) > > /js From saperia@jdscons.com Mon Sep 20 10:43:23 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 229F33A6AD2; Mon, 20 Sep 2010 10:43:23 -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 jwyB+t5Zs5dg; Mon, 20 Sep 2010 10:43:21 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by core3.amsl.com (Postfix) with ESMTP id 946623A67D1; Mon, 20 Sep 2010 10:43:21 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id o8KHhhqe028849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Sep 2010 12:43:44 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jon Saperia X-Priority: 3 In-Reply-To: <003c01cb58e5$e95359e0$6801a8c0@oemcomputer> Date: Mon, 20 Sep 2010 13:43:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4FB2A2E7-04E3-4604-B709-36A0E2F809B2@jdscons.com> References: <20100917082039.GA47046@elstar.local> <20100917101102.GA47610@elstar.local><4C9371A6.6040106@cisco.com><000b01cb5895$868c3ca0$4001a8c0@gateway.2wire.net> <0b4b01cb58aa$4cd4f320$4001a8c0@gateway.2wire.net> <003c01cb58e5$e95359e0$6801a8c0@oemcomputer> To: "Randy Presuhn" X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Mon, 04 Oct 2010 16:56:31 -0700 Cc: isms@ietf.org, ops-area@ietf.org Subject: Re: [Isms] [OPS-AREA] status and future of the isms working group 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: Mon, 20 Sep 2010 17:43:23 -0000 I could not agree more.=20 I would add that additional protocol/architecture/framework on any of = the management infrastructures we have does not address the key point I = took from Randy's post. What we need are widely implemented objects = (however you want to call the structures) that give real visibility into = what is going on in the devices and networks. That has always been the = problem and until we address that who cares how we transport the data. I = would settle for RFC2549, if it contained the right information. /jon On Sep 20, 2010, at 1:04 PM, Randy Presuhn wrote: > Hi - >=20 >> From: "t.petch" > ... >> I think that our resources are limited, and tend to decay with the = age of a >> working group, so I would rather see them applied elsewhere. I look = back at the >> effort that went into RFC3411, over many years, and yet it fell at = the first >> hurdle, not accommodating the move of security from deep inside the = engine to >> off the bottom of the radar; why should we do any better this time? > ... >=20 > The problem as I see it was that RFC3411 was intended to be the glue > describing how a particular set of specifications fit together, *not* = as > *the* architecture for all future SNMP work. *Requiring* extensions, > additions, and embellishments to adhere to that architecture is in > my opinion a huge mistake. =46rom my perspective, the real problem > addressed by RFC 3411 was that some of the preceding proposals > for securing SNMP had so many convolutions and interactions that > a lot of folks had trouble wrapping their heads around them. The > modularity brought by RFC 3411 was modularity of *specification*, > not necessarily implementation. The ASIs were rather controversial > because folks were (rightly, in retrospect) concerned that they would > be understood in a prescriptive sense, rather than descriptive sense > in which they were intended. >=20 > More importantly, I think focusing energy on this "problem" (which is > tempting because it's something we think we understand) would be > a huge distraction from the *real* problem: the kinds of information = models > this infrastructure should provide access to. If the information = models > can't support the high-value functions administrators / operators = need, > then embellishing the protocol engine architecture is a waste of time. >=20 > Randy >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area >=20 From wjhns1@hardakers.net Tue Oct 5 13:55:19 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 1A9E03A6FDE for ; Tue, 5 Oct 2010 13:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 vJGbXbIkmZlU for ; Tue, 5 Oct 2010 13:55:16 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id E21223A7015 for ; Tue, 5 Oct 2010 13:55:15 -0700 (PDT) Received: from localhost (eth-0-22-fa-ff-17-4c.dhcp.nanog.merit.net [192.35.167.127]) by mail.hardakers.net (Postfix) with ESMTPSA id A12FA980D3 for ; Tue, 5 Oct 2010 13:55:52 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Tue, 05 Oct 2010 13:55:51 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [Isms] Next steps about the next steps 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, 05 Oct 2010 20:55:19 -0000 So, I'm willing to draft up charter text that includes items for: - TLSTM to draft - KSM (But I don't want to do it until the chairs say they're willing to potentially accept it ;-) -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Tue Oct 5 15:03:51 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 D47F03A6FF7 for ; Tue, 5 Oct 2010 15:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 7h9yTa2Vd3ex for ; Tue, 5 Oct 2010 15:03:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 52FE43A6F27 for ; Tue, 5 Oct 2010 15:03:49 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E2CEC003F; Wed, 6 Oct 2010 00:04:47 +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 VkMjCvcNbgMd; Wed, 6 Oct 2010 00:04:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A003C0016; Wed, 6 Oct 2010 00:04:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A0D31510772; Wed, 6 Oct 2010 00:04:17 +0200 (CEST) Date: Wed, 6 Oct 2010 00:04:17 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20101005220416.GA49219@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" , Russ Mundy References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "isms@ietf.org" , Russ Mundy Subject: Re: [Isms] Next steps about the next steps 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, 05 Oct 2010 22:03:51 -0000 On Tue, Oct 05, 2010 at 10:55:51PM +0200, Wes Hardaker wrote: > I'm willing to draft up charter text that includes items for: > > - TLSTM to draft > - KSM > > (But I don't want to do it until the chairs say they're willing to > potentially accept it ;-) Here is my view on these two items: - Concerning the advancement of TLSTM plus related specifications to Draft Standard, I first checked with the ADs because some of these specifications will have normative dependencies to e.g. TLS and DTLS, which are likely going to remain Proposed Standards. The ADs told me that they are willing to defend this in the IESG, so this concern has been cleared. Since we also seem to have the necessary human resources, I am supportive to undertake this work. - Concerning KSM I like to see a revised ID that better details the proposal and brings it more inline with the way we happen to write SNMP security models. Once an updated ID is available, I like to have some feedback in particular from Kerberos experts about the approach taken etc. In short, I like to better understand the technical details and the potential pitfalls, which is also needed in order to set realistic milestones. Given that the next IETF meeting is coming up relatively soon, it might make sense to discuss KSM in some technical detail in Beijing before we execute the formal rechartering procedure through the IESG. Russ, anything you like to add? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Tue Oct 5 15:56: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 ADBCB3A6EB1 for ; Tue, 5 Oct 2010 15:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 yFxsMKrZ86Dc for ; Tue, 5 Oct 2010 15:56:08 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D08CB3A6E8C for ; Tue, 5 Oct 2010 15:56:08 -0700 (PDT) Received: from localhost (eth-0-22-fa-ff-17-4c.dhcp.nanog.merit.net [192.35.167.127]) by mail.hardakers.net (Postfix) with ESMTPSA id 85AD698104; Tue, 5 Oct 2010 15:56:45 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20101005220416.GA49219@elstar.local> Date: Tue, 05 Oct 2010 15:56:43 -0700 In-Reply-To: <20101005220416.GA49219@elstar.local> (Juergen Schoenwaelder's message of "Wed, 6 Oct 2010 00:04:17 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "isms@ietf.org" , Russ Mundy Subject: Re: [Isms] Next steps about the next steps 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, 05 Oct 2010 22:56:09 -0000 >>>>> On Wed, 6 Oct 2010 00:04:17 +0200, Juergen Schoenwaelder said: JS> - Concerning KSM I like to see a revised ID that better details the JS> proposal and brings it more inline with the way we happen to write JS> SNMP security models. I happened to be in the same room as one of the authors today and believe they're planning on a very-near-term republication. Hopefully that'll occur. Thanks for the note and I'm glad that everyone agrees the 595[0,1,3] advancement is a good thing. JS> Given that the next IETF meeting is coming up relatively soon, it JS> might make sense to discuss KSM in some technical detail in Beijing JS> before we execute the formal rechartering procedure through the IESG. I agree that's a possibility, but I'd rather see the charter hammered out on the list and done with sooner so we can move to just technical discussions on the list and at the meeting (which now looks like it should be held) on the technical issues in an effort to move it forward. -- Wes Hardaker Cobham Analytic Solutions From mundy@tislabs.com Tue Oct 5 20:44:49 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 901E43A6D77 for ; Tue, 5 Oct 2010 20:44:49 -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 XGFcush4wdEp for ; Tue, 5 Oct 2010 20:44:48 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0C83E3A6D42 for ; Tue, 5 Oct 2010 20:44:47 -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 o963jkGp003929; Tue, 5 Oct 2010 22:45:46 -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 o963jjau008246; Tue, 5 Oct 2010 22:45:46 -0500 Received: from garfield.home.tislabs.com ([68.33.140.25]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Oct 2010 23:45:44 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by garfield.home.tislabs.com (Postfix) with ESMTP id A8E71117C027; Tue, 5 Oct 2010 23:45:43 -0400 (EDT) Date: Tue, 5 Oct 2010 23:45:42 -0400 From: mundy@tislabs.com To: Juergen Schoenwaelder Message-ID: <20101005234542790778.99347635@tislabs.com> In-Reply-To: <20101005220416.GA49219@elstar.local> References: <20101005220416.GA49219@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.10 X-OriginalArrivalTime: 06 Oct 2010 03:45:45.0459 (UTC) FILETIME=[F4FD8430:01CB6508] Cc: mundy@sparta.com, Russ Mundy , "isms@ietf.org" Subject: Re: [Isms] Next steps about the next steps 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, 06 Oct 2010 03:44:49 -0000 On Wed, 6 Oct 2010 00:04:17 +0200, Juergen Schoenwaelder wrote: > On Tue, Oct 05, 2010 at 10:55:51PM +0200, Wes Hardaker wrote: > >> I'm willing to draft up charter text that includes items for: >> >> - TLSTM to draft >> - KSM >> >> (But I don't want to do it until the chairs say they're willing to >> potentially accept it ;-) > > Here is my view on these two items: > > - Concerning the advancement of TLSTM plus related specifications to > Draft Standard, I first checked with the ADs because some of these > specifications will have normative dependencies to e.g. TLS and > DTLS, which are likely going to remain Proposed Standards. The ADs > told me that they are willing to defend this in the IESG, so this > concern has been cleared. Since we also seem to have the necessary > human resources, I am supportive to undertake this work. > > - Concerning KSM I like to see a revised ID that better details the > proposal and brings it more inline with the way we happen to write > SNMP security models. Once an updated ID is available, I like to > have some feedback in particular from Kerberos experts about the > approach taken etc. In short, I like to better understand the > technical details and the potential pitfalls, which is also needed > in order to set realistic milestones. > > Given that the next IETF meeting is coming up relatively soon, it > might make sense to discuss KSM in some technical detail in Beijing > before we execute the formal rechartering procedure through the IESG. > > Russ, anything you like to add? This sounds like a good approach. In think advancement TLSTM and related specs is pretty straight forward. We do need the new KSN spec as well as making sure there is sufficient interest and energy to work it. Russ > > /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 Wed Oct 6 04:34:01 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 A95223A7114 for ; Wed, 6 Oct 2010 04:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.981 X-Spam-Level: X-Spam-Status: No, score=-101.981 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 mGTszD29yfBj for ; Wed, 6 Oct 2010 04:33:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B29C63A6EFE for ; Wed, 6 Oct 2010 04:33:45 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37E1FC003F; Wed, 6 Oct 2010 13:33:18 +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 6QJJWzcyY+UG; Wed, 6 Oct 2010 13:33:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57E89C0034; Wed, 6 Oct 2010 13:33:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B2601514E6C; Wed, 6 Oct 2010 13:32:48 +0200 (CEST) Date: Wed, 6 Oct 2010 13:32:47 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20101006113247.GA53034@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" , Russ Mundy References: <20101005220416.GA49219@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "isms@ietf.org" , Russ Mundy Subject: Re: [Isms] Next steps about the next steps 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, 06 Oct 2010 11:34:01 -0000 On Wed, Oct 06, 2010 at 12:56:43AM +0200, Wes Hardaker wrote: > JS> Given that the next IETF meeting is coming up relatively soon, it > JS> might make sense to discuss KSM in some technical detail in Beijing > JS> before we execute the formal rechartering procedure through the IESG. > > I agree that's a possibility, but I'd rather see the charter hammered > out on the list and done with sooner so we can move to just technical > discussions on the list and at the meeting (which now looks like it > should be held) on the technical issues in an effort to move it forward. I assume the authors do already work on the technical issues, which is great. However, since milestones are part of the WG charters, I like to get a better understanding whether there are any technical obstacles that might causes this work to take years instead of a few months. This is why I like to have early feedback from Kerberos experts before attempting to charter this work. If we meet in Beijing to discuss this work, we will focus on the discussion of the technical issues, regardless of the rechartering status. That said, I do not mind receiving input for possible new charter text before the Beijing meeting. Activity to get work done is always more than welcome. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rajaram_pejaver@cable.comcast.com Wed Oct 6 08:42:30 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 300883A6F92 for ; Wed, 6 Oct 2010 08:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.035 X-Spam-Level: X-Spam-Status: No, score=-108.035 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 IZJ9KKq7dj6W for ; Wed, 6 Oct 2010 08:42:29 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1588F3A6F8F for ; Wed, 6 Oct 2010 08:42:28 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.96605497; Wed, 06 Oct 2010 11:42:16 -0400 Received: from pacdcexcmb05.cable.comcast.com (24.40.15.116) by PACDCEXHUB01.cable.comcast.com (24.40.55.42) with Microsoft SMTP Server id 14.1.218.12; Wed, 6 Oct 2010 11:42:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 11:42:00 -0400 Message-ID: <029A504294520A4F84113D5C45B65A5202EF50E0@pacdcexcmb05.cable.comcast.com> In-Reply-To: <20101006113247.GA53034@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Next steps about the next steps Thread-Index: ActlSqJBgfoWj5WeS66IanVNG53AqwAHzD1A References: <20101005220416.GA49219@elstar.local> <20101006113247.GA53034@elstar.local> From: "Pejaver, Rajaram" To: Juergen Schoenwaelder , Wes Hardaker Cc: isms@ietf.org, Russ Mundy Subject: Re: [Isms] Next steps about the next steps 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, 06 Oct 2010 15:42:30 -0000 >>> My reading of=20 >>> the ID is that you are not really interested in the session key but=20 >>> you only want to use it for a single SNMP request/response=20 >>> interaction. >> This is why I like to have early feedback from Kerberos >> experts before attempting to charter this work. > The same ticket+sessionkey will be used if there are multiple SNMP > interactions between the NMS (Manager) & the managed device. Juergen, I did not fully answer your earlier question. KSM is aimed specifically for situations that involve short transactions. The sessionKey in a Kerberos ticket is a random value generated by the KDC. It can be safely used to encrypt a 'small' number of messages, or bytes of data. SNMP interactions that involve a 'large' number of messages (or data) will require rekeying which is not envisioned for KSM. Those interactions should use other stream based security models. We welcome suggestions for guidelines for what values are 'large' vs. 'small'. It is more of a AES/crypto question rather than a Kerberos one. Regards Rajaram Pejaver From d.b.nelson@comcast.net Wed Oct 6 09:16:22 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 664AD3A71A9 for ; Wed, 6 Oct 2010 09:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.802 X-Spam-Level: X-Spam-Status: No, score=-100.802 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_40=-0.185, USER_IN_WHITELIST=-100] 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 nkC6Aq4FRR4e for ; Wed, 6 Oct 2010 09:16:09 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id BF7DD3A7132 for ; Wed, 6 Oct 2010 09:16:02 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id FS3X1f0081YDfWL5BUH24y; Wed, 06 Oct 2010 16:17:02 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta20.westchester.pa.mail.comcast.net with comcast id FUH11f00a0yip6Y3gUH298; Wed, 06 Oct 2010 16:17:02 +0000 From: "Dave Nelson" To: References: <20101005220416.GA49219@elstar.local><20101006113247.GA53034@elstar.local> <029A504294520A4F84113D5C45B65A5202EF50E0@pacdcexcmb05.cable.comcast.com> Date: Wed, 6 Oct 2010 12:17:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActlSqJBgfoWj5WeS66IanVNG53AqwAHzD1AAAHGlCA= In-Reply-To: <029A504294520A4F84113D5C45B65A5202EF50E0@pacdcexcmb05.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: [Isms] Next steps about the next steps 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, 06 Oct 2010 16:16:22 -0000 > The sessionKey in a Kerberos ticket is a random value generated > by the KDC. It can be safely used to encrypt a 'small' number > of messages, or bytes of data. I think the question was whether a *single* Kerberos ticket would be used for more than a single SNMP PDU, thereby requiring session state. The "traditional" SNMP security models, such as USM, are stateless, in that the credentials are contained in each and every SNMP message. Are you proposing to include a Kerberos ticket in each and every SNMP message (even if it's the same ticket)? From jhutz@cmu.edu Wed Oct 6 09:26:41 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 CB07F3A6F2E for ; Wed, 6 Oct 2010 09:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 hRWTWvJeInQX for ; Wed, 6 Oct 2010 09:26:40 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id D29903A6B41 for ; Wed, 6 Oct 2010 09:26:39 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o96GRap1018780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2010 12:27:36 -0400 (EDT) Date: Wed, 06 Oct 2010 12:27:36 -0400 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , Wes Hardaker Message-ID: In-Reply-To: <32430_1286316293_o95M4qSo016245_20101005220416.GA49219@elstar.local> References: <32430_1286316293_o95M4qSo016245_20101005220416.GA49219@elstar.local> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: jhutz@cmu.edu, isms@ietf.org, Russ Mundy Subject: Re: [Isms] Next steps about the next steps 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, 06 Oct 2010 16:26:41 -0000 --On Wednesday, October 06, 2010 12:04:17 AM +0200 Juergen Schoenwaelder wrote: > - Concerning KSM I like to see a revised ID that better details the > proposal and brings it more inline with the way we happen to write > SNMP security models. Once an updated ID is available, I like to > have some feedback in particular from Kerberos experts about the > approach taken etc. In short, I like to better understand the > technical details and the potential pitfalls, which is also needed > in order to set realistic milestones. > > Given that the next IETF meeting is coming up relatively soon, it > might make sense to discuss KSM in some technical detail in Beijing > before we execute the formal rechartering procedure through the IESG. I'm certainly willing to review and contribute to this work, if the WG takes it on. You might find other reviewers by asking on the krb-wg list. I will not be in Beijing, but I will try to participate via jabber. -- Jeff From rajaram_pejaver@cable.comcast.com Wed Oct 6 10:54: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 125A23A701A for ; Wed, 6 Oct 2010 10:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.096 X-Spam-Level: X-Spam-Status: No, score=-108.096 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Yls8djgT6Vs2 for ; Wed, 6 Oct 2010 10:54:15 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 7FEBE3A6FC4 for ; Wed, 6 Oct 2010 10:54:13 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.96645912; Wed, 06 Oct 2010 13:55:12 -0400 Received: from pacdcexcmb05.cable.comcast.com (24.40.15.116) by PACDCEXHUB02.cable.comcast.com (24.40.55.41) with Microsoft SMTP Server id 14.1.218.12; Wed, 6 Oct 2010 13:55:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 13:54:44 -0400 Message-ID: <029A504294520A4F84113D5C45B65A5202EF5204@pacdcexcmb05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re: [Isms] Next steps about the next steps Thread-Index: ActlSqJBgfoWj5WeS66IanVNG53AqwAHzD1AAAHGlCAAAL+ikAACufrQ From: "Pejaver, Rajaram" To: Subject: Re: [Isms] Next steps about the next steps 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, 06 Oct 2010 17:54:16 -0000 >> The sessionKey in a Kerberos ticket is a random value generated >> by the KDC. It can be safely used to encrypt a 'small' number >> of messages, or bytes of data. > > I think the question was whether a *single* Kerberos ticket would be used > for more than a single SNMP PDU, thereby requiring session state. The > "traditional" SNMP security models, such as USM, are stateless, in that the > credentials are contained in each and every SNMP message. Are you proposing > to include a Kerberos ticket in each and every SNMP message (even if it's > the same ticket)? Yes. If the goal is to keep the managed device (MD) stateless, a Kerberos ticket must be included in each and every SNMP message. The same ticket cannot be reused because the MD will detect it as a replay based on the timestamp in the ticket. SNMP traps may be an exception where the MD saves the session key (along with the manager's IP address) for continued use because there will be few=20 destinations (typically 1) for traps. Thanks for clarifying the question. --raj From j.schoenwaelder@jacobs-university.de Wed Oct 6 17:15:34 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 DDDB63A6EBB for ; Wed, 6 Oct 2010 17:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 2hkNvFa6nTY7 for ; Wed, 6 Oct 2010 17:15:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 072933A6EB3 for ; Wed, 6 Oct 2010 17:15:32 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C52FDC0019; Thu, 7 Oct 2010 02:16:32 +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 GAa2bSUq3Gdl; Thu, 7 Oct 2010 02:16:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2729CC0008; Thu, 7 Oct 2010 02:16:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AC9151516564; Thu, 7 Oct 2010 02:15:58 +0200 (CEST) Date: Thu, 7 Oct 2010 02:15:58 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20101007001558.GA55596@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <20101005220416.GA49219@elstar.local> <20101006113247.GA53034@elstar.local> <029A504294520A4F84113D5C45B65A5202EF50E0@pacdcexcmb05.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "isms@ietf.org" Subject: Re: [Isms] Next steps about the next steps 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, 07 Oct 2010 00:15:34 -0000 On Wed, Oct 06, 2010 at 06:17:08PM +0200, Dave Nelson wrote: > > The sessionKey in a Kerberos ticket is a random value generated > > by the KDC. It can be safely used to encrypt a 'small' number > > of messages, or bytes of data. > > I think the question was whether a *single* Kerberos ticket would be used > for more than a single SNMP PDU, thereby requiring session state. The > "traditional" SNMP security models, such as USM, are stateless, in that the > credentials are contained in each and every SNMP message. Are you proposing > to include a Kerberos ticket in each and every SNMP message (even if it's > the same ticket)? My understanding of the text was that KSM reuses the same *ticket* for multiple transactions instead of establishing the session key and session state. But I might be wrong... /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 Wed Oct 6 17:19: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 EC6773A6ECC for ; Wed, 6 Oct 2010 17:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.995 X-Spam-Level: X-Spam-Status: No, score=-101.995 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 FngULs70SBTf for ; Wed, 6 Oct 2010 17:19:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6ED0D3A7081 for ; Wed, 6 Oct 2010 17:19:07 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36C8DC003B; Thu, 7 Oct 2010 02:20:08 +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 4hPo7uQs4lv0; Thu, 7 Oct 2010 02:20:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AA38C0008; Thu, 7 Oct 2010 02:20:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B005515165AB; Thu, 7 Oct 2010 02:19:38 +0200 (CEST) Date: Thu, 7 Oct 2010 02:19:38 +0200 From: Juergen Schoenwaelder To: "Pejaver, Rajaram" Message-ID: <20101007001938.GB55596@elstar.local> Mail-Followup-To: "Pejaver, Rajaram" , Wes Hardaker , "isms@ietf.org" , Russ Mundy References: <20101005220416.GA49219@elstar.local> <20101006113247.GA53034@elstar.local> <029A504294520A4F84113D5C45B65A5202EF50E0@pacdcexcmb05.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <029A504294520A4F84113D5C45B65A5202EF50E0@pacdcexcmb05.cable.comcast.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Russ Mundy , "isms@ietf.org" Subject: Re: [Isms] Next steps about the next steps 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, 07 Oct 2010 00:19:09 -0000 On Wed, Oct 06, 2010 at 05:42:00PM +0200, Pejaver, Rajaram wrote: > KSM is aimed specifically for situations that involve short > transactions. The sessionKey in a Kerberos ticket is a random value > generated by the KDC. It can be safely used to encrypt a 'small' > number of messages, or bytes of data. SNMP interactions that > involve a 'large' number of messages (or data) will require rekeying > which is not envisioned for KSM. Those interactions should use > other stream based security models. > > We welcome suggestions for guidelines for what values are 'large' > vs. 'small'. It is more of a AES/crypto question rather than a > Kerberos one. USM has a long lived symmetric key and a management application has to run a key update procedure to refresh the key. That is all fine. My reading, however, was that you send the ticket containing the session key multiple times instead of establishing the session key contained in the ticket once and then reusing the session state. Am I confused? /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 Wed Oct 6 17:22: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 162743A6D97 for ; Wed, 6 Oct 2010 17:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.996 X-Spam-Level: X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 PM3TSbgV0ECv for ; Wed, 6 Oct 2010 17:22:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CCE7F3A6EB3 for ; Wed, 6 Oct 2010 17:22:41 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A842C0019; Thu, 7 Oct 2010 02:23:42 +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 bhOxOnJwFiyl; Thu, 7 Oct 2010 02:23:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9758C0008; Thu, 7 Oct 2010 02:23:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7B5871516637; Thu, 7 Oct 2010 02:23:13 +0200 (CEST) Date: Thu, 7 Oct 2010 02:23:13 +0200 From: Juergen Schoenwaelder To: "Pejaver, Rajaram" Message-ID: <20101007002313.GC55596@elstar.local> Mail-Followup-To: "Pejaver, Rajaram" , "isms@ietf.org" References: <029A504294520A4F84113D5C45B65A5202EF5204@pacdcexcmb05.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <029A504294520A4F84113D5C45B65A5202EF5204@pacdcexcmb05.cable.comcast.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "isms@ietf.org" Subject: Re: [Isms] Next steps about the next steps 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, 07 Oct 2010 00:22:43 -0000 On Wed, Oct 06, 2010 at 07:54:44PM +0200, Pejaver, Rajaram wrote: > Yes. If the goal is to keep the managed device (MD) stateless, a > Kerberos ticket must be included in each and every SNMP message. > The same ticket cannot be reused because the MD will detect it as a > replay based on the timestamp in the ticket. Are you saying that for every getnext I have to get a new Kerberos ticket? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jhutz@cmu.edu Thu Oct 7 08:02: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 A0DD43A725D for ; Thu, 7 Oct 2010 08:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ar3fLrf77B0a for ; Thu, 7 Oct 2010 08:02:07 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id DF5AE3A7253 for ; Thu, 7 Oct 2010 08:02:06 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o97F357f022640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Oct 2010 11:03:05 -0400 (EDT) Date: Thu, 07 Oct 2010 11:03:01 -0400 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , "Pejaver, Rajaram" Message-ID: In-Reply-To: <24045_1286411027_o970NkAU026281_20101007002313.GC55596@elstar.local> References: <029A504294520A4F84113D5C45B65A5202EF5204@pacdcexcmb05.cable.comcast.com> <24045_1286411027_o970NkAU026281_20101007002313.GC55596@elstar.local> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] Next steps about the next steps 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, 07 Oct 2010 15:02:08 -0000 --On Thursday, October 07, 2010 02:23:13 AM +0200 Juergen Schoenwaelder wrote: > On Wed, Oct 06, 2010 at 07:54:44PM +0200, Pejaver, Rajaram wrote: > >> Yes. If the goal is to keep the managed device (MD) stateless, a >> Kerberos ticket must be included in each and every SNMP message. >> The same ticket cannot be reused because the MD will detect it as a >> replay based on the timestamp in the ticket. > > Are you saying that for every getnext I have to get a new Kerberos > ticket? No. That's not true, and the document doesn't say it, either. You do have to generate a new AP_REQ, or at least, you do if the command processor is doing replay detection correctly. With some care, it ought to be careful to avoid even this, by doing replay detection at the KSM layer instead of in Kerberos. In either case, you're going to have to _send_ both the ticket and AP_REQ with every request, in order to allow the server to remain stateless. I've done a very brief overview of this document and while it needs some work, the basic approach seems reasonable. I look forward to seeing comments from Wes and Ken Hornstein, who co-wrote the last KSM attempt around 10 years ago. And, I still recommend asking for additional review on the krb-wg list. -- Jeff From j.schoenwaelder@jacobs-university.de Thu Oct 7 08:13:35 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 3701F3A6E6D for ; Thu, 7 Oct 2010 08:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 wE2+4DvfoUhd for ; Thu, 7 Oct 2010 08:13:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7A9093A6E12 for ; Thu, 7 Oct 2010 08:13:33 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD0B0C0010; Thu, 7 Oct 2010 17:14:35 +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 jyrh4hn5ZVxL; Thu, 7 Oct 2010 17:14:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D1B8C0008; Thu, 7 Oct 2010 17:14:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9C6671517C18; Thu, 7 Oct 2010 17:14:06 +0200 (CEST) Date: Thu, 7 Oct 2010 17:14:06 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20101007151406.GF56935@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , "Pejaver, Rajaram" , "isms@ietf.org" References: <029A504294520A4F84113D5C45B65A5202EF5204@pacdcexcmb05.cable.comcast.com> <24045_1286411027_o970NkAU026281_20101007002313.GC55596@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "isms@ietf.org" Subject: Re: [Isms] Next steps about the next steps 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, 07 Oct 2010 15:13:35 -0000 On Thu, Oct 07, 2010 at 05:03:01PM +0200, Jeffrey Hutzelman wrote: > I've done a very brief overview of this document and while it needs some > work, the basic approach seems reasonable. I look forward to seeing > comments from Wes and Ken Hornstein, who co-wrote the last KSM attempt > around 10 years ago. And, I still recommend asking for additional review > on the krb-wg list. Thanks for looking at the document. I have noticed your suggestion to ask the krb-wg for review but since the authors want to post a more detailed ID soon, I thought I wait for this new revision to pop up before asking on the krb-wg list for reviews. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yiu_lee@cable.comcast.com Thu Oct 7 08:27:56 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 5DEB33A6EE5 for ; Thu, 7 Oct 2010 08:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.827 X-Spam-Level: X-Spam-Status: No, score=-103.827 tagged_above=-999 required=5 tests=[AWL=2.569, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] 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 fumx5pqxWKe5 for ; Thu, 7 Oct 2010 08:27:12 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D4CD93A7016 for ; Thu, 7 Oct 2010 08:27:06 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.96886410; Thu, 07 Oct 2010 11:27:50 -0400 Received: from PACDCEXCMB04.cable.comcast.com (24.40.15.86) by pacdcexhub03.cable.comcast.com (24.40.55.40) with Microsoft SMTP Server id 14.1.218.12; Thu, 7 Oct 2010 11:27:50 -0400 Received: from 69.241.25.0 ([69.241.25.0]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server legacywebmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Oct 2010 15:27:49 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 7 Oct 2010 11:27:48 -0400 From: "Yiu L. Lee" To: "Pejaver, Rajaram" , Message-ID: Thread-Topic: [Isms] Next steps about the next steps Thread-Index: ActlSqJBgfoWj5WeS66IanVNG53AqwAHzD1AAAHGlCAAAL+ikAACufrQAC1Xm+c= In-Reply-To: <029A504294520A4F84113D5C45B65A5202EF5204@pacdcexcmb05.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [Isms] Next steps about the next steps 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, 07 Oct 2010 15:27:58 -0000 Hi Dave and Raj, If you want to stop replay, the same ticket can't be used. This is one-way to implement it. However, this is not a requirement for Kerberos. RFC 4120 3.2.3 does not require a ticket only used one time. I think a more efficient approach is to use the same ticket for a period of time (defined inside the ticket) and the MD will expire the ticket when the time is reached. The Session-Key will be inside the ticket so that the MD doesn't need to remember any key. For security reason, the ticket life time should be short enough (say 15 mins). This will sufficiently reduce the load to generate a new ticket for each snmp message. Thanks, Yiu On 10/6/10 1:54 PM, "Pejaver, Rajaram" wrote: > >>> The sessionKey in a Kerberos ticket is a random value generated >>> by the KDC. It can be safely used to encrypt a 'small' number >>> of messages, or bytes of data. >> >> I think the question was whether a *single* Kerberos ticket would be > used >> for more than a single SNMP PDU, thereby requiring session state. The >> "traditional" SNMP security models, such as USM, are stateless, in > that the >> credentials are contained in each and every SNMP message. Are you > proposing >> to include a Kerberos ticket in each and every SNMP message (even if > it's >> the same ticket)? > > Yes. If the goal is to keep the managed device (MD) stateless, > a Kerberos ticket must be included in each and every SNMP message. > The same ticket cannot be reused because the MD will detect it as a > replay > based on the timestamp in the ticket. > SNMP traps may be an exception where the MD saves the session key (along > with > the manager's IP address) for continued use because there will be few > destinations (typically 1) for traps. > > Thanks for clarifying the question. > > --raj > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From yiu_lee@cable.comcast.com Thu Oct 7 08:29:27 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 07C043A6E12 for ; Thu, 7 Oct 2010 08:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.827 X-Spam-Level: X-Spam-Status: No, score=-103.827 tagged_above=-999 required=5 tests=[AWL=2.569, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] 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 bGYB+Dweeh8r for ; Thu, 7 Oct 2010 08:29:26 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id DEE9C3A7016 for ; Thu, 7 Oct 2010 08:27:58 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.96886871; Thu, 07 Oct 2010 11:28:56 -0400 Received: from PACDCEXCMB04.cable.comcast.com (24.40.15.86) by PACDCEXHUB01.cable.comcast.com (24.40.55.42) with Microsoft SMTP Server id 14.1.218.12; Thu, 7 Oct 2010 11:28:55 -0400 Received: from 69.241.25.0 ([69.241.25.0]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server legacywebmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Oct 2010 15:28:55 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 7 Oct 2010 11:28:53 -0400 From: "Yiu L. Lee" To: Juergen Schoenwaelder , Dave Nelson Message-ID: Thread-Topic: [Isms] Next steps about the next steps Thread-Index: ActmNFkjvVpgAp4ZBEeWFCyKhOnj3Q== In-Reply-To: <20101007001558.GA55596@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: "isms@ietf.org" Subject: Re: [Isms] Next steps about the next steps 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, 07 Oct 2010 15:29:27 -0000 Hi Juergen, You understanding is also my understanding. Thanks, Yiu On 10/6/10 8:15 PM, "Juergen Schoenwaelder" wrote: > On Wed, Oct 06, 2010 at 06:17:08PM +0200, Dave Nelson wrote: >>> The sessionKey in a Kerberos ticket is a random value generated >>> by the KDC. It can be safely used to encrypt a 'small' number >>> of messages, or bytes of data. >> >> I think the question was whether a *single* Kerberos ticket would be used >> for more than a single SNMP PDU, thereby requiring session state. The >> "traditional" SNMP security models, such as USM, are stateless, in that the >> credentials are contained in each and every SNMP message. Are you proposing >> to include a Kerberos ticket in each and every SNMP message (even if it's >> the same ticket)? > > My understanding of the text was that KSM reuses the same *ticket* for > multiple transactions instead of establishing the session key and > session state. But I might be wrong... > > /js From yiu_lee@cable.comcast.com Thu Oct 7 08:29:27 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 C46F13A6E12 for ; Thu, 7 Oct 2010 08:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.916 X-Spam-Level: X-Spam-Status: No, score=-103.916 tagged_above=-999 required=5 tests=[AWL=2.480, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] 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 y0yfSJazXdtu for ; Thu, 7 Oct 2010 08:29:26 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1E9A83A71A7 for ; Thu, 7 Oct 2010 08:28:32 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.96887151; Thu, 07 Oct 2010 11:29:31 -0400 Received: from PACDCEXCMB04.cable.comcast.com (24.40.15.86) by pacdcexhub03.cable.comcast.com (24.40.55.40) with Microsoft SMTP Server id 14.1.218.12; Thu, 7 Oct 2010 11:29:31 -0400 Received: from 69.241.25.0 ([69.241.25.0]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server legacywebmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Oct 2010 15:29:29 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 7 Oct 2010 11:29:29 -0400 From: "Yiu L. Lee" To: Juergen Schoenwaelder , "Pejaver, Rajaram" Message-ID: Thread-Topic: [Isms] Next steps about the next steps Thread-Index: ActmNG6Y5kzu+SRqAUW5WgKVbx/i7w== In-Reply-To: <20101007002313.GC55596@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: "isms@ietf.org" Subject: Re: [Isms] Next steps about the next steps 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, 07 Oct 2010 15:29:27 -0000 No. Please read my previous reply. Thanks, Yiu On 10/6/10 8:23 PM, "Juergen Schoenwaelder" wrote: > On Wed, Oct 06, 2010 at 07:54:44PM +0200, Pejaver, Rajaram wrote: > >> Yes. If the goal is to keep the managed device (MD) stateless, a >> Kerberos ticket must be included in each and every SNMP message. >> The same ticket cannot be reused because the MD will detect it as a >> replay based on the timestamp in the ticket. > > Are you saying that for every getnext I have to get a new Kerberos > ticket? > > /js From wjhns1@hardakers.net Thu Oct 7 15: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 57B4F3A6C73 for ; Thu, 7 Oct 2010 15:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 U+b7QfEbAgSx for ; Thu, 7 Oct 2010 15:13:56 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 203FC3A6935 for ; Thu, 7 Oct 2010 15:13:56 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 59E57980A3; Thu, 7 Oct 2010 15:14:38 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <029A504294520A4F84113D5C45B65A5202EF5204@pacdcexcmb05.cable.comcast.com> <24045_1286411027_o970NkAU026281_20101007002313.GC55596@elstar.local> Date: Thu, 07 Oct 2010 15:14:38 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Thu, 07 Oct 2010 11:03:01 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: isms@ietf.org Subject: Re: [Isms] Next steps about the next steps 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, 07 Oct 2010 22:13:57 -0000 >>>>> On Thu, 07 Oct 2010 11:03:01 -0400, Jeffrey Hutzelman said: JH> I look forward to seeing comments from Wes and Ken Hornstein, who JH> co-wrote the last KSM attempt around 10 years ago. One of the things we did in the implementation (or at least started to do; I can't remember if we completed it) was to allow for a longer lived session where the ticket would only be sent in the first transmission and in subsequent transmissions both sides would cache information. I'd like to see this as an option as it may be that the use case they have is stateless, but many many real-world kerberos deployment's don't need to be stateless. For small boxes it may be necessary, but there are many larger boxes that would benefit from longer lived sessions. It should be easy to add a bit in the request field that indicates whether the server is expected to cache the security credentials and a corresponding bit in the response saying whether it did or not. (We never documented this aspect of the plan since the work wasn't going to go forward at that time) -- Wes Hardaker Cobham Analytic Solutions From yiu_lee@cable.comcast.com Mon Oct 25 12:51:47 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 E3DAB3A682B for ; Mon, 25 Oct 2010 12:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.964 X-Spam-Level: X-Spam-Status: No, score=-106.964 tagged_above=-999 required=5 tests=[AWL=1.499, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 g1GUeCubqZt6 for ; Mon, 25 Oct 2010 12:51:46 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 30FEB3A68D3 for ; Mon, 25 Oct 2010 12:51:46 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.101910686; Mon, 25 Oct 2010 15:53:28 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0255.000; Mon, 25 Oct 2010 15:53:28 -0400 From: "Lee, Yiu" To: "isms@ietf.org" Thread-Topic: New Version Notification for draft-pejaver-isms-kerberos-01 Thread-Index: AQHLdHJxM+gDAO81c0yY4mD+HfT5HpNSE6qA Date: Mon, 25 Oct 2010 19:53:27 +0000 Message-ID: In-Reply-To: <20101025182647.EC7E83A68A2@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <82F4A49F2DB53841B4E1D5DCE690E337@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Isms] FW: New Version Notification for draft-pejaver-isms-kerberos-01 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: Mon, 25 Oct 2010 19:51:48 -0000 Sorry for the delay. The new revision has been posted. In this revision, we added Ken Hardaker and Wes Hardaker who are the original SNMP KSM authors. We also revised the document organization. This is the link: http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01 We would like to present this in the IETF beijing meeting. Comments and questions are welcome. http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01 On 10/25/10 2:26 PM, "IETF I-D Submission Tool" wrote: > >A new version of I-D, draft-pejaver-isms-kerberos-01.txt has been >successfully submitted by Rajaram Pejaver and posted to the IETF >repository. > >Filename: draft-pejaver-isms-kerberos >Revision: 01 >Title: Kerberos Security Model for SNMPv3 >Creation_date: 2010-10-25 >WG ID: Independent Submission >Number_of_pages: 20 > >Abstract: >This memo describes the use of Kerberos service with Simple Network >Management Protocol (SNMP) to authenticate users, authorize them to >access specific MIB objects, and to protect SNMP messages by using >integrity protection and encryption. User authorization information >is securely encapsulated inside the AuthorizationData field in a >Kerberos ticket. > =20 > =20 > > >The IETF Secretariat. > > From j.schoenwaelder@jacobs-university.de Tue Oct 26 00:09:49 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 63AA43A6846 for ; Tue, 26 Oct 2010 00:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.009 X-Spam-Level: X-Spam-Status: No, score=-102.009 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 WRxjRGmBsGxL for ; Tue, 26 Oct 2010 00:09:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2B5A43A67F1 for ; Tue, 26 Oct 2010 00:09:48 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F674C0048 for ; Tue, 26 Oct 2010 09:11:34 +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 2aFIFosGulOB; Tue, 26 Oct 2010 09:11:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7BC1C0036; Tue, 26 Oct 2010 09:11:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 851B7157F384; Tue, 26 Oct 2010 09:10:55 +0200 (CEST) Date: Tue, 26 Oct 2010 09:10:55 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20101026071055.GA71072@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Isms] isms beijing meeting agenda 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, 26 Oct 2010 07:09:49 -0000 Hi, we have a meeting slot at the upcoming IETF meeting (Wednesday 15:10-16:10). The goal of the meeting is to have a technical discussion of the proposed Kerberos security model, followed by a rechartering discussion. I have uploaded a draft agenda: http://www.ietf.org/proceedings/79/agenda/isms.txt For those presenting the proposed Kerberos security model, please make sure that I receive your slides well before the meeting (Wednesday morning the latest) since we may have remote participants. The chairs would also appreciate to receive input for the new charter before the meeting, either complete proposals or just text fragments covering suggested work items. It is also fine to iterate proposals on this list, of course. /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 Tue Oct 26 01:12:59 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 7557B3A68EE for ; Tue, 26 Oct 2010 01:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.011 X-Spam-Level: X-Spam-Status: No, score=-102.011 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+YCqnzlTdXR for ; Tue, 26 Oct 2010 01:12:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2F1F43A68E6 for ; Tue, 26 Oct 2010 01:12:54 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A56D1C0048 for ; Tue, 26 Oct 2010 10:14:40 +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 nLa6QG2g5Sst; Tue, 26 Oct 2010 10:14:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8C3FC0030; Tue, 26 Oct 2010 10:14:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 65CEB157F6C9; Tue, 26 Oct 2010 10:14:01 +0200 (CEST) Date: Tue, 26 Oct 2010 10:14:01 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20101026081401.GB71495@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Isms] fyi: [kerberos security model for snmp] 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, 26 Oct 2010 08:12:59 -0000 Hi, I have sent the email below to the kerberos working group in order to make them aware of the kerberos security model for snmp and to solicit technical advice/assistance. /js ----- Forwarded message from Juergen Schoenwaelder ----- Date: Tue, 26 Oct 2010 10:10:56 +0200 From: Juergen Schoenwaelder To: ietf-krb-wg@lists.anl.gov Subject: kerberos security model for snmp Message-ID: <20101026081056.GA71495@elstar.local> Hi, a kerberos security model for the simple network management protocol (snmp) has been proposed to the ISMS working group. I like to solicit feedback on the proposal from the kerberos community. The document can be found here: http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01 We are going to have a technical discussion of this proposal at the Beijing IETF in the Wednesday 15:10-16:10 time slot. Perhaps some of you can join this meeting to make sure things are heading into the right direction. Please send any questions / comments to the ISMS working group mailing list . /js (ISMS co-chair) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 ----- End forwarded message ----- From yiu_lee@cable.comcast.com Tue Oct 26 01:51:18 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 C3C323A67DB for ; Tue, 26 Oct 2010 01:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.014 X-Spam-Level: X-Spam-Status: No, score=-107.014 tagged_above=-999 required=5 tests=[AWL=1.449, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 KVBDM14yQQJV for ; Tue, 26 Oct 2010 01:51:17 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 431043A67DA for ; Tue, 26 Oct 2010 01:51:17 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.102100794; Tue, 26 Oct 2010 04:53:00 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0255.000; Tue, 26 Oct 2010 04:53:00 -0400 From: "Lee, Yiu" To: Juergen Schoenwaelder Thread-Topic: [Isms] fyi: [kerberos security model for snmp] Thread-Index: AQHLdOXdTY9R8w2LfEumTBCVrE1tnpNTL7uA Date: Tue, 26 Oct 2010 08:52:59 +0000 Message-ID: <68FCB7E4-5A78-4164-AA52-D850D30A23AA@Cable.Comcast.com> References: <20101026081401.GB71495@elstar.local> In-Reply-To: <20101026081401.GB71495@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "isms@ietf.org" Subject: Re: [Isms] fyi: [kerberos security model for snmp] 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, 26 Oct 2010 08:51:18 -0000 Thanks Juergen. On Oct 26, 2010, at 4:14 AM, "Juergen Schoenwaelder" wrote: > Hi, > > I have sent the email below to the kerberos working group in order to > make them aware of the kerberos security model for snmp and to solicit > technical advice/assistance. > > /js > > ----- Forwarded message from Juergen Schoenwaelder > ----- > > Date: Tue, 26 Oct 2010 10:10:56 +0200 > From: Juergen Schoenwaelder > To: ietf-krb-wg@lists.anl.gov > Subject: kerberos security model for snmp > Message-ID: <20101026081056.GA71495@elstar.local> > > Hi, > > a kerberos security model for the simple network management protocol > (snmp) has been proposed to the ISMS working group. I like to solicit > feedback on the proposal from the kerberos community. The document can > be found here: > > http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01 > > We are going to have a technical discussion of this proposal at the > Beijing IETF in the Wednesday 15:10-16:10 time slot. Perhaps some of > you can join this meeting to make sure things are heading into the > right direction. Please send any questions / comments to the ISMS > working group mailing list . > > /js (ISMS co-chair) > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > ----- End forwarded message ----- > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From dromasca@avaya.com Tue Oct 26 03:51: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 DA3633A6938 for ; Tue, 26 Oct 2010 03:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 md4kd9iPG4ky for ; Tue, 26 Oct 2010 03:51:13 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 0FC523A691C for ; Tue, 26 Oct 2010 03:51:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,240,1286164800"; d="scan'208";a="214186508" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Oct 2010 06:52:58 -0400 X-IronPort-AV: E=Sophos;i="4.58,240,1286164800"; d="scan'208";a="528447582" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Oct 2010 06:52:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Oct 2010 12:52:42 +0200 Message-ID: In-Reply-To: <20101026071055.GA71072@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] isms beijing meeting agenda Thread-Index: Act03Qs3QBIxbc4ASzaSeRivzZ0ZwAAHr9gw References: <20101026071055.GA71072@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , Subject: Re: [Isms] isms beijing meeting agenda 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, 26 Oct 2010 10:51:15 -0000 Having a strawman proposal for a new charter would help focusing the discussion on this point.=20 Dan =20 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, October 26, 2010 9:11 AM > To: isms@ietf.org > Subject: [Isms] isms beijing meeting agenda >=20 > Hi, >=20 > we have a meeting slot at the upcoming IETF meeting=20 > (Wednesday 15:10-16:10). The goal of the meeting is to have a=20 > technical discussion of the proposed Kerberos security model,=20 > followed by a rechartering discussion. I have uploaded a draft agenda: >=20 > http://www.ietf.org/proceedings/79/agenda/isms.txt >=20 > For those presenting the proposed Kerberos security model,=20 > please make sure that I receive your slides well before the=20 > meeting (Wednesday morning the latest) since we may have=20 > remote participants. >=20 > The chairs would also appreciate to receive input for the new=20 > charter before the meeting, either complete proposals or just=20 > text fragments covering suggested work items. It is also fine=20 > to iterate proposals on this list, of course. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms >=20 From wjhns1@hardakers.net Tue Oct 26 07:56: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 A1AD13A6900 for ; Tue, 26 Oct 2010 07:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SOIJhyWN5z7w for ; Tue, 26 Oct 2010 07:55:59 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 7E4FF3A699A for ; Tue, 26 Oct 2010 07:55:56 -0700 (PDT) Received: from localhost (unknown [166.129.103.94]) by mail.hardakers.net (Postfix) with ESMTPSA id 5E416980B0 for ; Tue, 26 Oct 2010 07:57:21 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20101026071055.GA71072@elstar.local> Date: Tue, 26 Oct 2010 07:57:18 -0700 In-Reply-To: <20101026071055.GA71072@elstar.local> (Juergen Schoenwaelder's message of "Tue, 26 Oct 2010 09:10:55 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Isms] isms beijing meeting agenda 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, 26 Oct 2010 14:56:06 -0000 >>>>> On Tue, 26 Oct 2010 09:10:55 +0200, Juergen Schoenwaelder said: JS> The chairs would also appreciate to receive input for the new charter JS> before the meeting, either complete proposals or just text fragments JS> covering suggested work items. It is also fine to iterate proposals on JS> this list, of course. Here's a rough proposal for a new charter: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem, a new Transport Security Model, and a Secure Shell Transport Model, a TLS Transport Model, a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS) and a method to dynamically provision the VACM from AAA services. Since the time of publication, the TLS Transport Model (TLSTM) [RFC5593] has been implemented by at least two vendors and interoperability tests have been conducted. Also implemented by the vendors in order to support this transport was the components making up the transport subsystem [RFC5590], the Transport Security Model [RFC5591] and the Context EngineID Discovery Mechanism [RFC5343]. The results of the interoperability tests between the vendors needs to be documented and any work required to advance the documents to Draft standard needs to be undertaken. Additionally, new work will be undertaken to define a Kerberos Security Model (KSM) that can offer support for protecting SNMP by Kerberos Network Authentication Services. Kerberos is a trusted third-party authentication protocol that provides a centralized, transport-independent mechanism for performing authentication, distributing authorization information, and securing traffic between a Kerberos instrumented client and server. The current goal of the ISMS working group is two-fold: to advance the TLSTM and other required RFCs (listed above) to Draft Standard and to develop and a method for securing SNMPv3 traffic using resources provided by the Kerberos Network Authentication Service. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Document the interoperability results from testing of the TLS Transport Model [RFC5593], the Transport Subsystem [RFC5590], the Transport Security Model [RFC5591] and the Context EngineID Discovery Mechansim [RFC5343] and advance the documents to Draft status. - Define a Kerberos Security Model for use with SNMPv3 Goals and Milestones Dec 2010 Publish initial revised copies of RFC5593, RFC5590, RFC5591 and RFC5343 if changes are needed to the documents. Dec 2010 Publish an initial copy of a TLSTM implementation report Jan 2011 Submit the TLSTM implementation report any revised copies of the RFCs to the IESG for publication in February as Draft status. Nov 2010 Initial version of a KSM document ??? Submit documentation on the KSM to the IESG -- Wes Hardaker Cobham Analytic Solutions From ietfc@btconnect.com Tue Oct 26 10:41:32 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 E8B8F3A69CC for ; Tue, 26 Oct 2010 10:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 K2JHFgWIr8Ty for ; Tue, 26 Oct 2010 10:41:31 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by core3.amsl.com (Postfix) with ESMTP id 1DDF63A69C1 for ; Tue, 26 Oct 2010 10:41:30 -0700 (PDT) Received: from host86-156-136-67.range86-156.btcentralplus.com (HELO pc6) ([86.156.136.67]) by c2bthomr09.btconnect.com with SMTP id ALV70994; Tue, 26 Oct 2010 18:43:14 +0100 (BST) Message-ID: <011301cb752c$b7a8e0a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "isms" References: <20101026081401.GB71495@elstar.local> Date: Tue, 26 Oct 2010 18:40:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CC71332.0098, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4CC71333.030D,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [Isms] fyi: [kerberos security model for snmp] 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, 26 Oct 2010 17:41:33 -0000 I think that this I-D has some way to go. - There seems to be a confusion over what a Security Model is, in that s2.1 states that " The first security models, USM [RFC3414]and VACM [RFC3415] ..." while if, as s6.2 says, this is "Compatible with VACM." then what is s4.3 doing? I expect a security model to specify how securityEngineID and securityName are derived, which this I-D does not do, and then leave VACM to get on with it. Then again, s2.6 says "For KSM, this value must contain the permissions for the specific user on the identified device. Though the semantics of this value can vary widely, for SNMP it is constrained to be a VACM groupName that the user should be placed into." Well no, this is nothing to do with SNMP, this is to do with KSM or not; this is really a rerun of RADIUS, in that if Kerberos is supplying a securityName to groupName mapping, then that needs to be incorporated in the VACM table; sounds like we need a ietf-isms-kerberos-vacm - s3.4, 3.5 and 3.6 seem to ignore the work of the isms WG in that the ASIs of RFC5590 are ignored. - And s.5 has "Traps and Reports are handled just as all other outgoing requests." which suggests a lack of understanding of security for Notifications. (and there is plenty more:-( Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Tuesday, October 26, 2010 10:14 AM Subject: [Isms] fyi: [kerberos security model for snmp] > Hi, > > I have sent the email below to the kerberos working group in order to > make them aware of the kerberos security model for snmp and to solicit > technical advice/assistance. > > /js > > ----- Forwarded message from Juergen Schoenwaelder ----- > > Date: Tue, 26 Oct 2010 10:10:56 +0200 > From: Juergen Schoenwaelder > To: ietf-krb-wg@lists.anl.gov > Subject: kerberos security model for snmp > Message-ID: <20101026081056.GA71495@elstar.local> > > Hi, > > a kerberos security model for the simple network management protocol > (snmp) has been proposed to the ISMS working group. I like to solicit > feedback on the proposal from the kerberos community. The document can > be found here: > > http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01 > > We are going to have a technical discussion of this proposal at the > Beijing IETF in the Wednesday 15:10-16:10 time slot. Perhaps some of > you can join this meeting to make sure things are heading into the > right direction. Please send any questions / comments to the ISMS > working group mailing list . > > /js (ISMS co-chair) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > ----- End forwarded message ----- > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From rajaram_pejaver@cable.comcast.com Tue Oct 26 12:24: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 E733D3A68D2 for ; Tue, 26 Oct 2010 12:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.142 X-Spam-Level: X-Spam-Status: No, score=-108.142 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 EaqM+7wb3o0g for ; Tue, 26 Oct 2010 12:24:57 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id B87453A6774 for ; Tue, 26 Oct 2010 12:24:56 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.102381379; Tue, 26 Oct 2010 15:26:37 -0400 Received: from PACDCEXMB03.cable.comcast.com ([fe80::c9c:28ac:e945:214f]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0255.000; Tue, 26 Oct 2010 15:26:38 -0400 From: "Pejaver, Rajaram" To: t.petch , isms Thread-Topic: [Isms] fyi: [kerberos security model for snmp] Thread-Index: AQHLdOXd273nsdzzhUWtKhHSbkLZvpNTgMk3gAAci5A= Date: Tue, 26 Oct 2010 19:26:37 +0000 Message-ID: <755EF2E97BFCD84F9E40633C63A458E6022CBA@PACDCEXMB03.cable.comcast.com> References: <20101026081401.GB71495@elstar.local> <011301cb752c$b7a8e0a0$4001a8c0@gateway.2wire.net> In-Reply-To: <011301cb752c$b7a8e0a0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.120.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Isms] fyi: [kerberos security model for snmp] 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, 26 Oct 2010 19:24:58 -0000 t.petch said: I think that this I-D has some way to go. [RAJ] Agreed. We need your help along the way. - There seems to be a confusion over what a Security Model is, in that s2.1 states that " The first security models, USM [RFC3414]and VACM [RFC3415] ..." while if, as s6.2 says, this is "Compatible with VACM." then what is s4.3 d= oing? [RAJ] A command responder that implements KSM may not have a configurable v= acmSecurityToGroupTable. [RAJ] Instead, the "groupName (x)" will simply be the value that was extrac= ted from the ticket. [RAJ] (I am referring to s3.1 in RFC 3415 for above.) I expect a security model to specify how securityEngineID and securityName = are derived, which this I-D does not do, and then leave VACM to get on with it. [RAJ] The securityName is extracted from the ticket in s4.2. [RAJ] There is no securityEngineID. Then again, s2.6 says "For KSM, this value must contain the permissions for the specific user on the identified device. Though the semantics of this value can vary widely, for SNMP it is constrained to be a VACM groupName that the user should be placed into." Well no, this is nothing to do with SNMP, this is to do with KSM or not; th= is is really a rerun of RADIUS, in that if Kerberos is supplying a securityName t= o groupName mapping, then that needs to be incorporated in the VACM table; so= unds like we need a ietf-isms-kerberos-vacm [RAJ] I don't understand your statement. [RAJ] Yes, the Kerberos server (effectively) is providing the securityName = to group mapping. [RAJ] As stated above, step 2 of isAccessAllowed(), the VACM vacmSecurityTo= GroupTable would [RAJ] return the value that was extracted from the ticket. - s3.4, 3.5 and 3.6 seem to ignore the work of the isms WG in that the ASIs= of RFC5590 are ignored. [RAJ] Do you mean tmStateReference? Oops. Good catch. - And s.5 has "Traps and Reports are handled just as all other outgoing requests." which suggests a lack of understanding of security for Notifications. [RAJ] A lot of sections need to be explained further. [RAJ] It isn't always clear to me as to what is necessary and what is redun= dant, so comments are valuable. [RAJ] The goal for the present version was to give an outline, and to impro= ve the document structure. (and there is plenty more:-( [RAJ] I am sure... Thanks for your comments. --raj Rajaram Pejaver Comcast From randy_presuhn@mindspring.com Tue Oct 26 14:24:50 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 5A53A3A6879 for ; Tue, 26 Oct 2010 14:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.984 X-Spam-Level: X-Spam-Status: No, score=-101.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 kb0TKK6SJpku for ; Tue, 26 Oct 2010 14:24:49 -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 7D91D3A682C for ; Tue, 26 Oct 2010 14:24:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YxaX3Temaj3U3b6pN6KN34A9noxQRFqzoWlbfecjT309Ph3nazTayf5p0tpibz6f; 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 [76.254.51.212] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PAr2T-0004UP-5R for isms@ietf.org; Tue, 26 Oct 2010 17:26:37 -0400 Message-ID: <005f01cb7554$b0329a00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Tue, 26 Oct 2010 14:28:09 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5feea47df97112fa92307dfd7d5a2ddd53c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.51.212 Subject: [Isms] securing SNMP - marketing and reality 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, 26 Oct 2010 21:24:50 -0000 Hi - It looks like SNMP's marketing problems persist - this came from the ietf@ietf.org list today. Randy > From: "Phillip Hallam-Baker" > To: "Scott O. Bradner" > Cc: > Sent: Tuesday, October 26, 2010 12:24 PM > Subject: Re: what is the problem bis ... > Most of the documents to reach STANDARD status in recent years have been > SNMP documents. But even though SNMP has its uses, deployment and use hardly > compares with HTTP which is at DRAFT. And nobody should be considering using > the SNMP 2.0 protocol which is the one that is allegedly STANDARD as it has > no security layer. ... From j.schoenwaelder@jacobs-university.de Wed Oct 27 02:52:24 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 911853A69CD for ; Wed, 27 Oct 2010 02:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.743 X-Spam-Level: X-Spam-Status: No, score=-101.743 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] 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 sa-DFO+DI1Ix for ; Wed, 27 Oct 2010 02:52:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3A1CD3A69BC for ; Wed, 27 Oct 2010 02:52:23 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 423C2C0086; Wed, 27 Oct 2010 11:54:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OyWoeiPM2mxI; Wed, 27 Oct 2010 11:54:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 364EEC0031; Wed, 27 Oct 2010 11:54:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 03E4C15832FF; Wed, 27 Oct 2010 11:53:32 +0200 (CEST) Date: Wed, 27 Oct 2010 11:53:32 +0200 From: Juergen Schoenwaelder To: "Pejaver, Rajaram" Message-ID: <20101027095332.GA75386@elstar.local> Mail-Followup-To: "Pejaver, Rajaram" , "t.petch" , isms References: <20101026081401.GB71495@elstar.local> <011301cb752c$b7a8e0a0$4001a8c0@gateway.2wire.net> <755EF2E97BFCD84F9E40633C63A458E6022CBA@PACDCEXMB03.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <755EF2E97BFCD84F9E40633C63A458E6022CBA@PACDCEXMB03.cable.comcast.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: isms Subject: Re: [Isms] fyi: [kerberos security model for snmp] 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, 27 Oct 2010 09:52:24 -0000 On Tue, Oct 26, 2010 at 07:26:37PM +0000, Pejaver, Rajaram wrote: > t.petch said: > > > I think that this I-D has some way to go. > > [RAJ] Agreed. We need your help along the way. > > - There seems to be a confusion over what a Security Model is, in that s2.1 > states that > " The first security models, USM [RFC3414]and VACM [RFC3415] ..." > while if, as s6.2 says, this is "Compatible with VACM." then what is s4.3 doing? > > [RAJ] A command responder that implements KSM may not have a configurable vacmSecurityToGroupTable. > [RAJ] Instead, the "groupName (x)" will simply be the value that was extracted from the ticket. > [RAJ] (I am referring to s3.1 in RFC 3415 for above.) With RADIUS, the supplied mapping is overwritten by local VACM configuration. You seem to propose a different model. I believe this needs to be carefully looked at. > Then again, s2.6 says > "For KSM, this value must contain the permissions for the specific > user on the identified device. Though the semantics of this value > can vary widely, for SNMP it is constrained to be a VACM groupName > that the user should be placed into." > Well no, this is nothing to do with SNMP, this is to do with KSM or not; this is > really a rerun of RADIUS, in that if Kerberos is supplying a securityName to > groupName mapping, then that needs to be incorporated in the VACM table; sounds > like we need a ietf-isms-kerberos-vacm > > [RAJ] I don't understand your statement. > [RAJ] Yes, the Kerberos server (effectively) is providing the securityName to group mapping. > [RAJ] As stated above, step 2 of isAccessAllowed(), the VACM vacmSecurityToGroupTable would > [RAJ] return the value that was extracted from the ticket. Sorry, we likely won't change what isAccessAllowed() in VACM does. So things have to work with the elements of procedure documented in RFC3415. This is why RADIUS supplied group mappings cause volatile entries to be added to the vacmSecurityToGroupTable if they do not collide with non-volatile config. /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 Wed Oct 27 03:15: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 E53413A69D3 for ; Wed, 27 Oct 2010 03:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 O5IywDgnT-hU for ; Wed, 27 Oct 2010 03:15:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1C29B3A685B for ; Wed, 27 Oct 2010 03:15:44 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AFD3C0015; Wed, 27 Oct 2010 12:17:33 +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 4Dc8qsVTp+iJ; Wed, 27 Oct 2010 12:17:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F784C000D; Wed, 27 Oct 2010 12:17:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B7C8415833FA; Wed, 27 Oct 2010 12:16:52 +0200 (CEST) Date: Wed, 27 Oct 2010 12:16:52 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20101027101652.GA75434@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: <20101026071055.GA71072@elstar.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: isms@ietf.org Subject: Re: [Isms] new charter proposal 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, 27 Oct 2010 10:15:46 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 26, 2010 at 07:57:18AM -0700, Wes Hardaker wrote: > Here's a rough proposal for a new charter: Thanks for getting this going. I have modified your text to remove some redundancy. For the TLS advancement, I have modified the timeline a bit to be hopefully more realistic. I think we first need to have the interoperability reports to decide which of the documents need what kind of changes. I also added a WG last call as a separate milestone plus some time to work through any WG last call comments. I think this looks more realistic and since we can't advance before six months have passed, there is not much difference anyway. For the Kerberos Security Model, I think there should be a short but strong motiviation included in the charter explaining why a Kerberos Security Model is needed in addition to what we have. This question surely will be asked by the IESG (and it already has been asked). And just to be clear about the process: The WG chairs will first determine whether there is WG support for each of the proposed two work items. Afterwards, we will discuss the charter text based on what we are preparing now. In other words, the fact that we discuss proposals of a potential new charter here does not mean that a decision has already been taken that the WG will work on these two items. We are just trying to be prepared. (I also changed the subject line to make this hopefully clearer.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-charter.txt" The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem, a new Transport Security Model, and a Secure Shell Transport Model, a TLS/DTLS Transport Model, a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS) and a method to dynamically provision the View-Based Access Control Model (VACM) security name to group name mappings from AAA services. Since the time of publication, the TLS/DTLS Transport Model (TLSTM) [RFC5593] has been implemented by at least two vendors and interoperability tests have been conducted. Also implemented by the vendors in order to support this transport was the components making up the transport subsystem [RFC5590], the Transport Security Model [RFC5591] and the Context EngineID Discovery Mechanism [RFC5343], originally defined in the Operations and Management Area Working Group (OPSAWG). Additionally, new work will be undertaken to define a Kerberos Security Model (KSM) that can offer support for protecting SNMP by Kerberos Network Authentication Services. Kerberos is a trusted third-party authentication protocol that provides a centralized, transport-independent mechanism for performing authentication, distributing authorization information, and securing traffic between a Kerberos instrumented client and server. [XXX Provide a short but strong motiviation why this is needed in addition to what we have. This question will be asked. XXX] The current goal of the ISMS working group is two-fold: (1) Document the results of the interoperability tests and based on the results undertake any work required to advance the Context EngineID Discovery Mechansim [RFC5343], the Transport Subsystem [RFC5590], the Transport Security Model [RFC5591], and the TLS/DTLS Transport Model [RFC5593] to Draft Standard. (2) Define a Kerberos Security Model (KSM) for use with SNMPv3. The Kerberos Security Model must comply with the SNMP architecture defined in RFC3411. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). Goals and Milestones Dec 2010 Publish an initial copy of a TLSTM implementation report Jan 2011 Publish initial revised copies of RFC5593, RFC5590, RFC5591 and RFC5343 if changes are needed to the documents. Feb 2011 Working group last call on any revised RFCs Mar 2011 Submit the TLSTM implementation report any revised copies of the RFCs to the IESG for publication as Draft Standard. Nov 2010 Initial version of a KSM document Working group last call on the KSM document ??? Submit documentation on the KSM to the IESG for publication as Proposed Standard --ibTvN161/egqYuK8-- From rajaram_pejaver@cable.comcast.com Wed Oct 27 05:45:27 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 F1E5B3A69FB for ; Wed, 27 Oct 2010 05:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.178 X-Spam-Level: X-Spam-Status: No, score=-108.178 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 mD4MabZdEjY9 for ; Wed, 27 Oct 2010 05:45:25 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 6FCFE3A69F4 for ; Wed, 27 Oct 2010 05:45:25 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.102614902; Wed, 27 Oct 2010 08:47:13 -0400 Received: from PACDCEXMB03.cable.comcast.com ([fe80::c9c:28ac:e945:214f]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0255.000; Wed, 27 Oct 2010 08:47:13 -0400 From: "Pejaver, Rajaram" To: Juergen Schoenwaelder Thread-Topic: [Isms] fyi: [kerberos security model for snmp] Thread-Index: AQHLdOXd273nsdzzhUWtKhHSbkLZvpNTgMk3gAAci5CAATWPAP//25rQ Date: Wed, 27 Oct 2010 12:47:12 +0000 Message-ID: <755EF2E97BFCD84F9E40633C63A458E60231A3@PACDCEXMB03.cable.comcast.com> References: <20101026081401.GB71495@elstar.local> <011301cb752c$b7a8e0a0$4001a8c0@gateway.2wire.net> <755EF2E97BFCD84F9E40633C63A458E6022CBA@PACDCEXMB03.cable.comcast.com> <20101027095332.GA75386@elstar.local> In-Reply-To: <20101027095332.GA75386@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.248.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: isms Subject: Re: [Isms] fyi: [kerberos security model for snmp] 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, 27 Oct 2010 12:45:27 -0000 In response to Juergen Schoenwaelder: > [RAJ] A command responder that implements KSM may not have a configurable= vacmSecurityToGroupTable. > [RAJ] Instead, the "groupName (x)" will simply be the value that was extr= acted from the ticket. > [RAJ] (I am referring to s3.1 in RFC 3415 for above.) [JS] With RADIUS, the supplied mapping is overwritten by local VACM [JS] configuration. You seem to propose a different model. I believe this [JS] needs to be carefully looked at. We are proposing exactly the same procedure as in draft-ietf-isms-radius-va= cm-11. The supplied mapping from the ticket is overwritten -into- local VACM confi= guration. No new models are being added to RFC3415 (VACM). =20 > [RAJ] I don't understand your statement. > [RAJ] Yes, the Kerberos server (effectively) is providing the securityNam= e to group mapping. > [RAJ] As stated above, step 2 of isAccessAllowed(), the VACM vacmSecurity= ToGroupTable would > [RAJ] return the value that was extracted from the ticket. [JS] Sorry, we likely won't change what isAccessAllowed() in VACM does. So [JS] things have to work with the elements of procedure documented in [JS] RFC3415. This is why RADIUS supplied group mappings cause volatile [JS] entries to be added to the vacmSecurityToGroupTable if they do not [JS] collide with non-volatile config. Again, no change is being requested to RFC3415 (VACM). To be more clear, I will copy language from draft-ietf-isms-radius-vacm-11 = into our next draft. I do not have that doc handy at the moment, but conceptually something as f= ollows: - The groupName authorization value is inserted into the vacmSecurityToGrou= pTable and is associated with the securityName (same as Kerberos principal name) and= the model (KSM). This happens when the incoming request is being processed. The update procedure is as described in radius-vacm. - When isAccessAllowed() is subsequently executed, it will pick up the corr= ect groupName from vacmSecurityToGroupTable. =20 - At the end of the SNMP operation, the table entry (association) must be d= eleted. The table on the responder must not have any preexisting non-volatile ent= ries for KSM. Please pardon my language & terminology. I will get that right eventually. --raj Rajaram Pejaver Comcast From adonati@motorola.com Wed Oct 27 05:47:48 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 04D4F3A69F6 for ; Wed, 27 Oct 2010 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk8O5d10PD2f for ; Wed, 27 Oct 2010 05:47:46 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id AB6C43A69F4 for ; Wed, 27 Oct 2010 05:47:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1288183774!45075841!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3397 invoked from network); 27 Oct 2010 12:49:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Oct 2010 12:49:34 -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 o9RCnYZV021877 for ; Wed, 27 Oct 2010 05:49:34 -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 o9RCnY9J025138 for ; Wed, 27 Oct 2010 07:49:34 -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 o9RCnXsr025134 for ; Wed, 27 Oct 2010 07:49:33 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 2010 08:49:11 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 Thread-Index: AQHLdHJxM+gDAO81c0yY4mD+HfT5HpNSE6qAgAKoZbA= References: <20101025182647.EC7E83A68A2@core3.amsl.com> From: "Donati Andrew-MGIA0477" To: "Lee, Yiu" , X-CFilter-Loop: Reflected Subject: Re: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 12:47:48 -0000 Hi, Here are a few quick comments on draft -01 Section 2.1. =20 >This memo defines a Kerberos-based Security Model (KSM) ... for SNMPv3 [RFC3411]. =20 If using the [RFC3411] designation with SNMP, the term 'architecture' should probably be included. The reference to RFC3411 can otherwise be left out when mentioning SNMP in general.=20 >The first security models, USM [RFC3414] and VACM [RFC3415]... (Others have previously brought up this topic) The latter is an access control model which can be used within a security model as discussed in section 2.6. Are you proposing the use of VACM or some other access control model to be used within the KSM security model? Section 2.4=20 >authPriv - with both authentication and privacy...scopedPDU will be further protected for confidentiality. 'Further protected' could stand for encryption for privacy. Draft 00 discussed using the PAC (Privilege Attribute Certificate) for defining encryption requirements. Perhaps a section can be added discussing an encryption protocol and the possible use of the PAC if it's still chosen to be used. Section 3.4 >securityModel: Must be Kerberos Security Model (KSM). The KSM security model needs a defined enumeration. Should this be 4 ? General comment: Will if be helpful to define a MIB module for visibility in monitoring KSM transactions? Error definitions defined in RFC4120 section 3.2.3 can be used as a basis for counters. The following are some examples.=20 KRB_AP_ERR_BADKEYVER=20 KRB_AP_ERR_NOKEY=20 KRB_AP_ERR_BAD_INTEGRITY=20 KRB_AP_ERR_BADADDR =20 KRB_AP_ERR_SKEW=20 KRB_AP_ERR_REPEAT KRB_AP_ERR_TKT_NYV=20 KRB_AP_ERR_TKT_EXPIRED -- Andy Donati -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Lee, Yiu Sent: Monday, October 25, 2010 3:53 PM To: isms@ietf.org Subject: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 Sorry for the delay. The new revision has been posted. In this revision, we added Ken Hardaker and Wes Hardaker who are the original SNMP KSM authors. We also revised the document organization. This is the link: http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01 We would like to present this in the IETF beijing meeting. Comments and questions are welcome. http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01 On 10/25/10 2:26 PM, "IETF I-D Submission Tool" wrote: > >A new version of I-D, draft-pejaver-isms-kerberos-01.txt has been=20 >successfully submitted by Rajaram Pejaver and posted to the IETF=20 >repository. > >Filename: draft-pejaver-isms-kerberos >Revision: 01 >Title: Kerberos Security Model for SNMPv3 >Creation_date: 2010-10-25 >WG ID: Independent Submission >Number_of_pages: 20 > >Abstract: >This memo describes the use of Kerberos service with Simple Network=20 >Management Protocol (SNMP) to authenticate users, authorize them to=20 >access specific MIB objects, and to protect SNMP messages by using=20 >integrity protection and encryption. User authorization information is >securely encapsulated inside the AuthorizationData field in a Kerberos=20 >ticket. > =20 > =20 > > >The IETF Secretariat. > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From rajaram_pejaver@cable.comcast.com Wed Oct 27 06:40:54 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 29C633A6802 for ; Wed, 27 Oct 2010 06:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.206 X-Spam-Level: X-Spam-Status: No, score=-108.206 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Omr19l3AsOrR for ; Wed, 27 Oct 2010 06:40:53 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 0326F3A67B2 for ; Wed, 27 Oct 2010 06:40:52 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.102624571; Wed, 27 Oct 2010 09:42:39 -0400 Received: from PACDCEXMB03.cable.comcast.com ([fe80::c9c:28ac:e945:214f]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0255.000; Wed, 27 Oct 2010 09:42:39 -0400 From: "Pejaver, Rajaram" To: Donati Andrew-MGIA0477 , "Lee, Yiu" , "isms@ietf.org" Thread-Topic: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 Thread-Index: AQHLddVurBtmA+Yc206Kx6p3GvMp6pNUv32Q Date: Wed, 27 Oct 2010 13:42:38 +0000 Message-ID: <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> References: <20101025182647.EC7E83A68A2@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.248.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 13:40:54 -0000 In response to Andy Donati: [AD] Here are a few quick comments on draft -01 Thanks. Yiu may chime in with his own responses as well. [AD] If using the [RFC3411] designation with SNMP, the term 'architecture' [AD] should probably be included. The reference to RFC3411 can otherwise b= e [AD] left out when mentioning SNMP in general.=20 Are you suggesting adding the word 'architecture' after SNMPv3? Pls restate. [AD] >The first security models, USM [RFC3414] and VACM [RFC3415]... [AD] (Others have previously brought up this topic) [AD] The latter is an access control model which can be used within a [AD] security model as discussed in section 2.6. Are you proposing the use [AD] of VACM or some other access control model to be used within the KSM [AD] security model? KSM will use VACM as described in the RFC 3415 standard. VACM, as originally envisioned, had a username -> group mapping that was implicitly local to each managed device. Since that is hard to manage on m= ost large networks, we envision this mapping to be done centrally. The recent radius-vacm work found a way to deal with this issue and KSM follows exactly the same path. [AD] Section 2.4=20 [AD] >authPriv - with both authentication and privacy...scopedPDU will be [AD] further protected for confidentiality. [AD] 'Further protected' could stand for encryption for privacy. Draft 00 [AD] discussed using the PAC (Privilege Attribute Certificate) for defining [AD] encryption requirements. Perhaps a section can be added discussing an [AD] encryption protocol and the possible use of the PAC if it's still chos= en [AD] to be used. Version -01 matured beyond -00 in many ways. (Or perhaps I did :-) Yes, the scopedPDU must be encrypted as stated in s4.1. Kerberos has a prescribed way to encrypt data, and KSM must use that way. We replaced the term PAC with 'authorization information'. PAC implies a certificate, which implies a signature, which we don't need. I was initially imagining more flexible (complicated) encryption requiremen= ts. The correct (simpler) way is to just use securityLevel. [AD] Section 3.4 [AD] >securityModel: Must be Kerberos Security Model (KSM). [AD] The KSM security model needs a defined enumeration. Should this be 4 = ? Don't know yet. We need a lucky number. [AD] General comment: [AD] Will if be helpful to define a MIB module for visibility in monitoring [AD] KSM transactions? [AD] Error definitions defined in RFC4120 section 3.2.3 can be used as a [AD] basis for counters. The following are some examples.=20 Agreed. TBD in upcoming revisions. Thanks again. --raj Rajaram Pejaver Comcast From adonati@motorola.com Wed Oct 27 07:13: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 95B843A6A48 for ; Wed, 27 Oct 2010 07:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZAh86SAzHzz for ; Wed, 27 Oct 2010 07:13:07 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id CA3EB3A6B7B for ; Wed, 27 Oct 2010 07:09:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1288188660!55962449!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 17606 invoked from network); 27 Oct 2010 14:11:00 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Oct 2010 14:11:00 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id o9REB0Kl003707 for ; Wed, 27 Oct 2010 07:11:00 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o9REAxsA013729 for ; Wed, 27 Oct 2010 09:11:00 -0500 (CDT) Received: from de01exm62.ds.mot.com (de01exm62.am.mot.com [10.176.8.107]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o9REAx5d013721 for ; Wed, 27 Oct 2010 09:10:59 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 2010 10:10:38 -0400 Message-ID: In-Reply-To: <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: New Version Notificationfordraft-pejaver-isms-kerberos-01 Thread-Index: AQHLddVurBtmA+Yc206Kx6p3GvMp6pNUv32QgAASBfA= References: <20101025182647.EC7E83A68A2@core3.amsl.com> <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> From: "Donati Andrew-MGIA0477" To: "Pejaver, Rajaram" , "Lee, Yiu" , X-CFilter-Loop: Reflected Subject: Re: [Isms] FW: New Version Notificationfordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 14:13:10 -0000 >>[AD] If using the [RFC3411] designation with SNMP, the term 'architecture' >>[AD] should probably be included. The reference to RFC3411 can otherwise >>[AD] be left out when mentioning SNMP in general.=20 >Are you suggesting adding the word 'architecture' after SNMPv3? >Pls restate. SNMPv3 in the context of the following sentence seems to be referring to SNMP in general as opposed to the SNMP architecture [RFC3411]. "This memo defines a Kerberos-based Security Model (KSM) that supports centralized administration of user authentication and authorization for SNMPv3 [RFC3411]." Perhaps it can be restated as the following: "This memo defines a Kerberos-based Security Model (KSM) that supports centralized administration of user authentication and authorization for the Simple Network Management Protocol (SNMP)." -- Andy From wjhns1@hardakers.net Wed Oct 27 07:13:13 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 1B2433A6A56 for ; Wed, 27 Oct 2010 07:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 pkeMFqZm7eZY for ; Wed, 27 Oct 2010 07:13:12 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 6E6923A6B8F for ; Wed, 27 Oct 2010 07:09:54 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 57E8C98095; Wed, 27 Oct 2010 07:11:22 -0700 (PDT) From: Wes Hardaker To: "Pejaver\, Rajaram" Organization: Sparta References: <20101026081401.GB71495@elstar.local> <011301cb752c$b7a8e0a0$4001a8c0@gateway.2wire.net> <755EF2E97BFCD84F9E40633C63A458E6022CBA@PACDCEXMB03.cable.comcast.com> <20101027095332.GA75386@elstar.local> <755EF2E97BFCD84F9E40633C63A458E60231A3@PACDCEXMB03.cable.comcast.com> Date: Wed, 27 Oct 2010 07:11:21 -0700 In-Reply-To: <755EF2E97BFCD84F9E40633C63A458E60231A3@PACDCEXMB03.cable.comcast.com> (Rajaram Pejaver's message of "Wed, 27 Oct 2010 12:47:12 +0000") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: isms Subject: Re: [Isms] fyi: [kerberos security model for snmp] 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, 27 Oct 2010 14:13:13 -0000 >>>>> On Wed, 27 Oct 2010 12:47:12 +0000, "Pejaver, Rajaram" said: PR> The table on the responder must not have any preexisting PR> non-volatile entries for KSM. I think that's not the correct behavior. Operators should be able to configure the VACM and I think the radius draft addresses this and the KSM draft needs to as well. -- Wes Hardaker Cobham Analytic Solutions From yiu_lee@cable.comcast.com Wed Oct 27 07:13:20 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 155723A6A30 for ; Wed, 27 Oct 2010 07:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.144 X-Spam-Level: X-Spam-Status: No, score=-107.144 tagged_above=-999 required=5 tests=[AWL=1.319, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 2NilU3ZkxHwZ for ; Wed, 27 Oct 2010 07:13:19 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 243703A68DB for ; Wed, 27 Oct 2010 07:11:34 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.102631305; Wed, 27 Oct 2010 10:13:22 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0255.000; Wed, 27 Oct 2010 10:13:22 -0400 From: "Lee, Yiu" To: Donati Andrew-MGIA0477 , "Pejaver, Rajaram" , "isms@ietf.org" Thread-Topic: [Isms] FW: New Version Notificationfordraft-pejaver-isms-kerberos-01 Thread-Index: AQHLdeDBphKmik7RbUSKv0QADEgm2pNU1m2A Date: Wed, 27 Oct 2010 14:13:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <44CF87349644C44993AFBC0647039CC0@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Isms] FW: New Version Notificationfordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 14:13:20 -0000 Andy, Thanks for the input. We will rewrite that sentence based on your suggestion. Yiu On 10/27/10 10:10 AM, "Donati Andrew-MGIA0477" wrote: >>>[AD] If using the [RFC3411] designation with SNMP, the term >'architecture' >>>[AD] should probably be included. The reference to RFC3411 can >otherwise >>>[AD] be left out when mentioning SNMP in general. > >>Are you suggesting adding the word 'architecture' after SNMPv3? >>Pls restate. > >SNMPv3 in the context of the following sentence seems to be referring to >SNMP in general as opposed to the SNMP architecture [RFC3411]. > >"This memo defines a Kerberos-based Security Model (KSM) that supports >centralized administration of user authentication and authorization >for SNMPv3 [RFC3411]." > >Perhaps it can be restated as the following: > >"This memo defines a Kerberos-based Security Model (KSM) that supports >centralized administration of user authentication and authorization >for the Simple Network Management Protocol (SNMP)." > >-- Andy From wjhns1@hardakers.net Wed Oct 27 07:14: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 5617F3A6784 for ; Wed, 27 Oct 2010 07:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MI4wuyZY3PAI for ; Wed, 27 Oct 2010 07:14:09 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id DAA313A6A36 for ; Wed, 27 Oct 2010 07:14:01 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 96756980AB; Wed, 27 Oct 2010 07:15:30 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20101026071055.GA71072@elstar.local> <20101027101652.GA75434@elstar.local> Date: Wed, 27 Oct 2010 07:15:30 -0700 In-Reply-To: <20101027101652.GA75434@elstar.local> (Juergen Schoenwaelder's message of "Wed, 27 Oct 2010 12:16:52 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: isms@ietf.org Subject: Re: [Isms] new charter proposal 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, 27 Oct 2010 14:14:11 -0000 >>>>> On Wed, 27 Oct 2010 12:16:52 +0200, Juergen Schoenwaelder said: JS> Thanks for getting this going. I have modified your text to remove JS> some redundancy. Much of the redundancy was due to me copying the format of the existing charter, which was very redundant! JS> For the TLS advancement, I have modified [...] You didn't include your modified version in your post. JS> I think this looks more realistic and since we can't advance before JS> six months have passed, there is not much difference anyway. The original draft versions of the SNMPv3 docs were sent to the IESG before the 6 months had expired. They just weren't published until the 6 month mark, and I was hoping to do the same not "be speedy" but because I don't expect much work and don't see a benefit to dragging it out. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Wed Oct 27 07:32:14 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 010FE3A6A34 for ; Wed, 27 Oct 2010 07:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 a9iXpkPcbA4b for ; Wed, 27 Oct 2010 07:32:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DDA2A3A6A2F for ; Wed, 27 Oct 2010 07:32:12 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AFDFC0002; Wed, 27 Oct 2010 16:34:02 +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 G-2QMWood2zv; Wed, 27 Oct 2010 16:34:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38D34C0008; Wed, 27 Oct 2010 16:33:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E69C1583EBD; Wed, 27 Oct 2010 16:33:54 +0200 (CEST) Date: Wed, 27 Oct 2010 16:33:54 +0200 From: Juergen Schoenwaelder To: Donati Andrew-MGIA0477 Message-ID: <20101027143354.GA835@elstar.local> Mail-Followup-To: Donati Andrew-MGIA0477 , "Pejaver, Rajaram" , "Lee, Yiu" , isms@ietf.org References: <20101025182647.EC7E83A68A2@core3.amsl.com> <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: isms@ietf.org Subject: Re: [Isms] FW: New Version Notificationfordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 14:32:14 -0000 On Wed, Oct 27, 2010 at 10:10:38AM -0400, Donati Andrew-MGIA0477 wrote: > Perhaps it can be restated as the following: > > "This memo defines a Kerberos-based Security Model (KSM) that supports > centralized administration of user authentication and authorization > for the Simple Network Management Protocol (SNMP)." But it will only work for SNMPv3, so probably being more explicit about this is not a bad thing. /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 Wed Oct 27 07:35: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 664E93A6A33 for ; Wed, 27 Oct 2010 07:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 Ae+BbQhuCmLT for ; Wed, 27 Oct 2010 07:35:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 269733A6784 for ; Wed, 27 Oct 2010 07:35:42 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A28F1C000E; Wed, 27 Oct 2010 16:37:31 +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 U37GsZfSc7NP; Wed, 27 Oct 2010 16:37:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EFAEC0002; Wed, 27 Oct 2010 16:37:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EF88A1583F55; Wed, 27 Oct 2010 16:37:30 +0200 (CEST) Date: Wed, 27 Oct 2010 16:37:30 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20101027143730.GA872@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: <20101026071055.GA71072@elstar.local> <20101027101652.GA75434@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: isms@ietf.org Subject: Re: [Isms] new charter proposal 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, 27 Oct 2010 14:35:43 -0000 On Wed, Oct 27, 2010 at 07:15:30AM -0700, Wes Hardaker wrote: > >>>>> On Wed, 27 Oct 2010 12:16:52 +0200, Juergen Schoenwaelder said: > > JS> Thanks for getting this going. I have modified your text to remove > JS> some redundancy. > > Much of the redundancy was due to me copying the format of the existing > charter, which was very redundant! > > JS> For the TLS advancement, I have modified [...] > > You didn't include your modified version in your post. There is an attachment; at least there was one when the email went out. > JS> I think this looks more realistic and since we can't advance before > JS> six months have passed, there is not much difference anyway. > > The original draft versions of the SNMPv3 docs were sent to the IESG > before the 6 months had expired. They just weren't published until the > 6 month mark, and I was hoping to do the same not "be speedy" but > because I don't expect much work and don't see a benefit to dragging it out. It is always possible to be faster than the milestones state on the charter. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yiu_lee@cable.comcast.com Wed Oct 27 07:36:48 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 7178B3A6A43 for ; Wed, 27 Oct 2010 07:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.345 X-Spam-Level: X-Spam-Status: No, score=-107.345 tagged_above=-999 required=5 tests=[AWL=1.118, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 r59ptcbJkQ02 for ; Wed, 27 Oct 2010 07:36:44 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 94D943A6A38 for ; Wed, 27 Oct 2010 07:36:42 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.102637371; Wed, 27 Oct 2010 10:37:42 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0255.000; Wed, 27 Oct 2010 10:37:42 -0400 From: "Lee, Yiu" To: Juergen Schoenwaelder , Donati Andrew-MGIA0477 Thread-Topic: [Isms] FW: New Version Notificationfordraft-pejaver-isms-kerberos-01 Thread-Index: AQHLdeDBphKmik7RbUSKv0QADEgm2pNVH0IA//+9/oA= Date: Wed, 27 Oct 2010 14:37:41 +0000 Message-ID: In-Reply-To: <20101027143354.GA835@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <37F8711B429767409D4C87BC222A324F@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "isms@ietf.org" Subject: Re: [Isms] FW: New Version Notificationfordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 14:36:48 -0000 Agreed and noted. We will revise this in next version. On 10/27/10 10:33 AM, "Juergen Schoenwaelder" wrote: >On Wed, Oct 27, 2010 at 10:10:38AM -0400, Donati Andrew-MGIA0477 wrote: >=20 >> Perhaps it can be restated as the following: >>=20 >> "This memo defines a Kerberos-based Security Model (KSM) that supports >> centralized administration of user authentication and authorization >> for the Simple Network Management Protocol (SNMP)." > >But it will only work for SNMPv3, so probably being more explicit >about this is not a bad thing. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From dnelson@elbrys.com Wed Oct 27 08:46: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 A40B23A69AA for ; Wed, 27 Oct 2010 08:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96uQV9KyMIpn for ; Wed, 27 Oct 2010 08:46:24 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by core3.amsl.com (Postfix) with SMTP id C1EED3A6956 for ; Wed, 27 Oct 2010 08:46:21 -0700 (PDT) Received: from source ([209.85.216.52]) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTMhJukxkBX28GxThvACX3/T/FPmu2ge0@postini.com; Wed, 27 Oct 2010 08:48:12 PDT Received: by mail-qw0-f52.google.com with SMTP id 5so969998qwh.25 for ; Wed, 27 Oct 2010 08:48:10 -0700 (PDT) Received: by 10.229.91.2 with SMTP id k2mr4780964qcm.147.1288194490639; Wed, 27 Oct 2010 08:48:10 -0700 (PDT) Received: from dbn-imac.elbrysnetworks.com ([64.140.243.171]) by mx.google.com with ESMTPS id mz11sm8746337qcb.15.2010.10.27.08.48.08 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 08:48:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "David B. Nelson" In-Reply-To: <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> Date: Wed, 27 Oct 2010 11:48:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <341DF6B0-7A48-4939-BEAB-134143C3ABFC@elbrys.com> References: <20101025182647.EC7E83A68A2@core3.amsl.com> <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> To: "Pejaver, Rajaram" X-Mailer: Apple Mail (2.1081) Cc: "isms@ietf.org" , "Lee, Yiu" Subject: Re: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 15:46:26 -0000 On Oct 27, 2010, at 9:42 AM, Pejaver, Rajaram wrote: > The recent radius-vacm work found a way to deal with this issue and > KSM follows exactly the same path. Will you be using the same MIB module that was introduced in the = AAA-VACM work? It seems like introducing a similar (or nearly = identical) one with a different set of OIDs would be less than optimal. If you are indeed reusing the mechanisms of the AAA-VACM work, perhaps = all you need to do is reference that (pending) RFC and explain the = translation of terms in your draft, e.g. what the equivalents of = "User-Name" and ""Management-Policy-Id" are in the Kerberos framework. = Duplicating the elements of procedure and MIB module in the KSM document = would serve no useful purpose if the mechanism is indeed the same. Some = effort went into word-smithing the AAA-VACM document to make it = re-useable for other AAA services, which could certainly include = Kerberos. From wjhns1@hardakers.net Wed Oct 27 09:27: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 0EF253A6911 for ; Wed, 27 Oct 2010 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 d2lHzSZ3Z5Mp for ; Wed, 27 Oct 2010 09:27:09 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 39CB43A680C for ; Wed, 27 Oct 2010 09:27:09 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 6249D98091; Wed, 27 Oct 2010 09:28:38 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20101026071055.GA71072@elstar.local> <20101027101652.GA75434@elstar.local> <20101027143730.GA872@elstar.local> Date: Wed, 27 Oct 2010 09:28:38 -0700 In-Reply-To: <20101027143730.GA872@elstar.local> (Juergen Schoenwaelder's message of "Wed, 27 Oct 2010 16:37:30 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: isms@ietf.org Subject: Re: [Isms] new charter proposal 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, 27 Oct 2010 16:27:10 -0000 >>>>> On Wed, 27 Oct 2010 16:37:30 +0200, Juergen Schoenwaelder said: JS> There is an attachment; at least there was one when the email went JS> out. Doh! Bad mail reader hiding that button from me so well. Sorry. -- Wes Hardaker Cobham Analytic Solutions From yiu_lee@cable.comcast.com Wed Oct 27 09:30: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 581ED3A680C for ; Wed, 27 Oct 2010 09:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.425 X-Spam-Level: X-Spam-Status: No, score=-107.425 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 IxW-XLezyzYz for ; Wed, 27 Oct 2010 09:30:36 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 075B33A6998 for ; Wed, 27 Oct 2010 09:30:24 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.102667113; Wed, 27 Oct 2010 12:32:06 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0255.000; Wed, 27 Oct 2010 12:32:06 -0400 From: "Lee, Yiu" To: "David B. Nelson" , "Pejaver, Rajaram" Thread-Topic: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 Thread-Index: AQHLde5ebRgiVPUr90uPuV+1K2B6WJNU/RyA Date: Wed, 27 Oct 2010 16:32:04 +0000 Message-ID: In-Reply-To: <341DF6B0-7A48-4939-BEAB-134143C3ABFC@elbrys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <38A49BBBF5933F43A5471EE9765588D1@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "isms@ietf.org" Subject: Re: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 16:30:40 -0000 Hi Dave, We are indeed trying to use the AAA-VACM model. We are still investigating it. If this is workable, we will suggest some text in the AAA-VACM draft. Trust me, we don't want to invent a wheel if we don't have to. Thanks, Yiu On 10/27/10 11:48 AM, "David B. Nelson" wrote: >On Oct 27, 2010, at 9:42 AM, Pejaver, Rajaram wrote: > >> The recent radius-vacm work found a way to deal with this issue and >> KSM follows exactly the same path. > >Will you be using the same MIB module that was introduced in the AAA-VACM >work? It seems like introducing a similar (or nearly identical) one with >a different set of OIDs would be less than optimal. > >If you are indeed reusing the mechanisms of the AAA-VACM work, perhaps >all you need to do is reference that (pending) RFC and explain the >translation of terms in your draft, e.g. what the equivalents of >"User-Name" and ""Management-Policy-Id" are in the Kerberos framework. >Duplicating the elements of procedure and MIB module in the KSM document >would serve no useful purpose if the mechanism is indeed the same. Some >effort went into word-smithing the AAA-VACM document to make it >re-useable for other AAA services, which could certainly include Kerberos. > From rajaram_pejaver@cable.comcast.com Wed Oct 27 09:39:33 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 283413A6803 for ; Wed, 27 Oct 2010 09:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.23 X-Spam-Level: X-Spam-Status: No, score=-108.23 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 dBgavbNRpCSl for ; Wed, 27 Oct 2010 09:39:30 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id DBFD53A6A3B for ; Wed, 27 Oct 2010 09:37:39 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.102668670; Wed, 27 Oct 2010 12:38:46 -0400 Received: from PACDCEXMB03.cable.comcast.com ([fe80::c9c:28ac:e945:214f]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0255.000; Wed, 27 Oct 2010 12:38:46 -0400 From: "Pejaver, Rajaram" To: Wes Hardaker Thread-Topic: fyi: [kerberos security model for snmp] Thread-Index: AQHLdeDZ/PsDqsdHEkqNxKsr8uBPkZNU7dag Date: Wed, 27 Oct 2010 16:38:45 +0000 Message-ID: <755EF2E97BFCD84F9E40633C63A458E60236C2@PACDCEXMB03.cable.comcast.com> References: <20101026081401.GB71495@elstar.local> <011301cb752c$b7a8e0a0$4001a8c0@gateway.2wire.net> <755EF2E97BFCD84F9E40633C63A458E6022CBA@PACDCEXMB03.cable.comcast.com> <20101027095332.GA75386@elstar.local> <755EF2E97BFCD84F9E40633C63A458E60231A3@PACDCEXMB03.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.248.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: isms Subject: Re: [Isms] fyi: [kerberos security model for snmp] 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, 27 Oct 2010 16:39:33 -0000 Wes said: [WES] PR> The table on the responder must not have any preexisting [WES] PR> non-volatile entries for KSM. [WES] I think that's not the correct behavior. Operators should be able to [WES] configure the VACM and I think the radius draft addresses this and th= e [WES] KSM draft needs to as well. I agree that pre-configuration of local name->group mappings may be useful = sometimes, especially while testing & trouble shooting devices. Question, is an error generated if the existing entry is non-volatile, and = the new groupName is different from the existing one? Or is the old value silently used, thereby potentially causing an inexplica= ble error later in isAccessAllowed()? Where can I find the answer? Say a request comes in with sufficient privileges, but there is a previousl= y configured value with insufficient privileges inadvertently left behind on the managed= device. The resulting error could be confusing. It won't point to the root cause. Also, Security fascists typically do not like locally unique security setti= ngs. Say KSM adds an entry to the table like { securityModel, securityName, grou= pName, sessionID } The sessionID must be a number unique for each new command request. This aligns KSM with radius-vacm. It also solves the problem of having multiple concurrent requests from the = same principal but with different groupNames, if that ever happens. But it takes away the capability of pre-configuration of local name->group = mappings. I am just thinking, but perhaps the ideal behavior could be for VACM to sea= rch the table for a match on the sessionID first. If no entry is found, then that means that no authorization information was= found in the ticket. VACM could then look for a default non-volatile entry and use that value. Food for thought for later. Much much later... --raj Rajaram Pejaver Comcast From randy_presuhn@mindspring.com Wed Oct 27 12:30:07 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 A2D493A68E1 for ; Wed, 27 Oct 2010 12:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HiaeVzlEDpPz for ; Wed, 27 Oct 2010 12:30:06 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id B2B533A68DA for ; Wed, 27 Oct 2010 12:30:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=niu3VmbMdqsHh5KeHO6/uvXgaA02J3++k81wWhMAEiML5/+sBnNZrIhliy9u5EgA; 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.144.116] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PBBis-0006KU-RN for isms@ietf.org; Wed, 27 Oct 2010 15:31:47 -0400 Message-ID: <005601cb760d$bf5719c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Wed, 27 Oct 2010 12:32:24 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe18b361d0ef4068f2af8b4997940cdf7f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.116 Subject: Re: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 19:30:07 -0000 Hi - > From: "Lee, Yiu" > To: "David B. Nelson" ; "Pejaver, Rajaram" > Cc: > Sent: Wednesday, October 27, 2010 9:32 AM > Subject: Re: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 ... > We are indeed trying to use the AAA-VACM model. We are still investigating > it. If this is workable, we will suggest some text in the AAA-VACM draft. ... I asked for input specifically with respect to the Kerberos work quite some time ago. The AAA-VACM document is now in the RFC editor queue, so it's really too late for change proposals. If you think a change would be necessary, then I guess the path to take would be to add a bis effort to this WG's charter. Randy From yiu_lee@cable.comcast.com Wed Oct 27 12:36: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 291D63A67B7 for ; Wed, 27 Oct 2010 12:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.517 X-Spam-Level: X-Spam-Status: No, score=-107.517 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 i-hmDtu5bOdq for ; Wed, 27 Oct 2010 12:36:08 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 51BE63A68B0 for ; Wed, 27 Oct 2010 12:36:08 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.102710799; Wed, 27 Oct 2010 15:37:56 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0255.000; Wed, 27 Oct 2010 15:37:56 -0400 From: "Lee, Yiu" To: Randy Presuhn , "isms@ietf.org" Thread-Topic: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 Thread-Index: AQHLdg50oJIKSgB5rk2Q72b5gG/jXg== Date: Wed, 27 Oct 2010 19:37:56 +0000 Message-ID: In-Reply-To: <005601cb760d$bf5719c0$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <4824E34F53F8FD41B0B540793E0D987C@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Isms] FW: New Version Notification fordraft-pejaver-isms-kerberos-01 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, 27 Oct 2010 19:36:10 -0000 Hi Randy, I feel sorry that we missed the train. I guess we can put some text in the KSM draft. I don't think this will be a very urgent deal. Thanks, Yiu On 10/27/10 3:32 PM, "Randy Presuhn" wrote: >Hi - > >> From: "Lee, Yiu" >> To: "David B. Nelson" ; "Pejaver, Rajaram" >> >> Cc: >> Sent: Wednesday, October 27, 2010 9:32 AM >> Subject: Re: [Isms] FW: New Version Notification >>fordraft-pejaver-isms-kerberos-01 >... >> We are indeed trying to use the AAA-VACM model. We are still >>investigating >> it. If this is workable, we will suggest some text in the AAA-VACM >>draft. >... > >I asked for input specifically with respect to the Kerberos work quite >some >time ago. > >The AAA-VACM document is now in the RFC editor queue, so it's >really too late for change proposals. If you think a change would be >necessary, then I guess the path to take would be to add a bis >effort to this WG's charter. > >Randy > >_______________________________________________ >Isms mailing list >Isms@ietf.org >https://www.ietf.org/mailman/listinfo/isms From randy_presuhn@mindspring.com Wed Oct 27 12:45:33 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 D91193A68B9 for ; Wed, 27 Oct 2010 12:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Y-ywk2w2hh7i for ; Wed, 27 Oct 2010 12:45:17 -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 9FC8C3A6981 for ; Wed, 27 Oct 2010 12:45:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kU7JW2jaY8s0KHyD0cb3p6vJgs4r8ZXR+bc20QDykYZL7FuFSGexcaqQmM28anP+; 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.144.116] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PBBxi-0005QH-94 for isms@ietf.org; Wed, 27 Oct 2010 15:47:06 -0400 Message-ID: <006d01cb760f$f53884a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "isms" References: <20101026081401.GB71495@elstar.local><011301cb752c$b7a8e0a0$4001a8c0@gateway.2wire.net><755EF2E97BFCD84F9E40633C63A458E6022CBA@PACDCEXMB03.cable.comcast.com><20101027095332.GA75386@elstar.local><755EF2E97BFCD84F9E40633C63A458E60231A3@PACDCEXMB03.cable.comcast.com> <755EF2E97BFCD84F9E40633C63A458E60236C2@PACDCEXMB03.cable.comcast.com> Date: Wed, 27 Oct 2010 12:48:40 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5feb71bdfa2b502795d1b5e5070ef08d18e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.116 Subject: Re: [Isms] fyi: [kerberos security model for snmp] 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, 27 Oct 2010 19:45:33 -0000 Hi - > From: "Pejaver, Rajaram" > To: "Wes Hardaker" > Cc: "isms" > Sent: Wednesday, October 27, 2010 9:38 AM > Subject: Re: [Isms] fyi: [kerberos security model for snmp] ... > Question, is an error generated if the existing entry is non-volatile, and the new groupName > is different from the existing one? > Or is the old value silently used, thereby potentially causing an inexplicable error > later in isAccessAllowed()? > Where can I find the answer? http://www.ietf.org/id/draft-ietf-isms-radius-vacm-11.txt 7.2.3 > Say a request comes in with sufficient privileges, but there is a previously configured > value with insufficient privileges inadvertently left behind on the managed device. > The resulting error could be confusing. It won't point to the root cause. > Also, Security fascists typically do not like locally unique security settings. Discussed at length on this WG mailing list. Conclusion was that a device-specific policy explicitly configured by a security administrator should indeed take precedence over "global" AAA settings. > Say KSM adds an entry to the table like { securityModel, securityName, groupName, sessionID } > The sessionID must be a number unique for each new command request. This would work, but why is a new number *necessary* for each command request? Maintaining a small amount of state within KSM would avoid this overhead. > This aligns KSM with radius-vacm. > It also solves the problem of having multiple concurrent requests from the same principal > but with different groupNames, if that ever happens. I think http://www.ietf.org/id/draft-ietf-isms-radius-vacm-11.txt 7.3 already addresses this issue. > But it takes away the capability of pre-configuration of local name->group mappings. How/Why? > I am just thinking, but perhaps the ideal behavior could be for VACM to search the table > for a match on the sessionID first. VACM knows absolutely nothing about sessions. Do you perhaps mean KSM? > If no entry is found, then that means that no authorization information was found in the ticket. > VACM could then look for a default non-volatile entry and use that value. > Food for thought for later. Much much later... This sounds like an overly convoluted approach. Randy From ietfdbh@comcast.net Thu Oct 28 23:32:46 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 E64463A6A27 for ; Thu, 28 Oct 2010 23:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 rSdHImPB7kdA for ; Thu, 28 Oct 2010 23:28:47 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 7A5183A6879 for ; Thu, 28 Oct 2010 23:28:47 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta15.emeryville.ca.mail.comcast.net with comcast id QWGA1f0031GXsucAFWWh9i; Fri, 29 Oct 2010 06:30:41 +0000 Received: from 23FX1C1 ([98.173.74.148]) by omta07.emeryville.ca.mail.comcast.net with comcast id QWWR1f0033By9Sy8UWWUUl; Fri, 29 Oct 2010 06:30:39 +0000 From: "David Harrington" To: "'Pejaver, Rajaram'" , "'Donati Andrew-MGIA0477'" , "'Lee, Yiu'" , References: <20101025182647.EC7E83A68A2@core3.amsl.com> <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> Date: Fri, 29 Oct 2010 02:30:29 -0400 Message-ID: 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.5994 Thread-Index: AQHLddVurBtmA+Yc206Kx6p3GvMp6pNUv32QgAEJeGA= In-Reply-To: <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> Subject: Re: [Isms] FW: New VersionNotification fordraft-pejaver-isms-kerberos-01 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, 29 Oct 2010 06:32:46 -0000 Hi, The RFC3411 architecture and the 5590 update are very specific about which subsystem has knowledge of what data. The ASIs identify the expected input/output and processing of each subsystem (and specific models within those subsystems). If you are developing a model or models to fit into the RFC3411 architecture, you should go study RFC3411 (and 5590) to make sure you understand the way data flows between subsystems. Your current language shows a lack of understanding of the modularity of the system. The RFC3411 architecture is hard to master, but you will probably need to master it to specify a model correctly. The handling of authentication, authroization of a transport session, and authorization of data access can be split across different susbsystems/models. You need to understand how they are handled within an RFC3411 architecture. The conceptual handling can be very different than that of Kerberos, and you need to find the correct way to map them to the conceptual handling of RFC3411-compatible models. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Pejaver, Rajaram > Sent: Wednesday, October 27, 2010 9:43 AM > To: Donati Andrew-MGIA0477; Lee, Yiu; isms@ietf.org > Subject: Re: [Isms] FW: New VersionNotification > fordraft-pejaver-isms-kerberos-01 > > In response to Andy Donati: > > > [AD] Here are a few quick comments on draft -01 > > Thanks. Yiu may chime in with his own responses as well. > > > [AD] If using the [RFC3411] designation with SNMP, the term > 'architecture' > [AD] should probably be included. The reference to RFC3411 > can otherwise be > [AD] left out when mentioning SNMP in general. > > Are you suggesting adding the word 'architecture' after SNMPv3? > Pls restate. > > > [AD] >The first security models, USM [RFC3414] and VACM [RFC3415]... > [AD] (Others have previously brought up this topic) > [AD] The latter is an access control model which can be used within a > [AD] security model as discussed in section 2.6. Are you > proposing the use > [AD] of VACM or some other access control model to be used > within the KSM > [AD] security model? > > KSM will use VACM as described in the RFC 3415 standard. > VACM, as originally envisioned, had a username -> group > mapping that was > implicitly local to each managed device. Since that is hard > to manage on most > large networks, we envision this mapping to be done centrally. > The recent radius-vacm work found a way to deal with this issue and > KSM follows exactly the same path. > > > [AD] Section 2.4 > [AD] >authPriv - with both authentication and > privacy...scopedPDU will be > [AD] further protected for confidentiality. > [AD] 'Further protected' could stand for encryption for > privacy. Draft 00 > [AD] discussed using the PAC (Privilege Attribute > Certificate) for defining > [AD] encryption requirements. Perhaps a section can be added > discussing an > [AD] encryption protocol and the possible use of the PAC if > it's still chosen > [AD] to be used. > > Version -01 matured beyond -00 in many ways. (Or perhaps I did :-) > Yes, the scopedPDU must be encrypted as stated in s4.1. > Kerberos has a prescribed way to encrypt data, and KSM must > use that way. > > We replaced the term PAC with 'authorization information'. > PAC implies a certificate, which implies a signature, which > we don't need. > I was initially imagining more flexible (complicated) > encryption requirements. > The correct (simpler) way is to just use securityLevel. > > > [AD] Section 3.4 > [AD] >securityModel: Must be Kerberos Security Model (KSM). > [AD] The KSM security model needs a defined enumeration. > Should this be 4 ? > > Don't know yet. We need a lucky number. > > > [AD] General comment: > [AD] Will if be helpful to define a MIB module for visibility > in monitoring > [AD] KSM transactions? > [AD] Error definitions defined in RFC4120 section 3.2.3 can > be used as a > [AD] basis for counters. The following are some examples. > > Agreed. TBD in upcoming revisions. > > Thanks again. > > --raj > Rajaram Pejaver > Comcast > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfdbh@comcast.net Thu Oct 28 23:36:04 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 BB04A3A680B for ; Thu, 28 Oct 2010 23:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XruE5nDdwlVG for ; Thu, 28 Oct 2010 23:36:04 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 7A5183A6879 for ; Thu, 28 Oct 2010 23:28:47 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta15.emeryville.ca.mail.comcast.net with comcast id QWGA1f0031GXsucAFWWh9i; Fri, 29 Oct 2010 06:30:41 +0000 Received: from 23FX1C1 ([98.173.74.148]) by omta07.emeryville.ca.mail.comcast.net with comcast id QWWR1f0033By9Sy8UWWUUl; Fri, 29 Oct 2010 06:30:39 +0000 From: "David Harrington" To: "'Pejaver, Rajaram'" , "'Donati Andrew-MGIA0477'" , "'Lee, Yiu'" , References: <20101025182647.EC7E83A68A2@core3.amsl.com> <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> Date: Fri, 29 Oct 2010 02:30:29 -0400 Message-ID: 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.5994 Thread-Index: AQHLddVurBtmA+Yc206Kx6p3GvMp6pNUv32QgAEJeGA= In-Reply-To: <755EF2E97BFCD84F9E40633C63A458E60231DA@PACDCEXMB03.cable.comcast.com> Subject: Re: [Isms] FW: New VersionNotification fordraft-pejaver-isms-kerberos-01 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, 29 Oct 2010 06:36:04 -0000 Hi, The RFC3411 architecture and the 5590 update are very specific about which subsystem has knowledge of what data. The ASIs identify the expected input/output and processing of each subsystem (and specific models within those subsystems). If you are developing a model or models to fit into the RFC3411 architecture, you should go study RFC3411 (and 5590) to make sure you understand the way data flows between subsystems. Your current language shows a lack of understanding of the modularity of the system. The RFC3411 architecture is hard to master, but you will probably need to master it to specify a model correctly. The handling of authentication, authroization of a transport session, and authorization of data access can be split across different susbsystems/models. You need to understand how they are handled within an RFC3411 architecture. The conceptual handling can be very different than that of Kerberos, and you need to find the correct way to map them to the conceptual handling of RFC3411-compatible models. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Pejaver, Rajaram > Sent: Wednesday, October 27, 2010 9:43 AM > To: Donati Andrew-MGIA0477; Lee, Yiu; isms@ietf.org > Subject: Re: [Isms] FW: New VersionNotification > fordraft-pejaver-isms-kerberos-01 > > In response to Andy Donati: > > > [AD] Here are a few quick comments on draft -01 > > Thanks. Yiu may chime in with his own responses as well. > > > [AD] If using the [RFC3411] designation with SNMP, the term > 'architecture' > [AD] should probably be included. The reference to RFC3411 > can otherwise be > [AD] left out when mentioning SNMP in general. > > Are you suggesting adding the word 'architecture' after SNMPv3? > Pls restate. > > > [AD] >The first security models, USM [RFC3414] and VACM [RFC3415]... > [AD] (Others have previously brought up this topic) > [AD] The latter is an access control model which can be used within a > [AD] security model as discussed in section 2.6. Are you > proposing the use > [AD] of VACM or some other access control model to be used > within the KSM > [AD] security model? > > KSM will use VACM as described in the RFC 3415 standard. > VACM, as originally envisioned, had a username -> group > mapping that was > implicitly local to each managed device. Since that is hard > to manage on most > large networks, we envision this mapping to be done centrally. > The recent radius-vacm work found a way to deal with this issue and > KSM follows exactly the same path. > > > [AD] Section 2.4 > [AD] >authPriv - with both authentication and > privacy...scopedPDU will be > [AD] further protected for confidentiality. > [AD] 'Further protected' could stand for encryption for > privacy. Draft 00 > [AD] discussed using the PAC (Privilege Attribute > Certificate) for defining > [AD] encryption requirements. Perhaps a section can be added > discussing an > [AD] encryption protocol and the possible use of the PAC if > it's still chosen > [AD] to be used. > > Version -01 matured beyond -00 in many ways. (Or perhaps I did :-) > Yes, the scopedPDU must be encrypted as stated in s4.1. > Kerberos has a prescribed way to encrypt data, and KSM must > use that way. > > We replaced the term PAC with 'authorization information'. > PAC implies a certificate, which implies a signature, which > we don't need. > I was initially imagining more flexible (complicated) > encryption requirements. > The correct (simpler) way is to just use securityLevel. > > > [AD] Section 3.4 > [AD] >securityModel: Must be Kerberos Security Model (KSM). > [AD] The KSM security model needs a defined enumeration. > Should this be 4 ? > > Don't know yet. We need a lucky number. > > > [AD] General comment: > [AD] Will if be helpful to define a MIB module for visibility > in monitoring > [AD] KSM transactions? > [AD] Error definitions defined in RFC4120 section 3.2.3 can > be used as a > [AD] basis for counters. The following are some examples. > > Agreed. TBD in upcoming revisions. > > Thanks again. > > --raj > Rajaram Pejaver > Comcast > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfc@btconnect.com Fri Oct 29 04:40:22 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 6D3CD3A6848 for ; Fri, 29 Oct 2010 04:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 zkE5lNHwif+W for ; Fri, 29 Oct 2010 04:40:21 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by core3.amsl.com (Postfix) with ESMTP id E5F2D3A6A10 for ; Fri, 29 Oct 2010 04:40:14 -0700 (PDT) Received: from host86-156-136-67.range86-156.btcentralplus.com (HELO pc6) ([86.156.136.67]) by c2bthomr10.btconnect.com with SMTP id AMS38640; Fri, 29 Oct 2010 12:42:04 +0100 (BST) Message-ID: <04ec01cb7755$c054cea0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" References: <20101026071055.GA71072@elstar.local><20101027101652.GA75434@elstar.local> <20101027143730.GA872@elstar.local> Date: Fri, 29 Oct 2010 12:40:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4CCAB2FD.01D5, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4CCAB30F.00F8,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: isms@ietf.org Subject: Re: [Isms] new charter proposal 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, 29 Oct 2010 11:40:22 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Wes Hardaker" Cc: Sent: Wednesday, October 27, 2010 4:37 PM > On Wed, Oct 27, 2010 at 07:15:30AM -0700, Wes Hardaker wrote: > > >>>>> On Wed, 27 Oct 2010 12:16:52 +0200, Juergen Schoenwaelder said: > > > > JS> Thanks for getting this going. I have modified your text to remove > > JS> some redundancy. > > > > Much of the redundancy was due to me copying the format of the existing > > charter, which was very redundant! > > > > JS> For the TLS advancement, I have modified [...] > > > > You didn't include your modified version in your post. > > There is an attachment; at least there was one when the email went > out. There was still an attachment when it reached me:-) I think that the references to not modifying STD62 are wrong in that that is no longer the standard to which we work; rather, that has been updated by RFC5590 and so it is RFC5590 that we should now be respecting. This is a very practical consideration with the current KSM draft which appears to ignore RFC5590 totally. Tom Petch > > > JS> I think this looks more realistic and since we can't advance before > > JS> six months have passed, there is not much difference anyway. > > > > The original draft versions of the SNMPv3 docs were sent to the IESG > > before the 6 months had expired. They just weren't published until the > > 6 month mark, and I was hoping to do the same not "be speedy" but > > because I don't expect much work and don't see a benefit to dragging it out. > > It is always possible to be faster than the milestones state on the > charter. ;-) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Fri Oct 29 05:08:41 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 78D4B3A6A31 for ; Fri, 29 Oct 2010 05:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.746 X-Spam-Level: X-Spam-Status: No, score=-101.746 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] 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 DlnL-FbiCyCy for ; Fri, 29 Oct 2010 05:08:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8C8773A683B for ; Fri, 29 Oct 2010 05:08:39 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81B28C0016; Fri, 29 Oct 2010 14:10:33 +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 sGw0rLYTQ8Wm; Fri, 29 Oct 2010 14:10:33 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C00CCC0024; Fri, 29 Oct 2010 14:10:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0725C1588394; Fri, 29 Oct 2010 14:10:30 +0200 (CEST) Date: Fri, 29 Oct 2010 14:10:30 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20101029121030.GA7604@elstar.local> Mail-Followup-To: "t.petch" , isms@ietf.org References: <20101026071055.GA71072@elstar.local> <20101027101652.GA75434@elstar.local> <20101027143730.GA872@elstar.local> <04ec01cb7755$c054cea0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04ec01cb7755$c054cea0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: isms@ietf.org Subject: Re: [Isms] new charter proposal 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: Fri, 29 Oct 2010 12:08:41 -0000 On Fri, Oct 29, 2010 at 12:40:30PM +0200, t.petch wrote: > I think that the references to not modifying STD62 are wrong in that > that is no longer the standard to which we work; rather, that has > been updated by RFC5590 and so it is RFC5590 that we should now be > respecting. I think we should be explicit about STD62 and RFC5590. Here is the new text: The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types) and it must be consistent with RFC 5590. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Sat Oct 30 10:23:41 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 AC7283A69C5 for ; Sat, 30 Oct 2010 10:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_40=-0.185, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XMC5fi2Bhwh for ; Sat, 30 Oct 2010 10:23:40 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by core3.amsl.com (Postfix) with ESMTP id 7C3D43A6A25 for ; Sat, 30 Oct 2010 10:23:39 -0700 (PDT) Received: from host86-156-136-67.range86-156.btcentralplus.com (HELO pc6) ([86.156.136.67]) by c2bthomr10.btconnect.com with SMTP id ANA94050; Sat, 30 Oct 2010 18:25:30 +0100 (BST) Message-ID: <00a301cb784e$e3b40880$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" References: <20101026071055.GA71072@elstar.local> <20101027101652.GA75434@elstar.local> <20101027143730.GA872@elstar.local> <04ec01cb7755$c054cea0$4001a8c0@gateway.2wire.net> <20101029121030.GA7604@elstar.local> Date: Sat, 30 Oct 2010 18:24:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CCC550A.0091, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4CCC550F.0072,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: isms@ietf.org Subject: Re: [Isms] new charter proposal 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, 30 Oct 2010 17:23:41 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" To: "t.petch" Cc: Sent: Friday, October 29, 2010 2:10 PM > On Fri, Oct 29, 2010 at 12:40:30PM +0200, t.petch wrote: > > > I think that the references to not modifying STD62 are wrong in that > > that is no longer the standard to which we work; rather, that has > > been updated by RFC5590 and so it is RFC5590 that we should now be > > respecting. > > I think we should be explicit about STD62 and RFC5590. Here is the new > text: > > The new work must not modify any other aspects of SNMPv3 protocol > as defined in STD 62 (e.g., it must not create new PDU types) and > it must be consistent with RFC 5590. Looks good to me Tom Petch > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103