From wjhns1@hardakers.net Thu Jul 2 10:18:08 2009 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 00AF43A6B5F for ; Thu, 2 Jul 2009 10:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, 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 0ncSt5ZCpupo for ; Thu, 2 Jul 2009 10:18:07 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 8DEF53A69F0 for ; Thu, 2 Jul 2009 10:18:06 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id DAC979810E; Thu, 2 Jul 2009 10:18:28 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 775D539A0EA; Thu, 2 Jul 2009 10:18:28 -0700 (PDT) From: Wes Hardaker To: "Donati Andrew-MGIA0477" Organization: Sparta References: Date: Thu, 02 Jul 2009 10:18:27 -0700 In-Reply-To: (Donati Andrew-MGIA's message of "Tue, 30 Jun 2009 23:25:26 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to use 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, 02 Jul 2009 17:18:08 -0000 >>>>> On Tue, 30 Jun 2009 23:25:26 -0400, "Donati Andrew-MGIA0477" said: Donati, Thanks for the response and the opinion. DA> -- Since RowStatus and StorageType are already present the DA> snmpTargetParams table, it may be conflicting to have these columns DA> duplicated in the augmenting tlstmParams table. I don't think so. Not every row in the snmpTargetParams table will have an entry in the tlstmParamsTable so creation needs to be managed independently. It could be done either way, you're right but I think it makes more sense to have a separate creation/deletion object. Other opinions are welcome on the subject though. However, it shouldn't be an AUGMENT in the first place. I've changed the next to be an identical copy of the snmpTargetParamsTable index since it's not a 1:1 mapping, which rules out AUGMENT usage in the first place. Regardless the fate sharing needs to be documented better than it is currently so I'll work on the wording for that. DA> Note that the tlstmParamsRowStatus description states that "The DA> value of this object has no effect on whether other objects in this DA> conceptual row can be modified" and the values for objects in the DA> snmpTargetParams table cannot be set if the RowStatus is active. Well, I suppose that I should copy that table's method of modification method you're right. DA> -- The tlstmParamsHashValue object may need to have a default value DA> defined. Well, it'd have to default to "" which isn't helpful. I think I'd rather state that the row can't be made active unless the values are legally set. There is no sensible default value. How's this for new text for the tlstmParamsRowStatus object: tlstmParamsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the tlstmParamsRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding tlstmParamsClientHashType, and tlstmParamsClientHashValue have both been set. The row may not be made active(1) if the tlstmParamsClientHashValue object is not of a length suitable for use with the corresponding tlstmParamsClientHashType. The following objects may not be modified while the value of this object is active(1): - tlstmParamsClientHashType - tlstmParamsClientHashValue An attempt to set these objects while the value of tlstmParamsRowStatus is active(1) will result in an inconsistentValue error. The value of this object has no effect on whether other objects in this conceptual row can be modified. If this row is deleted it has no effect on the corresponding row in the tlstmParamsTable. If the corresponding row in the tlstmParamsTable is deleted then this row must be automatically removed." -- Wes Hardaker Cobham Analytic Solutions From adonati@motorola.com Thu Jul 2 12:13:00 2009 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 ABB943A6DDD for ; Thu, 2 Jul 2009 12:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 6tzm-VWVPRfo for ; Thu, 2 Jul 2009 12:12:59 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 6A8D63A6DD5 for ; Thu, 2 Jul 2009 12:12:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-4.tower-55.messagelabs.com!1246561993!84759204!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 16412 invoked from network); 2 Jul 2009 19:13:13 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-4.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2009 19:13:13 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n62JDDIK017114 for ; Thu, 2 Jul 2009 12:13:13 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n62JDCA7018923 for ; Thu, 2 Jul 2009 14:13:12 -0500 (CDT) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n62JDCgO018905 for ; Thu, 2 Jul 2009 14:13:12 -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: Thu, 2 Jul 2009 15:12:50 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (D)TLS question (#1): selecting a client certificate to use Thread-Index: Acn7O2cvitYsG4kwRtuAp6xl/iCDBQAAT3vw References: From: "Donati Andrew-MGIA0477" To: "Wes Hardaker" X-CFilter-Loop: Reflected Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to use 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, 02 Jul 2009 19:13:00 -0000 Wes,=20 Thanks for the update. WH> -- However, it shouldn't be an AUGMENT in the first place. =20 WH> -- I've changed the next to be an identical copy of the snmpTargetParamsTable WH> -- index since it's not a 1:1 mapping, which rules out AUGMENT usage in the first place.=20 Agreed. ... and if the table is not an AUGMENT, it needs to have it's own separate RowStatus and StorageType columns. =20 >AD> -- The tlstmParamsHashValue object may need to have a default value >AD> -- defined. =20 WH> -- Well, it'd have to default to "" which isn't helpful. I think I'd rather state that the row WH> -- can't be made active unless the values are legally set. There is no sensible default value. =20 You're right. Since tlstmParamsRowStatus will now be in control of it's own table and the new text in the description clause states that the value of tlstmParamsClientHashValue needs to meet certain criteria before being activated, it may not be especially helpful if there is a DEFVAL clause present.=20 WH> -- How's this for new text for the tlstmParamsRowStatus object: It looks very good. =20 If the corresponding row in the tlstmParamsTable is deleted and the row is automatically removed, I am assuming that setting tlstmParamsRowStatus to createAndGo(4) or createAndWait(5) returns an error if the corresponding row in the tlstmParamsTable is not present. If so, maybe this can be added in the description text ? I'm not too sure what the appropriate error code should be in this case (inconsistentValue ? ) - I'll need to take a closer look at RFC2579. =20 Andy Donati Motorola HN&M -----Original Message----- From: Wes Hardaker [mailto:wjhns1@hardakers.net]=20 Sent: Thursday, July 02, 2009 1:18 PM To: Donati Andrew-MGIA0477 Cc: Wes Hardaker; isms@ietf.org Subject: Re: (D)TLS question (#1): selecting a client certificate to use >>>>> On Tue, 30 Jun 2009 23:25:26 -0400, "Donati Andrew-MGIA0477" said: Donati, Thanks for the response and the opinion. DA> -- Since RowStatus and StorageType are already present the=20 DA> snmpTargetParams table, it may be conflicting to have these columns=20 DA> duplicated in the augmenting tlstmParams table. I don't think so. Not every row in the snmpTargetParams table will have an entry in the tlstmParamsTable so creation needs to be managed independently. It could be done either way, you're right but I think it makes more sense to have a separate creation/deletion object. Other opinions are welcome on the subject though. However, it shouldn't be an AUGMENT in the first place. I've changed the next to be an identical copy of the snmpTargetParamsTable index since it's not a 1:1 mapping, which rules out AUGMENT usage in the first place. Regardless the fate sharing needs to be documented better than it is currently so I'll work on the wording for that. DA> Note that the tlstmParamsRowStatus description states that "The=20 DA> value of this object has no effect on whether other objects in this=20 DA> conceptual row can be modified" and the values for objects in the=20 DA> snmpTargetParams table cannot be set if the RowStatus is active. Well, I suppose that I should copy that table's method of modification method you're right. DA> -- The tlstmParamsHashValue object may need to have a default value DA> defined. =20 Well, it'd have to default to "" which isn't helpful. I think I'd rather state that the row can't be made active unless the values are legally set. There is no sensible default value. How's this for new text for the tlstmParamsRowStatus object: tlstmParamsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the tlstmParamsRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding tlstmParamsClientHashType, and tlstmParamsClientHashValue have both been set. The row may not be made active(1) if the tlstmParamsClientHashValue object is not of a length suitable for use with the corresponding tlstmParamsClientHashType. The following objects may not be modified while the value of this object is active(1): - tlstmParamsClientHashType - tlstmParamsClientHashValue An attempt to set these objects while the value of tlstmParamsRowStatus is active(1) will result in an inconsistentValue error. The value of this object has no effect on whether other objects in this conceptual row can be modified. If this row is deleted it has no effect on the corresponding row in the tlstmParamsTable. If the corresponding row in the tlstmParamsTable is deleted then this row must be automatically removed." -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Fri Jul 3 10:06:25 2009 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 073423A6F46 for ; Fri, 3 Jul 2009 10:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 foXIRnfrBBDw for ; Fri, 3 Jul 2009 10:06:24 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 17B683A6CE9 for ; Fri, 3 Jul 2009 10:06:24 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 30C70980EE; Fri, 3 Jul 2009 10:06:45 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 9606F39A0EB; Fri, 3 Jul 2009 10:06:44 -0700 (PDT) From: Wes Hardaker To: "Donati Andrew-MGIA0477" Organization: Sparta References: Date: Fri, 03 Jul 2009 10:06:44 -0700 In-Reply-To: (Donati Andrew-MGIA's message of "Thu, 2 Jul 2009 15:12:50 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to use 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, 03 Jul 2009 17:06:25 -0000 >>>>> On Thu, 2 Jul 2009 15:12:50 -0400, "Donati Andrew-MGIA0477" said: DA> If the corresponding row in the tlstmParamsTable is deleted and the DA> row is automatically removed, I am assuming that setting DA> tlstmParamsRowStatus to createAndGo(4) or createAndWait(5) returns DA> an error if the corresponding row in the tlstmParamsTable is not DA> present. Good point. The options are: 1) let the row be created in anticipation of another being created later in the snmpTargetPararms table. 2) prohibit it with inconsistentValue, which I agree is the right choice. When deleting, I think it makes sense to auto-remove the column from the tlstmParamsTable table since it's unlikely you'd want it there in the future. But, I don't necessarily think that's true for creation and I don't see us getting a huge amount of benefit from disallowing the creation of a row in the tlstmParamsTable table when the row in the snmpTargetParams doesn't exist. But you're right, that doesn't feel consistent either. Opinions welcome :-) -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Fri Jul 3 10:33:25 2009 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 0A2663A6F3D for ; Fri, 3 Jul 2009 10:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7OF8pZ2WRu8 for ; Fri, 3 Jul 2009 10:33:24 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 1737D3A6CAA for ; Fri, 3 Jul 2009 10:33:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DI5GswwfhXCLf+9RlIS8fk69wMh4UEhGPsGQgWs3Co/32BGo/qcOX/EaWXpWJDae; 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.25] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MMmdu-0004wn-2a for isms@ietf.org; Fri, 03 Jul 2009 13:33:46 -0400 Message-ID: <004801c9fc04$913973a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Fri, 3 Jul 2009 10:34:49 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69688b8d8e57cabc4f5eb0475234646d12cf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.25 Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate touse 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, 03 Jul 2009 17:33:25 -0000 Hi - > From: "Wes Hardaker" > To: "Donati Andrew-MGIA0477" > Cc: > Sent: Friday, July 03, 2009 10:06 AM > Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate touse ... > 1) let the row be created in anticipation of another being created later > in the snmpTargetPararms table. > 2) prohibit it with inconsistentValue, which I agree is the right > choice. > > When deleting, I think it makes sense to auto-remove the column from the > tlstmParamsTable table since it's unlikely you'd want it there in the > future. But, I don't necessarily think that's true for creation and I > don't see us getting a huge amount of benefit from disallowing the > creation of a row in the tlstmParamsTable table when the row in the > snmpTargetParams doesn't exist. But you're right, that doesn't feel > consistent either. > > Opinions welcome :-) ... I'm a bit confused. Re-reading the thread, it looks like the text under discussion is this: ------------- tlstmParamsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the tlstmParamsRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding tlstmParamsClientHashType, and tlstmParamsClientHashValue have both been set. The row may not be made active(1) if the tlstmParamsClientHashValue object is not of a length suitable for use with the corresponding tlstmParamsClientHashType. The following objects may not be modified while the value of this object is active(1): - tlstmParamsClientHashType - tlstmParamsClientHashValue An attempt to set these objects while the value of tlstmParamsRowStatus is active(1) will result in an inconsistentValue error. The value of this object has no effect on whether other objects in this conceptual row can be modified. If this row is deleted it has no effect on the corresponding row in the tlstmParamsTable. If the corresponding row in the tlstmParamsTable is deleted then this row must be automatically removed." -------- If so, I think the proposed text has a problem. Most importantly, since tlstmParamsRowStatus is part of the tlstmParamsTable, the last two sentences of the DESCRIPTION make no sense. The real question is whether there should be any "fate sharing" between it and the snmpTargetParamsTable. I'd strongly recommend that there be *no* coupling whatsoever. This would simplify implementation, testing, provisioning, and operational use. I see no benefits from "fate sharing", and lots of disadvantages. Randy From wjhns1@hardakers.net Fri Jul 3 11:36:58 2009 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 673F03A6C5D for ; Fri, 3 Jul 2009 11:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 cpHABHwZ61j7 for ; Fri, 3 Jul 2009 11:36:57 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 538883A6A19 for ; Fri, 3 Jul 2009 11:36:57 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 42E9D98125; Fri, 3 Jul 2009 11:37:20 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 1972339A0EB; Fri, 3 Jul 2009 11:37:20 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <004801c9fc04$913973a0$6801a8c0@oemcomputer> Date: Fri, 03 Jul 2009 11:37:20 -0700 In-Reply-To: <004801c9fc04$913973a0$6801a8c0@oemcomputer> (Randy Presuhn's message of "Fri, 3 Jul 2009 10:34:49 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate touse 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, 03 Jul 2009 18:36:58 -0000 >>>>> On Fri, 3 Jul 2009 10:34:49 -0700, "Randy Presuhn" said: WH> If this row is deleted it has no effect on the corresponding WH> row in the tlstmParamsTable. WH> If the corresponding row in the tlstmParamsTable is deleted WH> then this row must be automatically removed." WH> If so, I think the proposed text has a problem. RP> Most importantly, since tlstmParamsRowStatus is part of RP> the tlstmParamsTable, the last two sentences of the DESCRIPTION RP> make no sense. You're right. "tlstmParamsTable" in both those paragraphs should be "targetParamsTable". RP> The real question is whether there should be any "fate sharing" RP> between it and the snmpTargetParamsTable. I'd strongly recommend RP> that there be *no* coupling whatsoever. This would simplify RP> implementation, testing, provisioning, and operational use. I RP> see no benefits from "fate sharing", and lots of disadvantages. Thanks for the opinion. I do see advantages to having the row in the tlstmParamsTable be removed when the snmpTargetParamsTable is removed, because I think it's cleaner to do complete removal when the base config for anything is destroyed. But, I'm not going to take a hard stand on it either way. I think it'd work either way. And I don't think there is a security concern with leaving a reference to the client side key to use around even if the parent row gets replaced again. (A reference to the expected server side key, however, I'm more concerned with and was a future topic I was going to bring up but didn't want muddy the waters with more than one topic at a time) -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Fri Jul 3 15:02:28 2009 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 4AF933A6A38 for ; Fri, 3 Jul 2009 15:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 LQNIrRt5S6Dj for ; Fri, 3 Jul 2009 15:02:27 -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 682F23A6842 for ; Fri, 3 Jul 2009 15:02:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rcyZ6nOv9wl9F1T1E3iea0M70zlu1U8ClyWrhqQSmejoRhjQ1kPtaBxymXTF9yX5; 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.25] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MMqqI-0002dN-OE for isms@ietf.org; Fri, 03 Jul 2009 18:02:50 -0400 Message-ID: <000001c9fc2a$2753d040$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <004801c9fc04$913973a0$6801a8c0@oemcomputer> Date: Fri, 3 Jul 2009 14:57:39 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968c7e2b3d8d7c2876b66175ce6d240ab9b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.25 Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate touse 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, 03 Jul 2009 22:02:28 -0000 Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Friday, July 03, 2009 11:37 AM > Subject: Re: (D)TLS question (#1): selecting a client certificate touse ... > Thanks for the opinion. I do see advantages to having the row in the > tlstmParamsTable be removed when the snmpTargetParamsTable is removed, > because I think it's cleaner to do complete removal when the base config > for anything is destroyed. > > But, I'm not going to take a hard stand on it either way. I think it'd > work either way. And I don't think there is a security concern with > leaving a reference to the client side key to use around even if the > parent row gets replaced again. Look at it from the perspective of a management application which provisions / performs updates to snmpTargetParamsTable. Depending on who wrote the code and the underlying support libraries, applications can make updates by incrementally updating individual variables, by setting several at once, or by deleting a row and then creating its replacement. That application may well be ignorant of tlstmParamsTable. If there is no fate sharing, then none of the possible implementation strategies could have bad side-effects. If there is fate sharing, then any management applications that use the delete-and-create-afresh strategy would have the unintended side-effect of trashing entries in the tlstmParamsTable. I think we should avoid situations where adding a new capability to a system requires changing the behaviour of software that doesn't know (or care) about that capability. > (A reference to the expected server side key, however, I'm more > concerned with and was a future topic I was going to bring up but didn't > want muddy the waters with more than one topic at a time) When an application decides to stash sensitive bits here and there in the network, it needs to take responsibility for issuing the instructions to wipe that information when the time comes. Anything beyond that starts entering the realm of tamper-proof self-destruct memories. I don't think this is substantially different from shared keys for notifications in USM. Randy From wjhns1@hardakers.net Fri Jul 3 15:35:12 2009 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 085143A6962 for ; Fri, 3 Jul 2009 15:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 LheUzXFhUrra for ; Fri, 3 Jul 2009 15:35:11 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 2E4BA3A683F for ; Fri, 3 Jul 2009 15:35:11 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 665A398093; Fri, 3 Jul 2009 15:35:33 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 4A87439A0EB; Fri, 3 Jul 2009 15:35:33 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <004801c9fc04$913973a0$6801a8c0@oemcomputer> <000001c9fc2a$2753d040$6801a8c0@oemcomputer> Date: Fri, 03 Jul 2009 15:35:33 -0700 In-Reply-To: <000001c9fc2a$2753d040$6801a8c0@oemcomputer> (Randy Presuhn's message of "Fri, 3 Jul 2009 14:57:39 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate touse 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, 03 Jul 2009 22:35:12 -0000 >>>>> On Fri, 3 Jul 2009 14:57:39 -0700, "Randy Presuhn" said: RP> Look at it from the perspective of a management application which RP> provisions / performs updates to snmpTargetParamsTable. Yep, I had been and understood all your points. My conclusions just came out on the opposite side :-) -- Wes Hardaker Cobham Analytic Solutions From d.b.nelson@comcast.net Sun Jul 5 17:13:14 2009 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 C50263A6B73 for ; Sun, 5 Jul 2009 17:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 ic2+kBP5lO3n for ; Sun, 5 Jul 2009 17:13:14 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id E32E23A6B62 for ; Sun, 5 Jul 2009 17:13:12 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA07.westchester.pa.mail.comcast.net with comcast id CQ2J1c0030QuhwU57QDeJX; Mon, 06 Jul 2009 00:13:38 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA02.westchester.pa.mail.comcast.net with comcast id CQDe1c0044H2mdz3NQDerE; Mon, 06 Jul 2009 00:13:38 +0000 From: "Dave Nelson" To: "'Juergen Schoenwaelder'" Date: Sun, 5 Jul 2009 20:13:37 -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.5579 Thread-Index: Acn9zUe1nlxwG0U1Twq8SOy+M6mJZAAAT5xw Cc: isms@ietf.org Subject: [Isms] FW: New Version Notification for draft-nelson-isms-extended-vacm-00 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, 06 Jul 2009 00:13:14 -0000 FYI. > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Sunday, July 05, 2009 8:04 PM > To: d.b.nelson@comcast.net > Cc: kaushik_narayan@yahoo.com > Subject: New Version Notification for draft-nelson-isms-extended-vacm-00 > > > A new version of I-D, draft-nelson-isms-extended-vacm-00.txt has been > successfuly submitted by David Nelson and posted to the IETF repository. > > Filename: draft-nelson-isms-extended-vacm > Revision: 00 > Title: Extensions to View-based Access Control Model for use > with RADIUS > Creation_date: 2009-07-05 > WG ID: Independent Submission > Number_of_pages: 10 > > Abstract: > This memo describes a backward compatible extension to the View-based > Access Control Model for SNMPv3 for use with RADIUS and other AAA > services to provide authorization of MIB database access. This > extension is intended to be used in conjunction with secure SNMP > Transport Models that facilitate RADIUS authentication, such as the > Secure Shell Transport Model. > > The IETF Secretariat. From j.schoenwaelder@jacobs-university.de Mon Jul 6 01:42:52 2009 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 1ACD13A6B74 for ; Mon, 6 Jul 2009 01:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_MLH_Stock1=0.87] 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 VrwYLo2CIzwX for ; Mon, 6 Jul 2009 01:42:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2149D3A6B6C for ; Mon, 6 Jul 2009 01:42:51 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8F20C0067 for ; Mon, 6 Jul 2009 10:42: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 bKLGB087TeRJ; Mon, 6 Jul 2009 10:42: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 3AE3FC0064; Mon, 6 Jul 2009 10:42:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AD5FAB592B9; Mon, 6 Jul 2009 10:42:45 +0200 (CEST) Date: Mon, 6 Jul 2009 10:42:45 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090706084245.GA4976@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] stockholm isms wg 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: Mon, 06 Jul 2009 08:42:52 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have posted the attached draft Stockholm ISMS WG meeting agenda. Let me know if there is something that should be changed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-agenda.txt" ============================================================= Integrated Security Model for SNMP WG (isms) IETF #75, Stockholm MONDAY, July 27, 2008, 1740-1940, Room Cabaret ============================================================= WG Chair: Juergen Schoenwaelder WG URL: http://tools.ietf.org/wg/isms/ Jabber: xmpp:isms@jabber.ietf.org AGENDA: 1) Agenda bashing, WG status (10 min) (Juergen Schoenwaelder) - Blue sheets - Minute and note takers - Jabber scribe 2) DTLS / TLS Transport Model (50 min) (Wes Hardaker) 3) RADIUS / VACM Integration (50 min) (TBD) 4) Wrap up and review of action items (10 min) (Juergen Schoenwaelder) WG RFCs: [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) RFC 5590 [2] Transport Security Model for SNMP RFC 5591 [3] Secure Shell Transport Model for SNMP RFC 5592 [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models RFC Ed Queue RELATED INTERNET DRAFTS: [5] Datagram Transport Layer Security Transport Model for SNMP [6] Extensions to View-based Access Control Model for use with RADIUS [7] Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management RFC Ed Queue --W/nzBZO5zC0uMSeA-- From rpurvis@mitre.org Tue Jul 7 09:49:29 2009 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 A613928C2F9 for ; Tue, 7 Jul 2009 09:49:29 -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 yqwYvqwuKe+u for ; Tue, 7 Jul 2009 09:49:28 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7546828C2AC for ; Tue, 7 Jul 2009 09:49:28 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n67GnOp5010985 for ; Tue, 7 Jul 2009 12:49:25 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n67GnOBo010974; Tue, 7 Jul 2009 12:49:24 -0400 Received: from IMCMBX4.MITRE.ORG ([129.83.29.207]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 7 Jul 2009 12:49:24 -0400 From: "Purvis, Ray" To: "'Wes Hardaker'" , Donati Andrew-MGIA0477 Date: Tue, 7 Jul 2009 12:49:23 -0400 Thread-Topic: [Isms] (D)TLS question (#1): selecting a client certificate to use Thread-Index: Acn8ALqP2302NjfrT4W/6fakB7IsOQDIA/NQ Message-ID: <547D5A0BAE35D24E92102CBF0A8D62320B3E25548B@IMCMBX4.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "isms@ietf.org" Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to use 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, 07 Jul 2009 16:49:29 -0000 Hi Wes, I saw the opinions welcome clause at the end and decided to jump in. :) It seems to me that an entry can exist in the snmpTargetParamsTable that do= esn't have a corresponding tlstmParamsEntry, but not vice verse. So, basic= ally, option 2 below is the best choice. Additionally, a deletion of the s= nmpTargetParamsTable entry should cause a deletion of the 1..N entries in t= lstmParamsEntry that these rows are tied to. This brings up my next question. I haven't seen the new table structure si= nce you decided not to augment the params table. I would assume that with = your current thoughts on the tlstmTargetParamsTable, you would include a co= lumn that references the snmpTargetParamsName? This in turn would change y= our rowStatus verbiage to not allow the row to become active until the cert= ificate info is in place and the snmpTargetParamsName exists and is filled = in. My 2 cents. Thanks. Ray -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Wes= Hardaker Sent: Friday, July 03, 2009 12:07 PM To: Donati Andrew-MGIA0477 Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to= use >>>>> On Thu, 2 Jul 2009 15:12:50 -0400, "Donati Andrew-MGIA0477" said: DA> If the corresponding row in the tlstmParamsTable is deleted and the DA> row is automatically removed, I am assuming that setting DA> tlstmParamsRowStatus to createAndGo(4) or createAndWait(5) returns DA> an error if the corresponding row in the tlstmParamsTable is not DA> present. Good point. The options are: 1) let the row be created in anticipation of another being created later in the snmpTargetPararms table. 2) prohibit it with inconsistentValue, which I agree is the right choice. When deleting, I think it makes sense to auto-remove the column from the tlstmParamsTable table since it's unlikely you'd want it there in the future. But, I don't necessarily think that's true for creation and I don't see us getting a huge amount of benefit from disallowing the creation of a row in the tlstmParamsTable table when the row in the snmpTargetParams doesn't exist. But you're right, that doesn't feel consistent either. Opinions welcome :-) -- Wes Hardaker Cobham Analytic Solutions _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From wjhns1@hardakers.net Tue Jul 7 10:09:13 2009 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 21D4328C4C2 for ; Tue, 7 Jul 2009 10:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 rSPhYzjxZCc9 for ; Tue, 7 Jul 2009 10:09:12 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 977B328C4EB for ; Tue, 7 Jul 2009 10:08:55 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 731C5980FA; Tue, 7 Jul 2009 10:09:20 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 150C339A0EE; Tue, 7 Jul 2009 10:04:04 -0700 (PDT) From: Wes Hardaker To: "Purvis\, Ray" Organization: Sparta References: <547D5A0BAE35D24E92102CBF0A8D62320B3E25548B@IMCMBX4.MITRE.ORG> Date: Tue, 07 Jul 2009 10:04:04 -0700 In-Reply-To: <547D5A0BAE35D24E92102CBF0A8D62320B3E25548B@IMCMBX4.MITRE.ORG> (Ray Purvis's message of "Tue, 7 Jul 2009 12:49:23 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to use 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, 07 Jul 2009 17:09:13 -0000 >>>>> On Tue, 7 Jul 2009 12:49:23 -0400, "Purvis, Ray" said: RP> I saw the opinions welcome clause at the end and decided to jump in. RP> :) Always! And thanks for the opinion. RP> Additionally, a deletion of the snmpTargetParamsTable entry should RP> cause a deletion of the 1..N entries in tlstmParamsEntry that these RP> rows are tied to. FYI, there is only a 1:0..1 mapping. RP> This brings up my next question. I haven't seen the new table RP> structure since you decided not to augment the params table. I would RP> assume that with your current thoughts on the tlstmTargetParamsTable, RP> you would include a column that references the snmpTargetParamsName? In MIBs there are multiple ways of referencing rows in another table, or in this case, "adding additional information" to rows in another table. The AUGMENT clause is designed for the 1:1 case where rows exist simultaneously and always in both tables. In this case, we actually have a 1:0..1 case and the best way to achieve that is by using identical indexes in the second (tlstmTargetParamsTable) table. So the indexing now looks like this on my local disk: tlstmParamsEntry OBJECT-TYPE SYNTAX TlstmParamsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row containing a locally held certificate's hash type and hash value for a given snmpTargetParamsEntry. The values in this row should be ignored if the connection that needs to be established, as indicated by the SNMP-TARGET-MIB infrastructure, is not a (D)TLS based connection." INDEX { IMPLIED snmpTargetParamsName } ::= { tlstmParamsTable 1 } The INDEX clause now matches (exactly) the clause from the snmpTargetParamsTable. RP> This in turn would change your rowStatus verbiage to not allow the RP> row to become active until the certificate info is in place and the RP> snmpTargetParamsName exists and is filled in. I haven't written up that potential clause yet since it's not entirely clear where consensus lies yet. I'll post new text when/if I do though and your review of it would be welcome. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Jul 7 10:29:30 2009 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 BE9153A6ABE for ; Tue, 7 Jul 2009 10:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 5O+cDZlBrjiQ for ; Tue, 7 Jul 2009 10:29:29 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id ADB343A6A0E for ; Tue, 7 Jul 2009 10:29:29 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 4B367980F5 for ; Tue, 7 Jul 2009 10:29:44 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 21D5939A0EE for ; Tue, 7 Jul 2009 10:29:43 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Tue, 07 Jul 2009 10:29:43 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] (D)TLS question #2: expecting a server side certificate 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, 07 Jul 2009 17:29:30 -0000 As just discussed, when a client (typically using the SNMP-TARGET-MIB) is opening an outgoing connection it needs to select a client-side certificate to use when making the connection. But, it also has to have an expectation of which remote machine it's connecting to as well. It shouldn't just connect to any old system that answers it's call. It needs to know that the remote system is, in fact, the responder it was hoping to reach. This can be done a number of ways: 1) Add additional rows to the snmpTargetAddrTable that specifies a hash-type/hash-value column pair to refer to a locally held copy of the remote certificate that should be presented. IE, this requires an additional row in an additional table per target. 2) Use one of the more standardized mapping techniques for assuring target certificates are ok based on a trust-anchor CA certificate and accepted mappings of either the CommonName field (which is commonly what web-browsers use, for example) or the subjectAltName field, which is what is currently being recommended within the IETF and the CN field is actually being deprecated. See the following draft for the current thoughts and details on TLS server side identity checks: draft-saintandre-tls-server-id-check-00.txt We'd then need to specify the allowable bindings. In particular, we already have the remote entity specified by the snmpTargetAddrTAddress variable which pretty much dictates the type of lookup that needs to happen in the subjectAltName list. The nice advantage of this approach is that it's the one used in industry today for other TLS connection types and requires no configuration (assuming we're going to stay out of CA-trust-anchor configuration because it's out of scope of the charter). 3) A combination of #1 and #2 allowing for both 1:1 X.509 hash references to an expected certificate and allowing for 1:1 mapping for those folks that don't have control over the certificate generation process or have such small installations that they don't want to set up anything other than self-signed certificates. Personally, I'm leaning toward just #2. Note that the current draft doesn't discuss this much and only hints at it. I intend to write up text for #2 unless the WG participants feel I'm taking the wrong direction in this approach. -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Tue Jul 7 12:00:28 2009 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 639E428C51C for ; Tue, 7 Jul 2009 12:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-I6LdpwQ1uW for ; Tue, 7 Jul 2009 12:00:27 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id E2B9528C54B for ; Tue, 7 Jul 2009 12:00:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=p9SIWXg40bDkk98UfaKdMDFriaFzoJ8AKurS3R8DbgEz119vS7fBEz9LhHaNNM8B; 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.146.233] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MOFtl-00066V-VG for isms@ietf.org; Tue, 07 Jul 2009 15:00:14 -0400 Message-ID: <000401c9ff35$52d35160$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Tue, 7 Jul 2009 12:01:22 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968321fb3b3092eda73a2ef617bd0a536e0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.146.233 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 07 Jul 2009 19:00:28 -0000 Hi - > From: "Wes Hardaker" > To: > Sent: Tuesday, July 07, 2009 10:29 AM > Subject: [Isms] (D)TLS question #2: expecting a server side certificate > > > As just discussed, when a client (typically using the SNMP-TARGET-MIB) > is opening an outgoing connection it needs to select a client-side > certificate to use when making the connection. > > But, it also has to have an expectation of which remote machine it's > connecting to as well. It shouldn't just connect to any old system that > answers it's call. It needs to know that the remote system is, in fact, > the responder it was hoping to reach. > > This can be done a number of ways: > > 1) Add additional rows to the snmpTargetAddrTable that specifies a > hash-type/hash-value column pair to refer to a locally held copy of > the remote certificate that should be presented. IE, this requires an > additional row in an additional table per target. > > 2) Use one of the more standardized mapping techniques for assuring > target certificates are ok based on a trust-anchor CA certificate and > accepted mappings of either the CommonName field (which is commonly > what web-browsers use, for example) or the subjectAltName field, > which is what is currently being recommended within the IETF and the > CN field is actually being deprecated. See the following draft for > the current thoughts and details on TLS server side identity checks: > > draft-saintandre-tls-server-id-check-00.txt > > We'd then need to specify the allowable bindings. In particular, > we already have the remote entity specified by the > snmpTargetAddrTAddress variable which pretty much dictates the type > of lookup that needs to happen in the subjectAltName list. > > The nice advantage of this approach is that it's the one used in > industry today for other TLS connection types and requires no > configuration (assuming we're going to stay out of CA-trust-anchor > configuration because it's out of scope of the charter). > > 3) A combination of #1 and #2 allowing for both 1:1 X.509 hash > references to an expected certificate and allowing for 1:1 mapping > for those folks that don't have control over the certificate > generation process or have such small installations that they don't > want to set up anything other than self-signed certificates. > > > Personally, I'm leaning toward just #2. > > Note that the current draft doesn't discuss this much and only hints at > it. I intend to write up text for #2 unless the WG participants feel > I'm taking the wrong direction in this approach. ... I think there is at least one other possibility. (4) Use additional column(s) in tlstmParamsTable to hold the information. Though at first glance this might seem problematic, I believe the weirdness is no worse than with USM. Randy From root@core3.amsl.com Tue Jul 7 14:00:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E7AC03A696D; Tue, 7 Jul 2009 14:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090707210001.E7AC03A696D@core3.amsl.com> Date: Tue, 7 Jul 2009 14:00:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] WG Action: RECHARTER: Integrated Security Model for SNMP (isms) 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, 07 Jul 2009 21:00:02 -0000 The Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Integrated Security Model for SNMP (isms) ========================================= Last Modified: 2009-06-18 Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working- groups/isms/current/maillist.html Description of Working Group: 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 definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing named access control policies, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. 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: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transport models for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the (D)TLS transports for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2010 Submit documentation on the (D)TLS transports for SNMP to IESG Jan 2010 Submit documentation for the centralized access control to IESG From wjhns1@hardakers.net Tue Jul 7 15:25:28 2009 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 CAE463A6EC3 for ; Tue, 7 Jul 2009 15:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 UyLErcCbrT4Q for ; Tue, 7 Jul 2009 15:25:27 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 861ED3A6E32 for ; Tue, 7 Jul 2009 15:25:27 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id E1677980D4; Tue, 7 Jul 2009 15:25:41 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 3EE4F39A0EE; Tue, 7 Jul 2009 15:25:40 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> Date: Tue, 07 Jul 2009 15:25:40 -0700 In-Reply-To: <000401c9ff35$52d35160$6801a8c0@oemcomputer> (Randy Presuhn's message of "Tue, 7 Jul 2009 12:01:22 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 07 Jul 2009 22:25:28 -0000 >>>>> On Tue, 7 Jul 2009 12:01:22 -0700, "Randy Presuhn" said: RP> (4) Use additional column(s) in tlstmParamsTable to hold the information. RP> Though at first glance this might seem problematic, I believe the weirdness RP> is no worse than with USM. You know, I half typed that one out and then erased it. In fact, that's even what I have written up in my unpublished copy of the draft. But in hind-site I think it's architecturally wrong with respect to the TARGET-MIB. In particular, the target MIB is split in half right now: the snmpTargetAddrTable is composed of remote destination type parameters: addresses, ports, timeouts, retries, etc. IE, things that may be specific to the remote server. The snmpTargetParamsTable, which is referenced by the snmpTargetAddrTable table and by extension the tlstmParamsTable, is designed for storing client-side connection information (security model, security name, etc). Right now, you have to have one row in the snmpTargetAddrTable for each row remote target. But you only need one row in the snmpTargetParamsTable and the tlstmParamsTable if you only have one set of client-side credentials to use. Putting the server side certificate information into the tlstmParamsTable would change this such that a new row would be required in the tlstmParamsTable for each remote target, which I think is not a good model. And I think it breaks how the original target mib storage model was designed. Hence the reason I didn't include it. But you're right that if we want to be complete it is an option. -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Tue Jul 7 15:52:08 2009 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 389103A6817 for ; Tue, 7 Jul 2009 15:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[AWL=1.211, 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 0hODe4Y3Q6yh for ; Tue, 7 Jul 2009 15:52:07 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 6E7F03A67FC for ; Tue, 7 Jul 2009 15:52:07 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n67Mq1nU020685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 18:52:02 -0400 (EDT) Date: Tue, 07 Jul 2009 18:52:01 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , Randy Presuhn Message-ID: In-Reply-To: <9795_1247005559_n67MPvFY022238_sdy6r0b063.fsf@wes.hardakers.net> References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> <9795_1247005559_n67MPvFY022238_sdy6r0b063.fsf@wes.hardakers.net> 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.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 07 Jul 2009 22:52:08 -0000 --On Tuesday, July 07, 2009 03:25:40 PM -0700 Wes Hardaker wrote: > Putting the server side certificate information into the > tlstmParamsTable would change this such that a new row would be required > in the tlstmParamsTable for each remote target, which I think is not a > good model. And I think it breaks how the original target mib storage > model was designed. Hence the reason I didn't include it. But you're > right that if we want to be complete it is an option. I am inclined to suggest that server certificate validation be done in the usual fashion, by comparing the CN and/or dnsName in the certificate the server presents to the configured server name, and that the issues of certificate validation, trust anchor selection, and handling of exceptional cases are all best handled by the implementation and/or its certificate store and really should be out of scope for the present specification. If someone wants to write a MIB to maange certificate stores, great. But that work is not within the current or proposed scope of ISMS. -- Jeff From wjhns1@hardakers.net Tue Jul 7 16:35:07 2009 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 0FC5B3A6872 for ; Tue, 7 Jul 2009 16:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 xrjdCIb8UEr2 for ; Tue, 7 Jul 2009 16:35:06 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 18B6B3A6767 for ; Tue, 7 Jul 2009 16:35:06 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 19CDF98123; Tue, 7 Jul 2009 16:35:31 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 3EBE039A0EE; Tue, 7 Jul 2009 16:35:29 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> <9795_1247005559_n67MPvFY022238_sdy6r0b063.fsf@wes.hardakers.net> Date: Tue, 07 Jul 2009 16:35:29 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Tue, 07 Jul 2009 18:52:01 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 07 Jul 2009 23:35:07 -0000 >>>>> On Tue, 07 Jul 2009 18:52:01 -0400, Jeffrey Hutzelman said: JH> I am inclined to suggest that server certificate validation be done in JH> the usual fashion, by comparing the CN and/or dnsName in the JH> certificate the server presents to the configured server name, and JH> that the issues of certificate validation, trust anchor selection, and JH> handling of exceptional cases are all best handled by the JH> implementation and/or its certificate store and really should be out JH> of scope for the present specification. Just to be sure you agree: that's functionally option #2 and the one I suggested. I'd add a bit of detail stating that's how it's expected, though you're right that adding "implementation dependent" is probably ok. I think I'd lean toward a standard implementation expectation though. JH> If someone wants to write a MIB to maange certificate stores, great. JH> But that work is not within the current or proposed scope of ISMS. Right. I agree. -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Tue Jul 7 16:48:01 2009 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 90A1F3A6A40 for ; Tue, 7 Jul 2009 16:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.463 X-Spam-Level: X-Spam-Status: No, score=-5.463 tagged_above=-999 required=5 tests=[AWL=1.136, 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 iVIwj-I-+k1W for ; Tue, 7 Jul 2009 16:48:00 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id A7AE83A672F for ; Tue, 7 Jul 2009 16:48:00 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n67NlVjX020785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 19:47:32 -0400 (EDT) Date: Tue, 07 Jul 2009 19:47:31 -0400 From: Jeffrey Hutzelman To: Wes Hardaker Message-ID: In-Reply-To: <6671_1247009736_n67NZZwd030532_sdtz1o9ida.fsf@wes.hardakers.net> References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> <9795_1247005559_n67MPvFY022238_sdy6r0b063.fsf@wes.hardakers.net> <6671_1247009736_n67NZZwd030532_sdtz1o9ida.fsf@wes.hardakers.net> 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.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 07 Jul 2009 23:48:01 -0000 --On Tuesday, July 07, 2009 04:35:29 PM -0700 Wes Hardaker wrote: >>>>>> On Tue, 07 Jul 2009 18:52:01 -0400, Jeffrey Hutzelman >>>>>> said: > > JH> I am inclined to suggest that server certificate validation be done in > JH> the usual fashion, by comparing the CN and/or dnsName in the > JH> certificate the server presents to the configured server name, and > JH> that the issues of certificate validation, trust anchor selection, and > JH> handling of exceptional cases are all best handled by the > JH> implementation and/or its certificate store and really should be out > JH> of scope for the present specification. > > Just to be sure you agree: that's functionally option #2 Yes, with the proviso that the implementation might provide features like the ability to map a server name to a specific certificate, whether or not that certificate would pass the normal validation process. The tricky bit here is that in reality, such exceptions are far more commonplace than we'd like, and while the usual model for web browsers is to handle them interactively, that won't fly for SNMP NO's. I wonder if PKIX could be convinced to take up the work of specifying a certificate store MIB. From wjhns1@hardakers.net Tue Jul 7 17:14:47 2009 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 95CA13A69AD for ; Tue, 7 Jul 2009 17:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 93kJ484QDwLg for ; Tue, 7 Jul 2009 17:14:46 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 93E513A68AC for ; Tue, 7 Jul 2009 17:14:46 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 19CDF9813E; Tue, 7 Jul 2009 17:15:11 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2CA2A39A0EE; Tue, 7 Jul 2009 17:15:09 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> <9795_1247005559_n67MPvFY022238_sdy6r0b063.fsf@wes.hardakers.net> <6671_1247009736_n67NZZwd030532_sdtz1o9ida.fsf@wes.hardakers.net> Date: Tue, 07 Jul 2009 17:15:09 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Tue, 07 Jul 2009 19:47:31 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 08 Jul 2009 00:14:47 -0000 >>>>> On Tue, 07 Jul 2009 19:47:31 -0400, Jeffrey Hutzelman said: JH> Yes, with the proviso that the implementation might provide features JH> like the ability to map a server name to a specific certificate, JH> whether or not that certificate would pass the normal validation JH> process. Ah, which is like an implementation dependent version of the features #3. I'm good with that. JH> The tricky bit here is that in reality, such exceptions are far more JH> commonplace than we'd like, and while the usual model for web browsers JH> is to handle them interactively, that won't fly for SNMP NO's. Agreed, which is why I even suggested #3 which in spec implementation would look like: A) A new table extension to the snmpTargetAddrTable that did hash reference specifying of a cert. The certificates matching the hashes would be stored out of ISMS WG specifications in an implementation or future-defined method. B) If no match is found in the above table, then the CommonName or subjectAltName style match would be checked. (order actually doesn't matter; either check regardless of ordering would still be a success) Opinions sought if this would be better than just option #2, which was functionally just B without the A component. -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Tue Jul 7 17:42:18 2009 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 A23F73A68A0 for ; Tue, 7 Jul 2009 17:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 PXejkTP+uVxy for ; Tue, 7 Jul 2009 17:42:17 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id AF1793A672F for ; Tue, 7 Jul 2009 17:42:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=L866hoqz7KuCc+alLsZ7ihI4EMoa9hNHxcj0sCHHI5d2vYEQAsuhw92q8aVYbLt8; 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 [76.254.54.56] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MOLEV-0005Fw-12 for isms@ietf.org; Tue, 07 Jul 2009 20:41:59 -0400 Message-ID: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> Date: Tue, 7 Jul 2009 17:43:08 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968c49a9c30783cf6d3306be913b5fd11af350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.56 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 08 Jul 2009 00:42:18 -0000 Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, July 07, 2009 3:25 PM > Subject: Re: (D)TLS question #2: expecting a server side certificate > > >>>>> On Tue, 7 Jul 2009 12:01:22 -0700, "Randy Presuhn" said: > > RP> (4) Use additional column(s) in tlstmParamsTable to hold the information. > RP> Though at first glance this might seem problematic, I believe the weirdness > RP> is no worse than with USM. > > You know, I half typed that one out and then erased it. In fact, that's > even what I have written up in my unpublished copy of the draft. > > But in hind-site I think it's architecturally wrong with respect to the > TARGET-MIB. In particular, the target MIB is split in half right now: > the snmpTargetAddrTable is composed of remote destination type > parameters: addresses, ports, timeouts, retries, etc. IE, things that > may be specific to the remote server. > > The snmpTargetParamsTable, which is referenced by the > snmpTargetAddrTable table and by extension the tlstmParamsTable, is > designed for storing client-side connection information (security model, > security name, etc). > > Right now, you have to have one row in the snmpTargetAddrTable for each > row remote target. But you only need one row in the > snmpTargetParamsTable and the tlstmParamsTable if you only have one set > of client-side credentials to use. > > Putting the server side certificate information into the > tlstmParamsTable would change this such that a new row would be required > in the tlstmParamsTable for each remote target, which I think is not a > good model. And I think it breaks how the original target mib storage > model was designed. Hence the reason I didn't include it. But you're > right that if we want to be complete it is an option. I'm not wild about it as a model. However, the target mib *already* has this property. Think about the USM symmetric keys needed in a notification originator. To prevent one compromised notification receiver from impersonating another, it's necessary to give each one its own set of securityNames for the notification receiver role. To get around this, you could use another table INDEXed by snmpTargetAddrName (*NOT* snmpTargetParamsName) to hold the information. Randy and From wjhns1@hardakers.net Wed Jul 8 07:38:34 2009 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 98FAF3A6A78 for ; Wed, 8 Jul 2009 07:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 D-k66e0pd8NX for ; Wed, 8 Jul 2009 07:38:33 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 5C1F43A67BD for ; Wed, 8 Jul 2009 07:38:33 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 42E2B981AE; Wed, 8 Jul 2009 07:38:58 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 8DAB039A0EE; Wed, 8 Jul 2009 07:38:56 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> <003601c9ff65$110e4f20$6801a8c0@oemcomputer> Date: Wed, 08 Jul 2009 07:38:56 -0700 In-Reply-To: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> (Randy Presuhn's message of "Tue, 7 Jul 2009 17:43:08 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 08 Jul 2009 14:38:34 -0000 >>>>> On Tue, 7 Jul 2009 17:43:08 -0700, "Randy Presuhn" said: RP> I'm not wild about it as a model. However, the target mib *already* has RP> this property. Think about the USM symmetric keys needed in a RP> notification originator. To prevent one compromised notification RP> receiver from impersonating another, it's necessary to give each one RP> its own set of securityNames for the notification receiver role. Yes, but doing that for server addresses would do it for every type of connection. Right now you need different secNames only when using INFORMs. Adding server parameters to the snmpTargetParamsTable (via an extension table) would require it for all types of messages. That would affect TRAPs and command messages generated via the disman-event-mib, eg. RP> To get around this, you could use another table INDEXed by RP> snmpTargetAddrName (*NOT* snmpTargetParamsName) RP> to hold the information. Um, yeah. That's what I said in the original message! -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Wed Jul 8 11:15:55 2009 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 A0EE43A6B8D for ; Wed, 8 Jul 2009 11:15:55 -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 WwKIIgr2gOD0 for ; Wed, 8 Jul 2009 11:15:54 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id C5BEC3A6A41 for ; Wed, 8 Jul 2009 11:15:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VOJSQAtprqRF47M9CT+ndUiebO6vUKu5gD1QSvHGMARgfGuKz0EBYSQbbeZrzpOm; 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.35.224.143] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MObd7-0005aZ-IL for isms@ietf.org; Wed, 08 Jul 2009 14:12:29 -0400 Message-ID: <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401c9ff35$52d35160$6801a8c0@oemcomputer><003601c9ff65$110e4f20$6801a8c0@oemcomputer> Date: Wed, 8 Jul 2009 11:13:42 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69681a61c86b46513c2f0d734f7d9e2485e8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.224.143 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 08 Jul 2009 18:15:55 -0000 Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, July 08, 2009 7:38 AM > Subject: Re: (D)TLS question #2: expecting a server side certificate > > >>>>> On Tue, 7 Jul 2009 17:43:08 -0700, "Randy Presuhn" said: > > RP> I'm not wild about it as a model. However, the target mib *already* has > RP> this property. Think about the USM symmetric keys needed in a > RP> notification originator. To prevent one compromised notification > RP> receiver from impersonating another, it's necessary to give each one > RP> its own set of securityNames for the notification receiver role. > > Yes, but doing that for server addresses would do it for every type of > connection. Right now you need different secNames only when using > INFORMs. Adding server parameters to the snmpTargetParamsTable (via an > extension table) would require it for all types of messages. That would > affect TRAPs and command messages generated via the disman-event-mib, eg. This same issue exists with USM. > RP> To get around this, you could use another table INDEXed by > RP> snmpTargetAddrName (*NOT* snmpTargetParamsName) > RP> to hold the information. > > Um, yeah. That's what I said in the original message! :-) It would be interesting to think through how the event or expression MIBs would work with this. Maybe we should invoke Bob Stewart. Randy From wjhns1@hardakers.net Wed Jul 8 11:21:45 2009 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 11E693A6BD0 for ; Wed, 8 Jul 2009 11:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 LGrwg+edGTz8 for ; Wed, 8 Jul 2009 11:21:44 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 168523A6B3C for ; Wed, 8 Jul 2009 11:21:44 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 91B55980F5; Wed, 8 Jul 2009 11:22:07 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2BF6D39A0F2; Wed, 8 Jul 2009 11:22:06 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> Date: Wed, 08 Jul 2009 11:22:06 -0700 In-Reply-To: <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> (Randy Presuhn's message of "Wed, 8 Jul 2009 11:13:42 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 08 Jul 2009 18:21:45 -0000 >>>>> On Wed, 8 Jul 2009 11:13:42 -0700, "Randy Presuhn" said: >> Yes, but doing that for server addresses would do it for every type of >> connection. Right now you need different secNames only when using >> INFORMs. Adding server parameters to the snmpTargetParamsTable (via an >> extension table) would require it for all types of messages. That would >> affect TRAPs and command messages generated via the disman-event-mib, eg. RP> This same issue exists with USM. No, for USM you can have an identical security name as a single row (1) in the params table for the remote agents and many different rows (N) in the USM table. With the hash of the remote certificate in the params table you'd need N rows in the parms table and N rows in the params extension table. That's worse. RP> :-) It would be interesting to think through how the event or RP> expression MIBs would work with this. Maybe we should invoke Bob RP> Stewart. I actually have thought about it actually, but the details of my thoughts haven't been transcribed to 1s and 0s. -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Wed Jul 8 11:53:04 2009 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 CE5213A6C10 for ; Wed, 8 Jul 2009 11:53:04 -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=[AWL=0.000, 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 J+dxbqqN-qcU for ; Wed, 8 Jul 2009 11:53:04 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 1184B3A6774 for ; Wed, 8 Jul 2009 11:53:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZZIlxXmB1VOKZWiBRES5bxTa7jQIGZbBhLdGeHtosmksq2e4L68N59zl6KeeXIle; 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.35.224.143] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MOcGm-0006gA-0Q for isms@ietf.org; Wed, 08 Jul 2009 14:53:28 -0400 Message-ID: <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401c9ff35$52d35160$6801a8c0@oemcomputer><003601c9ff65$110e4f20$6801a8c0@oemcomputer><002b01c9fff7$d4226a40$6801a8c0@oemcomputer> Date: Wed, 8 Jul 2009 11:54:41 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69689d46cd7c7f26ac30f1bede9f73b8d46e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.224.143 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 08 Jul 2009 18:53:04 -0000 Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, July 08, 2009 11:22 AM > Subject: Re: (D)TLS question #2: expecting a server side certificate ... > RP> This same issue exists with USM. > > No, for USM you can have an identical security name as a single row (1) > in the params table for the remote agents and many different rows (N) in > the USM table. With the hash of the remote certificate in the params > table you'd need N rows in the parms table and N rows in the params > extension table. That's worse. But it's the snmpTargetAddrTable that determines where that securityName gets sent, and the usmUserTable (indexed by BOTH usmUserEngineID and usmUserName) for the key. The idea behind the snmpTargetParamsTable was to avoid duplicating a lot of information in snmpTargetAddrTable, and only hold the bits that would likely be identical for multiple entries in the snmpTargetAddrTable. It sounds like the requirements for the remote certificates are more like those of some of the bits in the usmUserTable. Its entries do not exist 1:1 with either the snmpTargetAddrTable or the snmpTargetParamsTable. The problem, though, is whether you'd have access to an engineID in addition to the securityName for indexing. Randy From wjhns1@hardakers.net Wed Jul 8 13:51:13 2009 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 795553A6B98 for ; Wed, 8 Jul 2009 13:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 eu2crg8HfxFQ for ; Wed, 8 Jul 2009 13:51:12 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 83BCD3A6B99 for ; Wed, 8 Jul 2009 13:51:12 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id AFE5598177; Wed, 8 Jul 2009 13:51:38 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id E438439A0F2; Wed, 8 Jul 2009 13:51:36 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> Date: Wed, 08 Jul 2009 13:51:36 -0700 In-Reply-To: <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> (Randy Presuhn's message of "Wed, 8 Jul 2009 11:54:41 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 08 Jul 2009 20:51:13 -0000 >>>>> On Wed, 8 Jul 2009 11:54:41 -0700, "Randy Presuhn" said: RP> The idea behind the snmpTargetParamsTable was to avoid duplicating RP> a lot of information in snmpTargetAddrTable, and only hold the bits that RP> would likely be identical for multiple entries in the snmpTargetAddrTable. Why does it sound like we're agreeing not disagreeing? RP> It sounds like the requirements for the remote certificates are more RP> like those of some of the bits in the usmUserTable. Its entries do RP> not exist 1:1 with either the snmpTargetAddrTable or the RP> snmpTargetParamsTable. They're *possibly* 1:1 for the snmpTargetAddrTable for every row that is a (D)TLS domain and address. [the exception being is if we allow for the CommonName or subjectAltName mapping, then you don't need a TLS specific row] RP> The problem, though, is whether you'd have access to an engineID in RP> addition to the securityName for indexing. There is no need for an security engineID in (D)TLS land. Or ISMS land for that matter. The important question that needs answering though is: Should we even provide MIB instrumentation for 1:1 address->server-X.509 support or not. If the answer is "no we should not" then the whole discussion is moot anyway. -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Wed Jul 8 14:43:17 2009 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 D3EF528C453 for ; Wed, 8 Jul 2009 14:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 cozu5IWclt+T for ; Wed, 8 Jul 2009 14:43:17 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id EBD9128C105 for ; Wed, 8 Jul 2009 14:43:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Bw9iyFzx3OUrF00fJgrPVmkkfTMaxuPfal/w7fJah1f+67u6NFSnHuFfnbUidS21; h=Received:Message-ID:From:Cc: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.35.224.143] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MOevX-0003rr-V4 for isms@ietf.org; Wed, 08 Jul 2009 17:43:44 -0400 Message-ID: <000401ca0015$55df6f20$6801a8c0@oemcomputer> From: "Randy Presuhn" Cc: References: <000401c9ff35$52d35160$6801a8c0@oemcomputer><003601c9ff65$110e4f20$6801a8c0@oemcomputer><002b01c9fff7$d4226a40$6801a8c0@oemcomputer><005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> Date: Wed, 8 Jul 2009 14:44:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69685a521a9039f41bc2ef3b247dfe8928b2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.224.143 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 08 Jul 2009 21:43:17 -0000 Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, July 08, 2009 1:51 PM > Subject: Re: (D)TLS question #2: expecting a server side certificate ... > Why does it sound like we're agreeing not disagreeing? Probably because you're convincing me as you walk me through your reasoning. :-) > RP> It sounds like the requirements for the remote certificates are more > RP> like those of some of the bits in the usmUserTable. Its entries do > RP> not exist 1:1 with either the snmpTargetAddrTable or the > RP> snmpTargetParamsTable. > > They're *possibly* 1:1 for the snmpTargetAddrTable for every row that > is a (D)TLS domain and address. I think we're in violent agreement here - that this stuff would be more closely associated with the snmpTargetAddrTable than with the snmpTargetParamsTable. (FWIW, this is a great example of how the factoring of the target MIB was affected by the USM design, even though the intent was to keep them decoupled.) > [the exception being is if we allow for the CommonName or subjectAltName > mapping, then you don't need a TLS specific row] ... > The important question that needs answering though is: > > Should we even provide MIB instrumentation for 1:1 address->server-X.509 > support or not. > > If the answer is "no we should not" then the whole discussion is moot anyway. The only good reason I can see for doing it is if there were an operational requirement to deliver or remove them using SNMP. Would doing so make initial setup, provisioning, or deployment easier? I think the spirit of ISMS would be to say "no", but I think the operational case of the node which is primarily a notification generator would need to be worked through. Randy From wjhns1@hardakers.net Thu Jul 9 10:40:22 2009 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 D556E28C22F for ; Thu, 9 Jul 2009 10:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 rwAR-U9oyvUX for ; Thu, 9 Jul 2009 10:40:22 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id BA46328C1F4 for ; Thu, 9 Jul 2009 10:40:10 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id D5A5B98118; Thu, 9 Jul 2009 10:40:37 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id BA78F39A0EE; Thu, 9 Jul 2009 10:40:37 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <000401c9ff35$52d35160$6801a8c0@oemcomputer> <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> Date: Thu, 09 Jul 2009 10:40:37 -0700 In-Reply-To: <000401ca0015$55df6f20$6801a8c0@oemcomputer> (Randy Presuhn's message of "Wed, 8 Jul 2009 14:44:55 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 09 Jul 2009 17:40:22 -0000 >>>>> On Wed, 8 Jul 2009 14:44:55 -0700, "Randy Presuhn" said: RP> I think we're in violent agreement here - that this stuff would be more RP> closely associated with the snmpTargetAddrTable than with the RP> snmpTargetParamsTable. I'm glad we're in agreement then! >> The important question that needs answering though is: >> >> Should we even provide MIB instrumentation for 1:1 >> address->server-X.509 support or not. >> >> If the answer is "no we should not" then the whole discussion is moot >> anyway. RP> The only good reason I can see for doing it is if there were an RP> operational requirement to deliver or remove them using SNMP. Would RP> doing so make initial setup, provisioning, or deployment easier? I RP> think the spirit of ISMS would be to say "no", but I think the RP> operational case of the node which is primarily a notification RP> generator would need to be worked through. Operationally, the certificate still needs to be uploaded as well, which I think is generally considered to be out of scope. So even if we do provide a MIB it's not necessarily a complete solution (but we'd be providing "our half" of the responsibility and would still allow a certificate store to be present and referenced, which would be better than nothing). So it's unclear from the above if you have an opinion. It sounds like you're on the fence? -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Thu Jul 9 11:04:48 2009 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 0A5B928C24F for ; Thu, 9 Jul 2009 11:04:48 -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=[AWL=0.000, 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 GbTJX8CmifCO for ; Thu, 9 Jul 2009 11:04:47 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 3C07328C27E for ; Thu, 9 Jul 2009 11:04:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Gf6CmaDUmQKWbTygT1EiWwIHk7iP9pOAnj7dS6IXeU9fD62D57ahTnJId7y+eghE; 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.187.238.146] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MOxzc-0001K6-PN for isms@ietf.org; Thu, 09 Jul 2009 14:05:13 -0400 Message-ID: <003c01ca00bf$faf08260$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401c9ff35$52d35160$6801a8c0@oemcomputer><003601c9ff65$110e4f20$6801a8c0@oemcomputer><002b01c9fff7$d4226a40$6801a8c0@oemcomputer><005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer><000401ca0015$55df6f20$6801a8c0@oemcomputer> Date: Thu, 9 Jul 2009 11:06:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968e36b35a2b8425c80cf237d2e9d14885d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.238.146 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 09 Jul 2009 18:04:48 -0000 Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Thursday, July 09, 2009 10:40 AM > Subject: Re: (D)TLS question #2: expecting a server side certificate ... > Operationally, the certificate still needs to be uploaded as well, which > I think is generally considered to be out of scope. So even if we do > provide a MIB it's not necessarily a complete solution (but we'd be > providing "our half" of the responsibility and would still allow a > certificate store to be present and referenced, which would be better > than nothing). > > So it's unclear from the above if you have an opinion. It sounds like > you're on the fence? I think a "half solution" would miss the whole point of why the isms work was chartered in the first place. >From my perspective, the issue isn't whether SNMP is used to deliver the information, but rather that the isms documents address the whole problem. If there is a standardized way to deliver the certificates, we should reference it. If there isn't, then we need to provide a mechanism to support delivering the certificates for the (D)TLS transport of SNMP. (I agree that solving the certificate delivery problem in full generality would be out of scope.) Otherwise, we're leaving implementors and those trying to deploy this with an "and then a miracle occurs" solution. If folks really believe the charter prevents the WG from addressing the problem, then the draft should go right out and say "there's this big ol' hole where certificate delivery should be, and you'll have to invent something to put there to get this to work." Providing a way to deposit the necessary certificates using SNMP seems to be an obvious and straightforward way to plug that hole. It doesn't go as far as I think the spirit of isms should take it (remember, objections to the amount of provisioning necessary to prepare an SNMP engine for use in an operational network triggered this work) but it would be better than nothing. Exposing the information as a MIB could make it possible, for example, to remove certificates deposited by other means. I don't know whether that would be a bug or a feature. Randy From j.schoenwaelder@jacobs-university.de Thu Jul 9 11:27:44 2009 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 7C47628C28F for ; Thu, 9 Jul 2009 11:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKWPoJ2vjZhu for ; Thu, 9 Jul 2009 11:27:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 47F2628C27E for ; Thu, 9 Jul 2009 11:27:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE3AFC0042; Thu, 9 Jul 2009 20:28:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fEEJh0K+ALOq; Thu, 9 Jul 2009 20:28: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 6A4A2C003F; Thu, 9 Jul 2009 20:28:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 681E6B5BE56; Thu, 9 Jul 2009 20:28:07 +0200 (CEST) Date: Thu, 9 Jul 2009 20:28:07 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20090709182807.GA7502@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> <003c01ca00bf$faf08260$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003c01ca00bf$faf08260$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 09 Jul 2009 18:27:44 -0000 On Thu, Jul 09, 2009 at 08:06:27PM +0200, Randy Presuhn wrote: > From my perspective, the issue isn't whether SNMP is used to deliver > the information, but rather that the isms documents address the > whole problem. If there is a standardized way to deliver the > certificates, we should reference it. If there isn't, then we need > to provide a mechanism to support delivering the certificates for > the (D)TLS transport of SNMP. (I agree that solving the certificate > delivery problem in full generality would be out of scope.) > Otherwise, we're leaving implementors and those trying to deploy > this with an "and then a miracle occurs" solution. If folks really > believe the charter prevents the WG from addressing the problem, > then the draft should go right out and say "there's this big ol' > hole where certificate delivery should be, and you'll have to invent > something to put there to get this to work." > > Providing a way to deposit the necessary certificates using SNMP > seems to be an obvious and straightforward way to plug that hole. > It doesn't go as far as I think the spirit of isms should take it (remember, > objections to the amount of provisioning necessary to prepare > an SNMP engine for use in an operational network triggered this > work) but it would be better than nothing. Exposing the information > as a MIB could make it possible, for example, to remove certificates > deposited by other means. I don't know whether that would be a > bug or a feature. Most operators know how to deal with SSH keys or [D]TLS certificates. As far as I recall, the reason why operators did not like USM was that it is yet another key management system they have to deal with. The fact that USM has an SNMP way of managing keys did not make it fly too high either. I agree with Joe that we are better served not to solve certificate management issues - like we decided not to solve SSH key management issues. (Me speaking as a technical contributor.) /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 Jul 9 11:42:34 2009 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 A5A5728C2A2 for ; Thu, 9 Jul 2009 11:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=-0.931, 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 dwlVU6X97u9e for ; Thu, 9 Jul 2009 11:42:34 -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 C4D1B28C15D for ; Thu, 9 Jul 2009 11:42:33 -0700 (PDT) Received: from ATLANTIS.PC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n69IgwUa026755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2009 14:42:59 -0400 (EDT) Date: Thu, 09 Jul 2009 14:42:58 -0400 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , Randy Presuhn Message-ID: <9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu> In-Reply-To: <28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local> References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> <003c01ca00bf$faf08260$6801a8c0@oemcomputer> <28944_1247164095_n69ISEEb012095_20090709182807.GA7502@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: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 09 Jul 2009 18:42:34 -0000 --On Thursday, July 09, 2009 08:28:07 PM +0200 Juergen Schoenwaelder wrote: > Most operators know how to deal with SSH keys or [D]TLS certificates. > As far as I recall, the reason why operators did not like USM was that > it is yet another key management system they have to deal with. The > fact that USM has an SNMP way of managing keys did not make it fly too > high either. I agree with Joe that we are better served not to solve > certificate management issues - like we decided not to solve SSH key > management issues. (Me speaking as a technical contributor.) Note also that the goal of ISMS is not just "make it easier", but "make it work with our existing infrastructure". That means eliminating the n*m keying explosion of USM in favor of using existing enterprise authentication mechanisms for both users and hosts, whether that's RADIUS, Kerberos, PKI, leap-of-faith, or some combination. In any case, _managing_ that infrastructure is not just "not in our charter"; it's actually out of scope -- we don't have enough of the expertise for it. I don't think it's appropriate to develop an ISMS-specific approach to using SNMP to manage certificate stores. Management of certificate stores should be done in a standardized way, not tied to a particular application, and the expertise for doing it right lies in PKIX, not here. -- Jeff From randy_presuhn@mindspring.com Thu Jul 9 14:57:55 2009 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 3040D28C277 for ; Thu, 9 Jul 2009 14:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 iuPxXwFZYNFy for ; Thu, 9 Jul 2009 14:57:54 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 680003A6A9B for ; Thu, 9 Jul 2009 14:57:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hyd7oqCdRRtpGtAgKwFt4zfeNSrL0aUJ3ctFwB2434M2a1QWM9TGSa7xeskQstna; 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 [76.254.48.93] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MP1dG-0002SB-3z for isms@ietf.org; Thu, 09 Jul 2009 17:58:22 -0400 Message-ID: <001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> <003c01ca00bf$faf08260$6801a8c0@oemcomputer> <28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local> <9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu> Date: Thu, 9 Jul 2009 14:59:37 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968a9c036709cf0d9b13e7e44c062cfc35a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.48.93 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 09 Jul 2009 21:57:55 -0000 Hi - > From: "Jeffrey Hutzelman" > To: "Juergen Schoenwaelder" ; "Randy Presuhn" > Cc: ; > Sent: Thursday, July 09, 2009 11:42 AM > Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate ... > I don't think it's appropriate to develop an ISMS-specific approach to > using SNMP to manage certificate stores. Management of certificate stores > should be done in a standardized way, not tied to a particular application, > and the expertise for doing it right lies in PKIX, not here. ... It would be fine with me if we just had a pointer to the appropriate RFC indicating how it should be done. My point is that it should not be left to the reader's imagination. If there is no specification for us to point to, then the work here is not standardization, but rather just wishful thinking. Randy From wjhns1@hardakers.net Thu Jul 9 15:10:12 2009 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 24F7D3A6D34 for ; Thu, 9 Jul 2009 15:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 ak56DhNQZ5N9 for ; Thu, 9 Jul 2009 15:10:09 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 518343A6D35 for ; Thu, 9 Jul 2009 15:09:09 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id DB02D98079; Thu, 9 Jul 2009 15:09:36 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 9770139A0EE; Thu, 9 Jul 2009 15:09:36 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> <003c01ca00bf$faf08260$6801a8c0@oemcomputer> <28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local> <9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu> <001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer> Date: Thu, 09 Jul 2009 15:09:35 -0700 In-Reply-To: <001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer> (Randy Presuhn's message of "Thu, 9 Jul 2009 14:59:37 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 09 Jul 2009 22:10:12 -0000 >>>>> On Thu, 9 Jul 2009 14:59:37 -0700, "Randy Presuhn" said: RP> It would be fine with me if we just had a pointer to the appropriate RP> RFC indicating how it should be done. My point is that it should RP> not be left to the reader's imagination. If there is no RP> specification for us to point to, then the work here is not RP> standardization, but rather just wishful thinking. There are some CA based mapping systems we can point to (as I've noted). It's just a standardized certificate uploading process that isn't. If we're fine with just the CA CommonName/subjectAltName mapping then we have something to point to. It's only if we want to support a hash pointing to a unique X.509 cert that we either have to say the installation of that certificate is out of scope or we don't do it (or we work with a group where it is in scope). I don't think that it's a waste of time if we want to go to the halfway point and use a hash reference but not specify how the certificate itself is uploaded. It's completing some of the work. Netconf has yet to produce a fully working system of specifications but I wouldn't say their effort has been wasted just because they haven't completed their definitions yet. The same goes for this situation: half-way is still better than no-way. [aside: at some point there is *always* a bootstrapping problem that you have to fall down on, be it certificates or ssh keys or ... At some point you have to plug in the box, turn on the device and touch it via a human controlled first-certificate upload process or password setting process that is not standardized because it falls on the native physical interface system to make that happen] [if we were to standardize on an upload system, the easiest one would probably be a URL reference to go fetch it from; bootstrapping of the first certificate to validate the first URL pull would still be up to the initial install though] -- Wes Hardaker Cobham Analytic Solutions From jhutz@cmu.edu Thu Jul 9 19:06:44 2009 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 234533A6C37 for ; Thu, 9 Jul 2009 19:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=-0.879, 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 IaW77UpJCbd7 for ; Thu, 9 Jul 2009 19:06:43 -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 1F23D3A6827 for ; Thu, 9 Jul 2009 19:06:42 -0700 (PDT) Received: from ATLANTIS.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 n6A274H9016131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2009 22:07:06 -0400 (EDT) Date: Thu, 09 Jul 2009 22:07:04 -0400 From: Jeffrey Hutzelman To: Randy Presuhn , isms@ietf.org Message-ID: <23DCCDFC2F7B74A5ECE98D29@atlantis.pc.cs.cmu.edu> In-Reply-To: <470_1247176706_n69LwP66006375_001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer> References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> <003c01ca00bf$faf08260$6801a8c0@oemcomputer> <28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local> <9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu> <470_1247176706_n69LwP66006375_001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer> 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: jhutz@cmu.edu Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 10 Jul 2009 02:06:44 -0000 --On Thursday, July 09, 2009 02:59:37 PM -0700 Randy Presuhn wrote: > Hi - > >> From: "Jeffrey Hutzelman" >> To: "Juergen Schoenwaelder" ; >> "Randy Presuhn" Cc: ; >> >> Sent: Thursday, July 09, 2009 11:42 AM >> Subject: Re: [Isms] (D)TLS question #2: expecting a server side >> certificate > ... >> I don't think it's appropriate to develop an ISMS-specific approach to >> using SNMP to manage certificate stores. Management of certificate >> stores should be done in a standardized way, not tied to a particular >> application, and the expertise for doing it right lies in PKIX, not >> here. > ... > > It would be fine with me if we just had a pointer to the appropriate RFC > indicating how it should be done. My point is that it should not be left > to the reader's imagination. If there is no specification for us to > point to, then the work here is not standardization, but rather just > wishful thinking. It turns out that it is useful to have standards describing how license plates are formatted, what information they contain, how they are affixed to the vehicle is useful, and even requiring their use by all vehicle owners -- even though there is no standard specifying how they are distributed to the vehicle owner. Provisioning certificates is not the same as provisioning USM keys. A device generally needs to know only about approximately two certificates -- its own and that of a CA which signs the certificates of the entities it talks to. Defining a secure transport model using certificates furthers ISMS's goals by making it possible for operators to use their existing infrastructure to provision each device and each user, rather than provisioning each user on each device, and each NG on each NR, and so on. The reality is that certificate management is already widely deployed, it is highly implementation-dependent, and as Wes notes, it is frequently part of the bootstrapping process. Leaving this problem up to the implementors is _not_ wishful thinking; they have largely already solved it. Wishful thinking would be designing an ISMS certificate store MIB that no one ever uses because it fails to meet anyones actual needs or be consistent with implementors certificate management strategies. -- Jeff From randy_presuhn@mindspring.com Thu Jul 9 19:38:28 2009 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 109773A6932 for ; Thu, 9 Jul 2009 19:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 6RuN-Z0vjkuP for ; Thu, 9 Jul 2009 19:38:27 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 3AE563A67AA for ; Thu, 9 Jul 2009 19:38:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Ip6wD9/Nw5iM3qw/t5HkEl/s+puJPk6H0qtSCuPiaCPBzGK/CKeXiIdtnmAlw5OR; 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.145.167] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MP60h-0004S3-Vz for isms@ietf.org; Thu, 09 Jul 2009 22:38:52 -0400 Message-ID: <000a01ca0107$b5dc6840$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> <003c01ca00bf$faf08260$6801a8c0@oemcomputer> <28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local> <9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu> <470_1247176706_n69LwP66006375_001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer> <23DCCDFC2F7B74A5ECE98D29@atlantis.pc.cs.cmu.edu> Date: Thu, 9 Jul 2009 19:39:42 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968bd822277d328d1ed74c99c8f627f16fa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.145.167 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 10 Jul 2009 02:38:28 -0000 Hi - > From: "Jeffrey Hutzelman" > To: "Randy Presuhn" ; > Cc: > Sent: Thursday, July 09, 2009 7:07 PM > Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate ... > The reality is that certificate management is already widely deployed, it > is highly implementation-dependent, and as Wes notes, it is frequently part > of the bootstrapping process. Leaving this problem up to the implementors > is _not_ wishful thinking; they have largely already solved it. Wishful > thinking would be designing an ISMS certificate store MIB that no one ever > uses because it fails to meet anyones actual needs or be consistent with > implementors certificate management strategies. ... Then the document should simply say something like: How certificates are delivered, installed, and managed is implementation-dependent, and outside the scope of this memo. and declare victory. Randy From wjhns1@hardakers.net Fri Jul 10 10:46:13 2009 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 883033A6A0C for ; Fri, 10 Jul 2009 10:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 rXFp2qPtzaRw for ; Fri, 10 Jul 2009 10:46:12 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id A877B28C2D9 for ; Fri, 10 Jul 2009 10:46:12 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 53F3D98131; Fri, 10 Jul 2009 10:46:40 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 72C8C39A0EE; Fri, 10 Jul 2009 10:46:39 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> <003c01ca00bf$faf08260$6801a8c0@oemcomputer> <28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local> <9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu> <470_1247176706_n69LwP66006375_001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer> <23DCCDFC2F7B74A5ECE98D29@atlantis.pc.cs.cmu.edu> <000a01ca0107$b5dc6840$6801a8c0@oemcomputer> Date: Fri, 10 Jul 2009 10:46:39 -0700 In-Reply-To: <000a01ca0107$b5dc6840$6801a8c0@oemcomputer> (Randy Presuhn's message of "Thu, 9 Jul 2009 19:39:42 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 10 Jul 2009 17:46:13 -0000 >>>>> On Thu, 9 Jul 2009 19:39:42 -0700, "Randy Presuhn" said: RP> Then the document should simply say something like: RP> How certificates are delivered, installed, and managed is RP> implementation-dependent, and outside the scope of this RP> memo. [there actually is similar text in there now, but I like your wording so may replace it with yours] I think that consensus on this has been pretty much reached and I'll summarize below * We won't be defining a certificate management process [with text similar to the above] * We will be at least referring to how snmp address datatypes should be used for the CommonName/subjectAltName server-side certificate comparison and will reference another document describing the details of how those comparisons are done. * We will only be relying on CommonName/subjectAltName mapping and not a hash-reference for the standardized TLSTM work. We won't prohibit an implementation for offering other implementation-dependent mapping functionality, though. -- Wes Hardaker Cobham Analytic Solutions From rpurvis@mitre.org Sat Jul 11 11:04:44 2009 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 85CB13A6AE4 for ; Sat, 11 Jul 2009 11:04:44 -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 lfJc4DivxZ2v for ; Sat, 11 Jul 2009 11:04:43 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D109F3A67A5 for ; Sat, 11 Jul 2009 11:04:10 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n6ABrAgJ018957 for ; Fri, 10 Jul 2009 07:53:10 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n6ABrAHl018954; Fri, 10 Jul 2009 07:53:10 -0400 Received: from IMCMBX4.MITRE.ORG ([129.83.29.207]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 10 Jul 2009 07:53:09 -0400 From: "Purvis, Ray" To: "'Jeffrey Hutzelman'" , Randy Presuhn , "isms@ietf.org" Date: Fri, 10 Jul 2009 07:53:09 -0400 Thread-Topic: [Isms] (D)TLS question #2: expecting a server side certificate Thread-Index: AcoBAyU2PIo3MxuFScWzZmu9FZitrQAUDSmw Message-ID: <547D5A0BAE35D24E92102CBF0A8D62320B3E25549C@IMCMBX4.MITRE.ORG> References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> <003c01ca00bf$faf08260$6801a8c0@oemcomputer> <28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local> <9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu> <470_1247176706_n69LwP66006375_001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer> <23DCCDFC2F7B74A5ECE98D29@atlantis.pc.cs.cmu.edu> In-Reply-To: <23DCCDFC2F7B74A5ECE98D29@atlantis.pc.cs.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 11 Jul 2009 18:04:44 -0000 Hi, Well said. I like the approach Wes currently has of seeing the loaded cert= s using hashed references, this is universal no matter how they got there. = In my own little world we have our own methods, as Jeff points out, of del= ivering the certs, and really don't require an ISMS specific method....but = that's just us! We may require SNMP managed methods of handling our delive= ry process, but, imho, that shouldn't be an ISMS MIB. My 2 cents.... Ray -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Jef= frey Hutzelman Sent: Thursday, July 09, 2009 9:07 PM To: Randy Presuhn; isms@ietf.org Cc: jhutz@cmu.edu Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate --On Thursday, July 09, 2009 02:59:37 PM -0700 Randy Presuhn=20 wrote: > Hi - > >> From: "Jeffrey Hutzelman" >> To: "Juergen Schoenwaelder" ; >> "Randy Presuhn" Cc: ; >> >> Sent: Thursday, July 09, 2009 11:42 AM >> Subject: Re: [Isms] (D)TLS question #2: expecting a server side >> certificate > ... >> I don't think it's appropriate to develop an ISMS-specific approach to >> using SNMP to manage certificate stores. Management of certificate >> stores should be done in a standardized way, not tied to a particular >> application, and the expertise for doing it right lies in PKIX, not >> here. > ... > > It would be fine with me if we just had a pointer to the appropriate RFC > indicating how it should be done. My point is that it should not be left > to the reader's imagination. If there is no specification for us to > point to, then the work here is not standardization, but rather just > wishful thinking. It turns out that it is useful to have standards describing how license=20 plates are formatted, what information they contain, how they are affixed=20 to the vehicle is useful, and even requiring their use by all vehicle=20 owners -- even though there is no standard specifying how they are=20 distributed to the vehicle owner. Provisioning certificates is not the same as provisioning USM keys. A=20 device generally needs to know only about approximately two certificates --= =20 its own and that of a CA which signs the certificates of the entities it=20 talks to. Defining a secure transport model using certificates furthers=20 ISMS's goals by making it possible for operators to use their existing=20 infrastructure to provision each device and each user, rather than=20 provisioning each user on each device, and each NG on each NR, and so on. The reality is that certificate management is already widely deployed, it=20 is highly implementation-dependent, and as Wes notes, it is frequently part= =20 of the bootstrapping process. Leaving this problem up to the implementors= =20 is _not_ wishful thinking; they have largely already solved it. Wishful=20 thinking would be designing an ISMS certificate store MIB that no one ever= =20 uses because it fails to meet anyones actual needs or be consistent with=20 implementors certificate management strategies. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From ietfdbh@comcast.net Sat Jul 11 16:59:57 2009 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 48F393A6C0E for ; Sat, 11 Jul 2009 16:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=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 CyAVN-xNvOcs for ; Sat, 11 Jul 2009 16:59:56 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 500083A69CA for ; Sat, 11 Jul 2009 16:59:56 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA10.westchester.pa.mail.comcast.net with comcast id EnxA1c0010Fqzac5Ao0SrN; Sun, 12 Jul 2009 00:00:26 +0000 Received: from Harrington73653 ([202.106.79.11]) by OMTA08.westchester.pa.mail.comcast.net with comcast id Enzx1c0010EeVTe3Uo0BBw; Sun, 12 Jul 2009 00:00:24 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer><002b01c9fff7$d4226a40$6801a8c0@oemcomputer><005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer><000401ca0015$55df6f20$6801a8c0@oemcomputer><003c01ca00bf$faf08260$6801a8c0@oemcomputer><28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local><9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu><001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer><0ff501ca00f8$31cc4340$0600a8c0@china.huawei.com><10fd01ca01af$8a800230$0600a8c0@china.huawei.com><115a01ca0234$44923d30$0600a8c0@china.huawei.com> Date: Sat, 11 Jul 2009 19:59:54 -0400 Message-ID: <119501ca0283$bf102c80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: Thread-Index: AcoCS9ML/Ynl/hGVTfCQVxBFCxD7ZAANgBCQ Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 11 Jul 2009 23:59:57 -0000 Hi, syslog/TLS requires implementation of self-signed certs for when a PKI system is not available (either by configuration choice or because the device has not yet established conectivity to the PKI). I am no expert in PKI and TLS, but my understanding is we have this is in syslog because SamH insisted that a non-PKI solution MUST be available (when syslog/TLS became a MUST to meet congestion control demands of the transport ADs). Pasi agreed and liked the fingerprint/self-signed certs for when PKI was not available. If I have this wrong, I invite correction by Sam and/or Pasi. Without making this a MUST implement for SNMP as well, an SNMP system not co-resident with a syslog system might not support the self-signed certs, and that means operators would need to use a different configuration for the TLS for SNMP-alone vs SNMP+syslog. I think that indirectly defeats the purpose of ISMS, which is to simplify the security configuration needed for SNMP. Woudn't it be simpler to mandate implementation of (but not use of) self-signed certs for SNMP/TLS as well? dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Saturday, July 11, 2009 1:20 PM > To: David Harrington > Cc: 'Wes Hardaker' > Subject: Re: (D)TLS question #2: expecting a server side certificate > > >>>>> On Sat, 11 Jul 2009 10:31:12 -0400, "David Harrington" > said: > > DH> I was thinking of End-entity certificate matching, using > fingerprints, > DH> as described in 4.2.2. "This method provides an > alternative to a PKI > DH> that is simple to deploy and still maintains a reasonable level of > DH> security. > DH> Both transport receiver and transport sender implementations MUST > DH> provide means to generate a key pair and self-signed > certificate in > DH> the case that a key pair and certificate are not available through > DH> another mechanism." > > Ah, but see that's basically what we've been talking about (but have > also been talking about MIB support around it). I think ISMS has > functionally agreed that the subjectAltName is a MUST but we're not > going to prohibit the above (and thus it becomes a MAY). > > -- > Wes Hardaker > Cobham Analytic Solutions > From wjhns1@hardakers.net Sun Jul 12 21:22:18 2009 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 B14663A690D for ; Sun, 12 Jul 2009 21:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 RJDK-uzbXMNl for ; Sun, 12 Jul 2009 21:22:18 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id D7F673A68CB for ; Sun, 12 Jul 2009 21:22:17 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 690B3980A9; Sun, 12 Jul 2009 21:22:46 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2BAD639A0EE; Sun, 12 Jul 2009 21:22:45 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer> <002b01c9fff7$d4226a40$6801a8c0@oemcomputer> <005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer> <000401ca0015$55df6f20$6801a8c0@oemcomputer> <003c01ca00bf$faf08260$6801a8c0@oemcomputer> <28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local> <9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu> <001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer> <0ff501ca00f8$31cc4340$0600a8c0@china.huawei.com> <10fd01ca01af$8a800230$0600a8c0@china.huawei.com> <115a01ca0234$44923d30$0600a8c0@china.huawei.com> <119501ca0283$bf102c80$0600a8c0@china.huawei.com> Date: Sun, 12 Jul 2009 21:22:45 -0700 In-Reply-To: <119501ca0283$bf102c80$0600a8c0@china.huawei.com> (David Harrington's message of "Sat, 11 Jul 2009 19:59:54 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 13 Jul 2009 04:22:18 -0000 >>>>> On Sat, 11 Jul 2009 19:59:54 -0400, "David Harrington" said: DH> Woudn't it be simpler to mandate implementation of (but not use of) DH> self-signed certs for SNMP/TLS as well? I think you bring up a lot of good points and I suspect that this discussion will roll into the meeting at this point, but that's a good thing. I'll make sure to have slides available to talk about it (and in fact, I already do). It'd probably take me less work to implement the MIB than it would to argue about whether we should do it or not ;-) -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Tue Jul 14 09:04:20 2009 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 025E03A6844 for ; Tue, 14 Jul 2009 09:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, J_CHICKENPOX_46=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 OLQu1RI3cwve for ; Tue, 14 Jul 2009 09:04:19 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id A447C3A68BC for ; Tue, 14 Jul 2009 09:04:01 -0700 (PDT) X-Trace: 232504915/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.201/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.201 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAINCXEo+vGTJ/2dsb2JhbACDLDwejAfBOgmDfwWBPQ X-IronPort-AV: E=Sophos;i="4.42,398,1243810800"; d="scan'208";a="232504915" X-IP-Direction: IN Received: from 1cust201.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.201]) by smtp.pipex.tiscali.co.uk with SMTP; 14 Jul 2009 16:36:10 +0100 Message-ID: <000a01ca0490$29b65f60$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Wes Hardaker'" , References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer><002b01c9fff7$d4226a40$6801a8c0@oemcomputer><005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer><000401ca0015$55df6f20$6801a8c0@oemcomputer><003c01ca00bf$faf08260$6801a8c0@oemcomputer><28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local><9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu><001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer><0ff501ca00f8$31cc4340$0600a8c0@china.huawei.com><10fd01ca01af$8a800230$0600a8c0@china.huawei.com><115a01ca0234$44923d30$0600a8c0@china.huawei.com> <119501ca0283$bf102c80$0600a8c0@china.huawei.com> Date: Tue, 14 Jul 2009 15:07:27 +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 Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 16:04:20 -0000 ----- Original Message ----- From: "David Harrington" To: "'Wes Hardaker'" ; Sent: Sunday, July 12, 2009 1:59 AM > > syslog/TLS requires implementation of self-signed certs for when a PKI > system is not available (either by configuration choice or because the > device has not yet established conectivity to the PKI). > > I am no expert in PKI and TLS, but my understanding is we have this is > in syslog because SamH insisted that a non-PKI solution MUST be > available (when syslog/TLS became a MUST to meet congestion control > demands of the transport ADs). Pasi agreed and liked the > fingerprint/self-signed certs for when PKI was not available. > > If I have this wrong, I invite correction by Sam and/or Pasi. > > Without making this a MUST implement for SNMP as well, an SNMP system > not co-resident with a syslog system might not support the self-signed > certs, and that means operators would need to use a different > configuration for the TLS for SNMP-alone vs SNMP+syslog. I think that > indirectly defeats the purpose of ISMS, which is to simplify the > security configuration needed for SNMP. Woudn't it be simpler to > mandate implementation of (but not use of) self-signed certs for > SNMP/TLS as well? > I agree; we should at least keep syslog and SNMP in line. I would also encourage anyone listening in to join apps-discuss@ietf.org and press for this in the server identification draft, draft-hodges-server-ident-check Some on that list are pushing for an http, TLS, PKI solution only, whereas I see the I-D as an opportunity to introduce a much-needed, wider coherence to the IETF. Tom Petch > dbh > > > -----Original Message----- > > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > > Sent: Saturday, July 11, 2009 1:20 PM > > To: David Harrington > > Cc: 'Wes Hardaker' > > Subject: Re: (D)TLS question #2: expecting a server side certificate From wjhns1@hardakers.net Wed Jul 15 17:07:49 2009 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 CF50C28C16C for ; Wed, 15 Jul 2009 17:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_46=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 LUNmW6CwbWKY for ; Wed, 15 Jul 2009 17:07:30 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 7A4E628C15D for ; Wed, 15 Jul 2009 17:07:30 -0700 (PDT) Received: from [10.96.230.84] (unknown [32.153.4.174]) by mail.hardakers.net (Postfix) with ESMTPA id 54F009810F; Wed, 15 Jul 2009 17:07:51 -0700 (PDT) From: "Wes Hardaker" Date: 15 Jul 2009 17:08:00 -0700 To: X-Mailer: ChatterEmail+ for Treo 6xx/700p (3.0.7) Message-ID: <3330522481.185949@mail.hardakers.net> Cc: isms@ietf.org Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 16 Jul 2009 00:07:49 -0000 Thanks for thw pointer to the other discussion Tom, you're right that it's important. Very in fact since the tlstm document already references it ( and i'd prefer to keep the reference). -----Original Message----- From: "tom.petch" Date: Tuesday, Jul 14, 2009 8:36 am Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate To: Reply- "tom.petch" To: "David Harrington" , "'Wes Hardaker'" , ----- Original Message ----- >From: "David Harrington" >To: "'Wes Hardaker'" ; >Sent: Sunday, July 12, 2009 1:59 AM > > syslog/TLS requires implementation of self-signed certs for when a PKI > system is not available (either by configuration choice or because the > device has not yet established conectivity to the PKI). > > I am no expert in PKI and TLS, but my understanding is we have this is > in syslog because SamH insisted that a non-PKI solution MUST be > available (when syslog/TLS became a MUST to meet congestion control > demands of the transport ADs). Pasi agreed and liked the > fingerprint/self-signed certs for when PKI was not available. > > If I have this wrong, I invite correction by Sam and/or Pasi. > > Without making this a MUST implement for SNMP as well, an SNMP system > not co-resident with a syslog system might not support the self-signed > certs, and that means operators would need to use a different > configuration for the TLS for SNMP-alone vs SNMP+syslog. I think that > indirectly defeats the purpose of ISMS, which is to simplify the > security configuration needed for SNMP. Woudn't it be simpler to > mandate implementation of (but not use of) self-signed certs for > SNMP/TLS as well? > > >I agree; we should at least keep syslog and SNMP in line. > >I would also encourage anyone listening in to join >apps-discuss@ietf.org >and press for this in the server identification draft, >draft-hodges-server-ident-check >Some on that list are pushing for an http, TLS, PKI solution only, >whereas I see the I-D as an opportunity to introduce a much-needed, >wider coherence to the IETF. > >Tom Petch > >> dbh > > > -----Original Message----- > > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > > Sent: Saturday, July 11, 2009 1:20 PM > > To: David Harrington > > Cc: 'Wes Hardaker' > > Subject: Re: (D)TLS question #2: expecting a server side certificate > > From j.schoenwaelder@jacobs-university.de Mon Jul 27 00:24:54 2009 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 A17D628C0F7 for ; Mon, 27 Jul 2009 00:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntl7WI2qaF1Q for ; Mon, 27 Jul 2009 00:24:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1C02D3A69FA for ; Mon, 27 Jul 2009 00:24:53 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E50E5C0039 for ; Mon, 27 Jul 2009 09:24:53 +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 DnSYso2VKq7C; Mon, 27 Jul 2009 09:24:53 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 224C9C0038; Mon, 27 Jul 2009 09:24:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E5494B6D0D6; Mon, 27 Jul 2009 09:24:52 +0200 (CEST) Date: Mon, 27 Jul 2009 09:24:52 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090727072452.GA10456@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.19 (2009-01-05) Subject: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 07:24:54 -0000 Hi, here are a few comments (posted as a technical contributor) on the RADIUS / VACM document: A: How specific should the document refer to the TSM? Should we try to phrase things such that things still work in case we replace TSM with something else? B: I suggest that we do not overwrite existing table entries. C: The aging I think needs more work so that we can handle situations where user joe logs into an agent at t1 and a second time at t2 and then the first session ends at t3. The second session should not loose the group name mapping entry in this case. So implementations somehow need to do some reference counting. D: I am not sure why the USM discussion in the security considerations section is needed. E: Is there a need for a MIB module exposing an augmentation of the VACM table with session/timeout information? Such a table would allow a management application that is aware of this extension to detect where some name to group mapping entries are originating from. But on the other hand, we do not generally indicate where some config snippet is originating from in SNMP land... Though we will have time to discuss things later today in the WG meeting, I brought this to the list since not all contributors and in particular the document editors make it to Stockholm. /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 Mon Jul 27 00:29:25 2009 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 6AD073A6BCC for ; Mon, 27 Jul 2009 00:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-sf+T7RjIvU for ; Mon, 27 Jul 2009 00:29:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6E41B3A6A8B for ; Mon, 27 Jul 2009 00:29:24 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D06AC0039 for ; Mon, 27 Jul 2009 09:29:25 +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 2FC2MaaIbxMF; Mon, 27 Jul 2009 09:29: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 C429FC0012; Mon, 27 Jul 2009 09:29:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9D00CB6D114; Mon, 27 Jul 2009 09:29:24 +0200 (CEST) Date: Mon, 27 Jul 2009 09:29:24 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090727072924.GB10456@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.19 (2009-01-05) Subject: [Isms] snmp: URI scheme transport extensions 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, 27 Jul 2009 07:29:25 -0000 Hi, while doing some SNMP during vacation, I did run into an issue with the snmp: URI scheme defined in RFC 4088. When RFC 4088 was created, we excluded transport information from SNMP service URIs. Now, with the presence of much more transports, it would be really nice to have the URI format supporting transport parameters, e.g. snmp://tester5@example.com:5161;transport=ssh ^^^^^^^^^^^^^^ new I would be willing to work on this because I need it for some tools; perhaps this work should be hosted at OPSAWG? I obviously forgot to bring this up while ISMS was rechartering. But the transports we have to provision extend ISMS transports anyway so OPSAWG might be a good choice. Anyway, at this point in time, I just bring this up to see whether there is interest to work this out or it is just me. /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 Mon Jul 27 01:12:50 2009 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 C1B273A6C16 for ; Mon, 27 Jul 2009 01:12:50 -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 rl5Zo-HrpnjL for ; Mon, 27 Jul 2009 01:12:47 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id B7DD13A6C0B for ; Mon, 27 Jul 2009 01:12:46 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 443159811B for ; Mon, 27 Jul 2009 01:12:47 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 7E72A39A351 for ; Mon, 27 Jul 2009 01:12:46 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20090727072924.GB10456@elstar.local> Date: Mon, 27 Jul 2009 01:12:46 -0700 In-Reply-To: <20090727072924.GB10456@elstar.local> (Juergen Schoenwaelder's message of "Mon, 27 Jul 2009 09:29:24 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 08:12:50 -0000 >>>>> On Mon, 27 Jul 2009 09:29:24 +0200, Juergen Schoenwaelder said: JS> snmp://tester5@example.com:5161;transport=ssh JS> ^^^^^^^^^^^^^^ JS> new I think you're still missing an important element, namely the securityModel. No where above does it specify TSM anywhere so I don't think it's complete as is. [I think that's likely missing from 4088 as well, for that matter, regardless of whether it's updated for transport specific concerns; the fact that it's excluded from the original document is sort of odd in my opinion in the first place since we're obviously to the point where multiple security models exist (although they've existed long before this)] -- Wes Hardaker Cobham Analytic Solutions From Pasi.Eronen@nokia.com Mon Jul 27 01:34:57 2009 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 ED1983A6C05 for ; Mon, 27 Jul 2009 01:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.355, 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 VOG8tq8f3mTL for ; Mon, 27 Jul 2009 01:34:57 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D76763A6ACA for ; Mon, 27 Jul 2009 01:34:53 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6R8XrPd014764; Mon, 27 Jul 2009 03:34:39 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 11:34:32 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 11:34:31 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 11:34:26 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 27 Jul 2009 10:34:26 +0200 From: To: , , Date: Mon, 27 Jul 2009 10:34:24 +0200 Thread-Topic: [Isms] (D)TLS question #2: expecting a server side certificate Thread-Index: AcoCS9ML/Ynl/hGVTfCQVxBFCxD7ZAANgBCQAwSEyqA= Message-ID: <808FD6E27AD4884E94820BC333B2DB773A71475683@NOK-EUMSG-01.mgdnok.nokia.com> References: <003601c9ff65$110e4f20$6801a8c0@oemcomputer><002b01c9fff7$d4226a40$6801a8c0@oemcomputer><005b01c9fffd$8d7f2aa0$6801a8c0@oemcomputer><000401ca0015$55df6f20$6801a8c0@oemcomputer><003c01ca00bf$faf08260$6801a8c0@oemcomputer><28944_1247164095_n69ISEEb012095_20090709182807.GA7502@elstar.local><9579026E66CD8EDCC6AE265B@atlantis.pc.cs.cmu.edu><001e01ca00e0$8dabc7c0$6801a8c0@oemcomputer><0ff501ca00f8$31cc4340$0600a8c0@china.huawei.com><10fd01ca01af$8a800230$0600a8c0@china.huawei.com><115a01ca0234$44923d30$0600a8c0@china.huawei.com> <119501ca0283$bf102c80$0600a8c0@china.huawei.com> In-Reply-To: <119501ca0283$bf102c80$0600a8c0@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2009 08:34:26.0626 (UTC) FILETIME=[0D1ADA20:01CA0E95] X-Nokia-AV: Clean Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate 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, 27 Jul 2009 08:34:58 -0000 David Harrington wrote: > Hi, >=20 > syslog/TLS requires implementation of self-signed certs for when a PKI > system is not available (either by configuration choice or because the > device has not yet established conectivity to the PKI). >=20 > I am no expert in PKI and TLS, but my understanding is we have this is > in syslog because SamH insisted that a non-PKI solution MUST be > available (when syslog/TLS became a MUST to meet congestion control > demands of the transport ADs). Pasi agreed and liked the > fingerprint/self-signed certs for when PKI was not available. >=20 > If I have this wrong, I invite correction by Sam and/or Pasi. In syslog, syslog-over-tls is the mandatory-to-implement transport, and the only currently specified security mechanism. However, for ISMS we already have SSHTM that can be used without PKI, so requiring a PKI for DTLSTM is not totally unreasonable. Nevertheless, I think supporting fingerprints (like in syslog) in DTLSTM would be quite useful, and I'd support including it in the draft. Best regards, Pasi From ietfdbh@comcast.net Mon Jul 27 01:47:54 2009 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 529A928C22B for ; Mon, 27 Jul 2009 01:47:54 -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 y1et3GBR9Rhl for ; Mon, 27 Jul 2009 01:47:53 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id F133328C25A for ; Mon, 27 Jul 2009 01:47:47 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id LwnQ1c0011HpZEsA8wnqSM; Mon, 27 Jul 2009 08:47:50 +0000 Received: from Harrington73653 ([130.129.18.98]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id Lwnd1c00326xVzW8awngvD; Mon, 27 Jul 2009 08:47:47 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: <20090727072924.GB10456@elstar.local> Date: Mon, 27 Jul 2009 10:47:36 +0200 Message-ID: <015b01ca0e96$e9f17840$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoOkgxt2m/G+KjUT+Cg/sQxN+TFMAAA79mw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 08:47:54 -0000 Hi, I don't use URIs in my work, so I may be overlooking why we need this. Why do we need to specify the transport in the URI? We are already specifying port 5161, which is snmp/ssh. Why do we need to specify the securityModel in the URI? It is already specified in the SNMP header. If the purpose is to specify to the URI user which transport should be used, and which secmodel should be used, then the information is incomplete. Wouldn't we need to specify the securityName, securityLevel, and so on as well? and maybe the ssh username to use? In fact, wouldn't we need to specify everything that could be specified in the set of tables in the notification-mib? What is the use case that requires including this info in the URI? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Monday, July 27, 2009 10:13 AM > To: isms@ietf.org > Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions > > >>>>> On Mon, 27 Jul 2009 09:29:24 +0200, Juergen > Schoenwaelder said: > > JS> snmp://tester5@example.com:5161;transport=ssh > JS> ^^^^^^^^^^^^^^ > JS> new > > I think you're still missing an important element, namely the > securityModel. No where above does it specify TSM anywhere so I don't > think it's complete as is. > > [I think that's likely missing from 4088 as well, for that matter, > regardless of whether it's updated for transport specific > concerns; the > fact that it's excluded from the original document is sort of > odd in my > opinion in the first place since we're obviously to the point where > multiple security models exist (although they've existed long > before this)] > > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Mon Jul 27 02:13:00 2009 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 138D528C146 for ; Mon, 27 Jul 2009 02:13:00 -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 gni1Pw1V7U32 for ; Mon, 27 Jul 2009 02:12:58 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 7909528C13F for ; Mon, 27 Jul 2009 02:12:58 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id ABA5898063; Mon, 27 Jul 2009 02:12:53 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id DE5B439A355; Mon, 27 Jul 2009 02:12:52 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20090727072924.GB10456@elstar.local> <015b01ca0e96$e9f17840$7958404e@china.huawei.com> Date: Mon, 27 Jul 2009 02:12:52 -0700 In-Reply-To: <015b01ca0e96$e9f17840$7958404e@china.huawei.com> (David Harrington's message of "Mon, 27 Jul 2009 10:47:36 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 09:13:00 -0000 >>>>> On Mon, 27 Jul 2009 10:47:36 +0200, "David Harrington" said: DH> Why do we need to specify the transport in the URI? We are already DH> specifying port 5161, which is snmp/ssh. You're presuming TCP there. You're also presuming a standard port is being used and you can determine from that what is running on it, which isn't a safe assumption. DH> Why do we need to specify the securityModel in the URI? It is already DH> specified in the SNMP header. It's configuring a client. Consider a URI the equivalent of a TARGET-MIB entry that specifies how the client should connect. The point of the URI stuff (I don't use it either, but Juergen will correct me if I'm wrong) is to be able to do the equivalent of: snmpget snmp://tester5@example.com:5161;transport=ssh sysContact.0 No other command line options needed because it's all in the URI string. [on a side note, I *did* write a plugin to KDE once to make their web browser do something almost exactly like this... Connect via SNMP to a remote agent given a URI and display the results.] DH> In fact, wouldn't we need to specify everything that could be DH> specified in the set of tables in the notification-mib? I think so, yes [but really it's a target]. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Mon Jul 27 02:32:06 2009 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 6324528C158 for ; Mon, 27 Jul 2009 02:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_93=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 u0KB57vOigAx for ; Mon, 27 Jul 2009 02:32:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3924B28C23C for ; Mon, 27 Jul 2009 02:32:05 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39474C003C; Mon, 27 Jul 2009 11:32:06 +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 qwWzGMxzO-nm; Mon, 27 Jul 2009 11:32:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02258C0039; Mon, 27 Jul 2009 11:32:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 732E0B6D27C; Mon, 27 Jul 2009 11:32:04 +0200 (CEST) Date: Mon, 27 Jul 2009 11:32:04 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090727093204.GA10532@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: <20090727072924.GB10456@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 09:32:06 -0000 On Mon, Jul 27, 2009 at 10:12:46AM +0200, Wes Hardaker wrote: > >>>>> On Mon, 27 Jul 2009 09:29:24 +0200, Juergen Schoenwaelder said: > > JS> snmp://tester5@example.com:5161;transport=ssh > JS> ^^^^^^^^^^^^^^ > JS> new > > I think you're still missing an important element, namely the > securityModel. No where above does it specify TSM anywhere so I don't > think it's complete as is. Yes, I agree. I was thinking about having a default for all this as we do now - you get SNMPv3/USM/UDP. If you specify transport=ssh, you get securitymodel=tsm as default - I did not spell this out. > [I think that's likely missing from 4088 as well, for that matter, > regardless of whether it's updated for transport specific concerns; > the fact that it's excluded from the original document is sort of > odd in my opinion in the first place since we're obviously to the > point where multiple security models exist (although they've existed > long before this)] When RFC 4088 was done, we scoped the work and now might be the time to make it more complete. What we discussed back then was more version information for community based SNMP, e.g. snmp://tester5@example.com:5161;version=snmpv1 (but we felt that opening this can of worms for a historic protocol version could be troublesome and so we tossed this idea). /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 Mon Jul 27 02:40:17 2009 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 996AB28C1FE for ; Mon, 27 Jul 2009 02:40:17 -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 kkutPLO2Scs0 for ; Mon, 27 Jul 2009 02:40:16 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 63EFA28C2A3 for ; Mon, 27 Jul 2009 02:39:47 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Lxdj1c0010b6N64A2xfpo5; Mon, 27 Jul 2009 09:39:49 +0000 Received: from Harrington73653 ([130.129.18.98]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id Lxfc1c00426xVzW8Pxffir; Mon, 27 Jul 2009 09:39:47 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , References: <20090727072924.GB10456@elstar.local> Date: Mon, 27 Jul 2009 11:39:35 +0200 Message-ID: <017301ca0e9e$2d180150$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoOi/shGuwT6RDgS4mOO6DsEm687gAEhU4A In-Reply-To: <20090727072924.GB10456@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] snmp: URI scheme transport extensions 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, 27 Jul 2009 09:40:17 -0000 Hi, Since the purpose of ISMS is to add new transports, I would think this would belong in ISMS. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Monday, July 27, 2009 9:29 AM > To: isms@ietf.org > Subject: [Isms] snmp: URI scheme transport extensions > > Hi, > > while doing some SNMP during vacation, I did run into an issue with > the snmp: URI scheme defined in RFC 4088. When RFC 4088 was created, > we excluded transport information from SNMP service URIs. Now, with > the presence of much more transports, it would be really nice to have > the URI format supporting transport parameters, e.g. > > snmp://tester5@example.com:5161;transport=ssh > ^^^^^^^^^^^^^^ > new > > I would be willing to work on this because I need it for some tools; > perhaps this work should be hosted at OPSAWG? I obviously forgot to > bring this up while ISMS was rechartering. But the transports we have > to provision extend ISMS transports anyway so OPSAWG might be a good > choice. Anyway, at this point in time, I just bring this up to see > whether there is interest to work this out or it is just me. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Mon Jul 27 03:26:07 2009 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 2F2F23A6C05 for ; Mon, 27 Jul 2009 03:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=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 mzbk6As9s4m0 for ; Mon, 27 Jul 2009 03:26:06 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 1BD553A6857 for ; Mon, 27 Jul 2009 03:26:05 -0700 (PDT) Received: from OMTA22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id LyQX1c0011vN32cAAyS7jz; Mon, 27 Jul 2009 10:26:07 +0000 Received: from Harrington73653 ([130.129.18.98]) by OMTA22.emeryville.ca.mail.comcast.net with comcast id LyUP1c00226xVzW8iyUSmK; Mon, 27 Jul 2009 10:28:35 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Wes Hardaker'" References: <20090727072924.GB10456@elstar.local> <20090727093204.GA10532@elstar.local> Date: Mon, 27 Jul 2009 12:25:48 +0200 Message-ID: <017b01ca0ea4$a378f880$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoOnR4IA0a8X1hoSfmfbfeyV3w3jQABstFg In-Reply-To: <20090727093204.GA10532@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 10:26:07 -0000 Hi, I believe having ssh **imply** tsm is inappropriate from an RFC3411 modularity POV. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Monday, July 27, 2009 11:32 AM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions > > On Mon, Jul 27, 2009 at 10:12:46AM +0200, Wes Hardaker wrote: > > >>>>> On Mon, 27 Jul 2009 09:29:24 +0200, Juergen > Schoenwaelder said: > > > > JS> snmp://tester5@example.com:5161;transport=ssh > > JS> ^^^^^^^^^^^^^^ > > JS> new > > > > I think you're still missing an important element, namely the > > securityModel. No where above does it specify TSM anywhere > so I don't > > think it's complete as is. > > Yes, I agree. I was thinking about having a default for all this as we > do now - you get SNMPv3/USM/UDP. If you specify transport=ssh, you get > securitymodel=tsm as default - I did not spell this out. > > > [I think that's likely missing from 4088 as well, for that matter, > > regardless of whether it's updated for transport specific concerns; > > the fact that it's excluded from the original document is sort of > > odd in my opinion in the first place since we're obviously to the > > point where multiple security models exist (although they've existed > > long before this)] > > When RFC 4088 was done, we scoped the work and now might be the time > to make it more complete. What we discussed back then was more version > information for community based SNMP, e.g. > > snmp://tester5@example.com:5161;version=snmpv1 > > (but we felt that opening this can of worms for a historic protocol > version could be troublesome and so we tossed this idea). > > /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 Mon Jul 27 03:34:03 2009 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 4492C3A694F for ; Mon, 27 Jul 2009 03:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv00m2Z3LkOH for ; Mon, 27 Jul 2009 03:34:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A76D63A69D5 for ; Mon, 27 Jul 2009 03:33:39 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9C35C0039; Mon, 27 Jul 2009 12:33:40 +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 A4VFz1Ie8Poo; Mon, 27 Jul 2009 12:33: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 B755BC0030; Mon, 27 Jul 2009 12:33:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6EECDB6D489; Mon, 27 Jul 2009 12:33:39 +0200 (CEST) Date: Mon, 27 Jul 2009 12:33:39 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090727103339.GB10532@elstar.local> Mail-Followup-To: David Harrington , 'Wes Hardaker' , "isms@ietf.org" References: <20090727072924.GB10456@elstar.local> <015b01ca0e96$e9f17840$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015b01ca0e96$e9f17840$7958404e@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 10:34:03 -0000 On Mon, Jul 27, 2009 at 10:47:36AM +0200, David Harrington wrote: > What is the use case that requires including this info in the URI? We have no interoperable way to write down and to pass around how you access SNMP resources. The snmp: service URI format does address this but the definition is incomplete. I have a command line tool that uses snmp: URIs instead of collections of command line options to specify to which agent you talk to - and it also generates such URIs if you want to. Having a compact serialized notation to pass around this information is helpful. RFC 4088 was actually created because some MIB modules had a need to indicate in a compact way (= one MIB object) where a management application can be found without having to go through multiple related MIB tables. Cut'n'paste of URIs really works great compared to cut'n'paste of collections of MIB objects. ;-) /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 Mon Jul 27 03:35:30 2009 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 5D9FE3A67EE for ; Mon, 27 Jul 2009 03:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-LLfHmtY5Pn for ; Mon, 27 Jul 2009 03:35:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8FD9F3A679F for ; Mon, 27 Jul 2009 03:35:29 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93EDFC0039; Mon, 27 Jul 2009 12:35:30 +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 sxCRQ8XmNRcY; Mon, 27 Jul 2009 12:35:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCAF7C0030; Mon, 27 Jul 2009 12:35:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AF050B6D4CF; Mon, 27 Jul 2009 12:35:29 +0200 (CEST) Date: Mon, 27 Jul 2009 12:35:29 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090727103529.GC10532@elstar.local> Mail-Followup-To: David Harrington , 'Wes Hardaker' , "isms@ietf.org" References: <20090727072924.GB10456@elstar.local> <20090727093204.GA10532@elstar.local> <017b01ca0ea4$a378f880$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <017b01ca0ea4$a378f880$7958404e@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 10:35:30 -0000 On Mon, Jul 27, 2009 at 12:25:48PM +0200, David Harrington wrote: > I believe having ssh **imply** tsm is inappropriate from an RFC3411 > modularity POV. But not incorrect. ;-) There is only an issue if TSM gets replaced by something else and the outcome in that case just won't be as short. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Mon Jul 27 04:49:04 2009 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 5ABDE3A680B for ; Mon, 27 Jul 2009 04:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=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 AFDBNzzMgpB5 for ; Mon, 27 Jul 2009 04:49:03 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id A135E3A695F for ; Mon, 27 Jul 2009 04:48:52 -0700 (PDT) Received: from OMTA19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id Lzmm1c0061eYJf8A9zoubi; Mon, 27 Jul 2009 11:48:54 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA19.emeryville.ca.mail.comcast.net with comcast id Lzot1c0084H2mdz01zotJh; Mon, 27 Jul 2009 11:48:54 +0000 From: "Dave Nelson" To: Date: Mon, 27 Jul 2009 07:48:55 -0400 Message-ID: <0CA70A81387A419690D5910BCDC90326@NEWTON603> 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.5579 Thread-Index: AcoOncAoY9gMv8MVQPu/+ddi4ezJmwAEl36w Subject: [Isms] FW: RFC 5607 on Remote Authentication Dial-In User Service (RADIUS)Authorization for Network Access Server (NAS) Management 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, 27 Jul 2009 11:49:04 -0000 FYI: > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org > Sent: Monday, July 27, 2009 5:30 AM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: radiusext@ops.ietf.org; rfc-editor@rfc-editor.org > Subject: RFC 5607 on Remote Authentication Dial-In User Service > (RADIUS)Authorization for Network Access Server (NAS) Management > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5607 > > Title: Remote Authentication Dial-In User Service > (RADIUS) Authorization for Network Access Server > (NAS) Management > Author: D. Nelson, G. Weber > Status: Standards Track > Date: July 2009 > Mailbox: dnelson@elbrysnetworks.com, > gdweber@gmail.com > Pages: 25 > Characters: 55464 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-radext-management-authorization-07.txt > > URL: http://www.rfc-editor.org/rfc/rfc5607.txt > > This document specifies Remote Authentication Dial-In User Service > (RADIUS) attributes for authorizing management access to a Network > Access Server (NAS). Both local and remote management are supported, > with granular access rights and management privileges. Specific > provisions are made for remote management via Framed Management > protocols and for management access over a secure transport protocol. > [STANDARDS TRACK] > > This document is a product of the RADIUS EXTensions Working Group of the > IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From d.b.nelson@comcast.net Mon Jul 27 05:10:48 2009 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 0702028C180 for ; Mon, 27 Jul 2009 05:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.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 ISwbScOiRm9b for ; Mon, 27 Jul 2009 05:10:47 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 1045B28C140 for ; Mon, 27 Jul 2009 05:10:47 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id M06B1c0040b6N64A80AFcR; Mon, 27 Jul 2009 12:10:15 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id M0AD1c0024H2mdz8P0AE6Q; Mon, 27 Jul 2009 12:10:14 +0000 From: "Dave Nelson" To: References: <20090727072452.GA10456@elstar.local> Date: Mon, 27 Jul 2009 08:10:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090727072452.GA10456@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcoOi1ma7s5KsvztRS+81CX/qLOycgAJYe+g Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 12:10:48 -0000 Juergen Schoenwaelder writes... > here are a few comments (posted as a technical contributor) on the > RADIUS / VACM document: I think you have nicely summarized the open technical issues in the -00 draft. > A: How specific should the document refer to the TSM? Should we try to > phrase things such that things still work in case we replace TSM > with something else? I think that might be nice to do. My one concern is that the mechanism of this document is dependent upon the tmStateReference. While some yet-to-be-written security model might also work with a secure transport model, allowing the VACM extensions in this document to be used without a RADIUS-aware transport model seems to open up a security issue, or at the very least an undefined mode of operation. > B: I suggest that we do not overwrite existing table entries. There seems to be some support for that in the list discussions to date. What we haven't determined is how additional entries are to be structured and what precedence they have with respect to the existing entries. I think some further discussion of this issue is needed. > C: The aging I think needs more work so that we can handle situations > where user joe logs into an agent at t1 and a second time at t2 and > then the first session ends at t3. The second session should not > loose the group name mapping entry in this case. So implementations > somehow need to do some reference counting. Yes. > D: I am not sure why the USM discussion in the security considerations > section is needed. Well, if VACM entries are configured so as to seriously restrict access, and we are relying on dynamic VACM group bindings, what happens if the network is down and we are using the USM "back door" credentials for access? Don't we need corresponding VACM configuration? This more of an operational consideration, than a security consideration, however. > E: Is there a need for a MIB module exposing an augmentation of the > VACM table with session/timeout information? Such a table would > allow a management application that is aware of this extension to > detect where some name to group mapping entries are originating > from. But on the other hand, we do not generally indicate where > some config snippet is originating from in SNMP land... The authors expected that the draft would eventually need to specify a MIB module for this and other items, based on the flow of list discussion to date, but the ideas hadn't sufficiently gelled at the time -00 was written to allow inclusion of that MIB module. > Though we will have time to discuss things later today in the WG > meeting, I brought this to the list since not all contributors and in > particular the document editors make it to Stockholm. Yes. Continued discussion of these items on the list will help us prepare the next draft revision. Thanks! From j.schoenwaelder@jacobs-university.de Mon Jul 27 05:36:02 2009 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 C88BE3A6994 for ; Mon, 27 Jul 2009 05:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKmpEmX3yER7 for ; Mon, 27 Jul 2009 05:36:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D6B853A67FC for ; Mon, 27 Jul 2009 05:36:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7477C0044; Mon, 27 Jul 2009 14:36:02 +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 oj5eHUYkHEFy; Mon, 27 Jul 2009 14:36: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 6D42FC003D; Mon, 27 Jul 2009 14:36:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 138E9B6D7A7; Mon, 27 Jul 2009 14:36:01 +0200 (CEST) Date: Mon, 27 Jul 2009 14:36:01 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090727123600.GA10809@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <20090727072452.GA10456@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 12:36:02 -0000 On Mon, Jul 27, 2009 at 02:10:15PM +0200, Dave Nelson wrote: > Juergen Schoenwaelder writes... > > > here are a few comments (posted as a technical contributor) on the > > RADIUS / VACM document: > > I think you have nicely summarized the open technical issues in the -00 > draft. > > > A: How specific should the document refer to the TSM? Should we try to > > phrase things such that things still work in case we replace TSM > > with something else? > > I think that might be nice to do. My one concern is that the mechanism of > this document is dependent upon the tmStateReference. While some > yet-to-be-written security model might also work with a secure transport > model, allowing the VACM extensions in this document to be used without a > RADIUS-aware transport model seems to open up a security issue, or at the > very least an undefined mode of operation. But isn't the RADIUS aware transport doing the manipulation of the VACM table? Perhaps this is one thing to clarify further - which component is actually manipulating the VACM table. /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 Mon Jul 27 05:47:31 2009 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 9BFD528C1A2 for ; Mon, 27 Jul 2009 05:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 A2JmcJ+53eHP for ; Mon, 27 Jul 2009 05:47:30 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 364AF28C1A4 for ; Mon, 27 Jul 2009 05:47:30 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id M0hZ1c00A0EPchoA50nYjm; Mon, 27 Jul 2009 12:47:32 +0000 Received: from Harrington73653 ([130.129.18.98]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id M0nE1c00626xVzW8M0nHwC; Mon, 27 Jul 2009 12:47:30 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Dave Nelson'" References: <20090727072452.GA10456@elstar.local> <20090727123600.GA10809@elstar.local> Date: Mon, 27 Jul 2009 14:47:17 +0200 Message-ID: <01b201ca0eb8$6918e150$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoOttCY9D6LjhumRBC5QIWNJMYf/wAAUadw In-Reply-To: <20090727123600.GA10809@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 12:47:31 -0000 modularity - remember? the access control model modifies the access control model MIB. NEVER should a transport model modify an access control model MIB. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Monday, July 27, 2009 2:36 PM > To: Dave Nelson > Cc: isms@ietf.org > Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 > > On Mon, Jul 27, 2009 at 02:10:15PM +0200, Dave Nelson wrote: > > Juergen Schoenwaelder writes... > > > > > here are a few comments (posted as a technical contributor) on the > > > RADIUS / VACM document: > > > > I think you have nicely summarized the open technical > issues in the -00 > > draft. > > > > > A: How specific should the document refer to the TSM? > Should we try to > > > phrase things such that things still work in case we > replace TSM > > > with something else? > > > > I think that might be nice to do. My one concern is that > the mechanism of > > this document is dependent upon the tmStateReference. While some > > yet-to-be-written security model might also work with a > secure transport > > model, allowing the VACM extensions in this document to be > used without a > > RADIUS-aware transport model seems to open up a security > issue, or at the > > very least an undefined mode of operation. > > But isn't the RADIUS aware transport doing the manipulation of the > VACM table? Perhaps this is one thing to clarify further - which > component is actually manipulating the VACM table. > > /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 Mon Jul 27 05:52:08 2009 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 17A8B3A6C67 for ; Mon, 27 Jul 2009 05:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyr36rfak9E7 for ; Mon, 27 Jul 2009 05:52: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 3FBE928C189 for ; Mon, 27 Jul 2009 05:52:07 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0505C0040; Mon, 27 Jul 2009 14:52:06 +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 X7To150c9VSy; Mon, 27 Jul 2009 14:52:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55F30C003D; Mon, 27 Jul 2009 14:52:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 24D30B6D851; Mon, 27 Jul 2009 14:52:06 +0200 (CEST) Date: Mon, 27 Jul 2009 14:52:05 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090727125205.GA10921@elstar.local> Mail-Followup-To: David Harrington , 'Dave Nelson' , "isms@ietf.org" References: <20090727072452.GA10456@elstar.local> <20090727123600.GA10809@elstar.local> <01b201ca0eb8$6918e150$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01b201ca0eb8$6918e150$7958404e@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 12:52:08 -0000 On Mon, Jul 27, 2009 at 02:47:17PM +0200, David Harrington wrote: > modularity - remember? > > the access control model modifies the access control model MIB. > NEVER should a transport model modify an access control model MIB. A manager modifies the access control MIB as well. :-) But seriously, the whole idea relies on the RADIUS client embedded in the SNMP implementation to somehow cause a change of the VACM table. I am sure you will explain us later today how this is done in an architectural pure way. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Mon Jul 27 05:54:25 2009 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 B3B073A6802 for ; Mon, 27 Jul 2009 05:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 x4+9yxe9KgAB for ; Mon, 27 Jul 2009 05:54:25 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id E761E3A6A82 for ; Mon, 27 Jul 2009 05:54:24 -0700 (PDT) Received: from OMTA15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id M0jB1c0061Y3wxoAE0uTms; Mon, 27 Jul 2009 12:54:27 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA15.emeryville.ca.mail.comcast.net with comcast id M0uR1c0024H2mdz8b0uSob; Mon, 27 Jul 2009 12:54:26 +0000 From: "Dave Nelson" To: References: <20090727072452.GA10456@elstar.local> <20090727123600.GA10809@elstar.local> Date: Mon, 27 Jul 2009 08:54:27 -0400 Message-ID: <28B607CB37B04687A54A88B201043BFF@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090727123600.GA10809@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcoOttCY3ngWLBe5QJSkSTbwrCqXRAAAas4w Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 12:54:25 -0000 Juergen Schoenwaelder writes ... [ > But isn't the RADIUS aware transport doing the manipulation of the > VACM table? Channeling Dave Harrington: No, that would be a violation of RFC3411 modularity. :-) > Perhaps this is one thing to clarify further - which > component is actually manipulating the VACM table. The transport populates tmStateReference. It's up to the extended VACM code to do something with that information, i.e., populate MIB tables. My concern is related to attempting to use extended VACM, and thus the tmStateRefrence, in the absence of a RADIUS-aware secure transport. The only input to the VACM's ASI that would indicate whether there is or is not a RADIUS-aware transport at work would be the Security Model selector. Do you see another way to accomplish this? From d.b.nelson@comcast.net Mon Jul 27 05:55:38 2009 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 338193A6C2D for ; Mon, 27 Jul 2009 05:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-1.107, 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 N7yfYbGlkrVo for ; Mon, 27 Jul 2009 05:55:37 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 7192B3A6802 for ; Mon, 27 Jul 2009 05:55:37 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id M0ZM1c0051HpZEsA10vf5Q; Mon, 27 Jul 2009 12:55:39 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id M0vd1c0094H2mdz8a0veZx; Mon, 27 Jul 2009 12:55:39 +0000 From: "Dave Nelson" To: "'David Harrington'" , "'Juergen Schoenwaelder'" References: <20090727072452.GA10456@elstar.local> <20090727123600.GA10809@elstar.local> <01b201ca0eb8$6918e150$7958404e@china.huawei.com> Date: Mon, 27 Jul 2009 08:55:39 -0400 Message-ID: <49BA93C1877D4639A97B706A53D83FAA@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <01b201ca0eb8$6918e150$7958404e@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcoOttCY9D6LjhumRBC5QIWNJMYf/wAAUadwAABUL4A= Cc: isms@ietf.org Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 12:55:38 -0000 > modularity - remember? Ha! You did beat me to it, after all. (See my reply where I channel you.) :-) From d.b.nelson@comcast.net Mon Jul 27 05:59:29 2009 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 2E5883A69F5 for ; Mon, 27 Jul 2009 05:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvvWpEnWlQXV for ; Mon, 27 Jul 2009 05:59:28 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 6E7A03A67FC for ; Mon, 27 Jul 2009 05:59:28 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id M0Vt1c0050cQ2SLA70zWxx; Mon, 27 Jul 2009 12:59:30 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id M0zV1c0014H2mdz8W0zVop; Mon, 27 Jul 2009 12:59:30 +0000 From: "Dave Nelson" To: References: <20090727072452.GA10456@elstar.local> <20090727123600.GA10809@elstar.local> <01b201ca0eb8$6918e150$7958404e@china.huawei.com> <20090727125205.GA10921@elstar.local> Date: Mon, 27 Jul 2009 08:59:30 -0400 Message-ID: <7EEAD707EFA04F51B8F0E6F56D28DE13@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090727125205.GA10921@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcoOuQ6XmeD9+66/QZaCkmYpIRZcEgAALGAA Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 12:59:29 -0000 Juergen writes... > But seriously, the whole idea relies on the RADIUS client embedded in > the SNMP implementation to somehow cause a change of the VACM table. The details are in the "somehow cause". I think the flow is something like: RADIUS Client PAM SSH SSHTM tmStateReference extended VACM MIB table From j.schoenwaelder@jacobs-university.de Mon Jul 27 06:31:07 2009 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 1C7183A6C80 for ; Mon, 27 Jul 2009 06:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+Z9IWTdr-oT for ; Mon, 27 Jul 2009 06:31:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 08B8C3A6C78 for ; Mon, 27 Jul 2009 06:31:06 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D52F7C0047; Mon, 27 Jul 2009 15:31:06 +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 MD9ufIdKPoF3; Mon, 27 Jul 2009 15:31:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5FE5CC0044; Mon, 27 Jul 2009 15:31:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 16DA1B6D978; Mon, 27 Jul 2009 15:31:01 +0200 (CEST) Date: Mon, 27 Jul 2009 15:31:00 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090727133100.GA10978@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <20090727072452.GA10456@elstar.local> <20090727123600.GA10809@elstar.local> <28B607CB37B04687A54A88B201043BFF@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28B607CB37B04687A54A88B201043BFF@NEWTON603> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 13:31:07 -0000 On Mon, Jul 27, 2009 at 02:54:27PM +0200, Dave Nelson wrote: > The transport populates tmStateReference. It's up to the extended VACM code > to do something with that information, i.e., populate MIB tables. Except that the ASIs do not pass the tmStateReference to VACM. > My concern is related to attempting to use extended VACM, and thus the > tmStateRefrence, in the absence of a RADIUS-aware secure transport. The > only input to the VACM's ASI that would indicate whether there is or is not > a RADIUS-aware transport at work would be the Security Model selector. Do > you see another way to accomplish this? /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 Mon Jul 27 07:05:04 2009 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 82EA528C1B5 for ; Mon, 27 Jul 2009 07:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 rirxxblkr29k for ; Mon, 27 Jul 2009 07:05:02 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 7CCC528C1AC for ; Mon, 27 Jul 2009 07:05:01 -0700 (PDT) Received: from OMTA23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id M24p1c00A1wfjNsA82527J; Mon, 27 Jul 2009 14:05:02 +0000 Received: from Harrington73653 ([130.129.18.98]) by OMTA23.emeryville.ca.mail.comcast.net with comcast id M27C1c00226xVzW8j27aCT; Mon, 27 Jul 2009 14:07:43 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Dave Nelson'" References: <20090727072452.GA10456@elstar.local><20090727123600.GA10809@elstar.local><28B607CB37B04687A54A88B201043BFF@NEWTON603> <20090727133100.GA10978@elstar.local> Date: Mon, 27 Jul 2009 16:04:31 +0200 Message-ID: <01e001ca0ec3$3cc670d0$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoOvoHvx1AVHsFpQEe0T+sa5w98BQAAWIag In-Reply-To: <20090727133100.GA10978@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 14:05:04 -0000 Hi, This particular binding between the info delivered from RADIUS to VACM uses the "other" path: implementation-dependent magic happens! The RADIUS management attributes are stored in an implementation-dependent manner. The RADIUS management attributes are principal-specific. The principal-specific attributes can be found using securitymodel/securityname/securitylevel. isAccessAllowed already supports these fields. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Monday, July 27, 2009 3:31 PM > To: Dave Nelson > Cc: isms@ietf.org > Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 > > On Mon, Jul 27, 2009 at 02:54:27PM +0200, Dave Nelson wrote: > > > The transport populates tmStateReference. It's up to the > extended VACM code > > to do something with that information, i.e., populate MIB tables. > > Except that the ASIs do not pass the tmStateReference to VACM. > > > My concern is related to attempting to use extended VACM, > and thus the > > tmStateRefrence, in the absence of a RADIUS-aware secure > transport. The > > only input to the VACM's ASI that would indicate whether > there is or is not > > a RADIUS-aware transport at work would be the Security > Model selector. Do > > you see another way to accomplish this? > > /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 d.b.nelson@comcast.net Mon Jul 27 07:23:27 2009 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 C0A6828C211 for ; Mon, 27 Jul 2009 07:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAxamaqaGriv for ; Mon, 27 Jul 2009 07:23:27 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id D49683A6C1F for ; Mon, 27 Jul 2009 07:23:26 -0700 (PDT) Received: from OMTA17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Lzf81c00A1vXlb8582PUux; Mon, 27 Jul 2009 14:23:28 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by OMTA17.westchester.pa.mail.comcast.net with comcast id M2S71c00R2PzLBw3d2S70D; Mon, 27 Jul 2009 14:26:07 +0000 Date: Mon, 27 Jul 2009 14:23:28 +0000 (UTC) From: d.b.nelson@comcast.net To: Juergen Schoenwaelder Message-ID: <470340161.6035241248704608692.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <20090727133100.GA10978@elstar.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_297552_774077841.1248704608690" X-Originating-IP: [64.140.243.171] X-Mailer: Zimbra 5.0.16_GA_2927.RHEL5_64 (ZimbraWebClient - SAF3 (Mac)/5.0.16_GA_2927.RHEL5_64) Cc: isms@ietf.org Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 14:23:27 -0000 ------=_Part_297552_774077841.1248704608690 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Juergen Schoenwaelder writes... > Except that the ASIs do not pass the tmStateReference > to VACM. No. tmStateReference is a "cache" that we invented to get around the issue of having to modify ASIs. :-) ------=_Part_297552_774077841.1248704608690 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Juergen Schoenwaelder writes...

> Except that the ASIs do not pass the tmStateReference 
> to VACM.

No.  tmStateReference is a "cache" that we invented to get around the issue of having to modify ASIs.  :-)

------=_Part_297552_774077841.1248704608690-- From d.b.nelson@comcast.net Mon Jul 27 07:30:28 2009 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 3C08D3A6A41 for ; Mon, 27 Jul 2009 07:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NpOxwalfVMn for ; Mon, 27 Jul 2009 07:30:27 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 2FF1B3A6A27 for ; Mon, 27 Jul 2009 07:30:27 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id M25D1c00717dt5G552WUy3; Mon, 27 Jul 2009 14:30:28 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by OMTA13.westchester.pa.mail.comcast.net with comcast id M2WU1c00B2PzLBw3Z2WUT3; Mon, 27 Jul 2009 14:30:28 +0000 Date: Mon, 27 Jul 2009 14:30:28 +0000 (UTC) From: d.b.nelson@comcast.net To: David Harrington Message-ID: <885984616.6039461248705028174.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <01e001ca0ec3$3cc670d0$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_297759_2051137341.1248705028172" X-Originating-IP: [64.140.243.171] X-Mailer: Zimbra 5.0.16_GA_2927.RHEL5_64 (ZimbraWebClient - SAF3 (Mac)/5.0.16_GA_2927.RHEL5_64) Cc: isms@ietf.org Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 14:30:28 -0000 ------=_Part_297759_2051137341.1248705028172 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit David Harrington writes... > The RADIUS management attributes are principal-specific. > The principal-specific attributes can be found using > securitymodel/securityname/securitylevel. > isAccessAllowed already supports these fields. Yes. I think another way to frame Juergen's original comment is why the (augmented) VACM tables should useTSM in the securityModel field. My answer was that it need not be restricted to TSM, but it would need to be restricted to some security model that was "dependent" on a RADIUS-aware transport model. Today, that means TSM. ------=_Part_297759_2051137341.1248705028172 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
David Harrington writes...

> The RADIUS management attributes are principal-specific.
> The principal-specific attributes can be found using
> securitymodel/securityname/securitylevel.
> isAccessAllowed already supports these fields.

Yes.

I think another way to frame Juergen's original comment is why the (augmented) VACM tables should useTSM in the securityModel field.

My answer was that it need not be restricted to TSM, but it would need to be restricted to some security model that was "dependent" on a RADIUS-aware transport model.  Today, that means TSM.

------=_Part_297759_2051137341.1248705028172-- From j.schoenwaelder@jacobs-university.de Mon Jul 27 07:36:57 2009 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 021BC28C178 for ; Mon, 27 Jul 2009 07:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZMLevtBxCsL for ; Mon, 27 Jul 2009 07:36: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 00EDA28C153 for ; Mon, 27 Jul 2009 07:36:56 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED119C0045; Mon, 27 Jul 2009 16:36:56 +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 fA720WVCZMxg; Mon, 27 Jul 2009 16:36:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F0EFC0043; Mon, 27 Jul 2009 16:36:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DFDF9B6DB33; Mon, 27 Jul 2009 16:36:55 +0200 (CEST) Date: Mon, 27 Jul 2009 16:36:55 +0200 From: Juergen Schoenwaelder To: "d.b.nelson@comcast.net" Message-ID: <20090727143655.GA11127@elstar.local> Mail-Followup-To: "d.b.nelson@comcast.net" , "isms@ietf.org" References: <20090727133100.GA10978@elstar.local> <470340161.6035241248704608692.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470340161.6035241248704608692.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 14:36:57 -0000 On Mon, Jul 27, 2009 at 04:23:28PM +0200, d.b.nelson@comcast.net wrote: > Juergen Schoenwaelder writes... > > > Except that the ASIs do not pass the tmStateReference > > to VACM. > > No. tmStateReference is a "cache" that we invented to get around > the issue of having to modify ASIs. :-) Not really. See RFC 5590: [...] A tmStateReference is passed as an extra parameter in the ASIs between the Transport Subsystem and the Message Processing and Security Subsystems in order to identify the relevant cache. We pass the tmStateReference but no the detailed information the tmStateReference points to. See also sections 6 of RFC 5590 for all the details of the changes of the ASIs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Mon Jul 27 07:47:32 2009 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 9A9FD3A6B22 for ; Mon, 27 Jul 2009 07:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV82F3hLw8Nw for ; Mon, 27 Jul 2009 07:47:31 -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 CD5693A68EF for ; Mon, 27 Jul 2009 07:47:30 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA11.westchester.pa.mail.comcast.net with comcast id M15D1c03a1HzFnQ5B2nYLF; Mon, 27 Jul 2009 14:47:32 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by OMTA14.westchester.pa.mail.comcast.net with comcast id M2nY1c00G2PzLBw3a2nYao; Mon, 27 Jul 2009 14:47:32 +0000 Date: Mon, 27 Jul 2009 14:47:32 +0000 (UTC) From: d.b.nelson@comcast.net To: isms@ietf.org Message-ID: <2040424970.6048621248706052823.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <20090727143655.GA11127@elstar.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_298188_2034400918.1248706052821" X-Originating-IP: [64.140.243.171] X-Mailer: Zimbra 5.0.16_GA_2927.RHEL5_64 (ZimbraWebClient - SAF3 (Mac)/5.0.16_GA_2927.RHEL5_64) Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 14:47:32 -0000 ------=_Part_298188_2034400918.1248706052821 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Juergen Schoenwaelder writes... > Not really. See RFC 5590: > > [...] A > tmStateReference is passed as an extra parameter in the ASIs between > the Transport Subsystem and the Message Processing and Security > Subsystems in order to identify the relevant cache. > > We pass the tmStateReference but no the detailed information the > tmStateReference points to. See also sections 6 of RFC 5590 for all > the details of the changes of the ASIs. Well, if we follow that precedent, and we want to avoid modifying the ASI of the access control model, we'll need to find another place to put the "magic". Since the tmStateReference pointer is only used in a "management" channel rather than a "message flow" channel, maybe it doesn't need to affect VACM's ASI, anyway. Any way you parse it, however, adding new functionality without modifying APIs (yes, I meant API, as in concrete implementation interface) is difficult. ------=_Part_298188_2034400918.1248706052821 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Arial; font-size: 12pt; color: #000000'>Juergen S= choenwaelder writes...

> Not really. See RFC 5590:>
>  [...] A
> tmStateReference is passed as an= extra parameter in the ASIs between
>  the Transport Subsystem = and the Message Processing and Security
>  Subsystems in order t= o identify the relevant cache.
>
> We pass the tmStateReferenc= e but no the detailed information the
> tmStateReference points to. S= ee also sections 6 of RFC 5590 for all
> the details of the changes o= f the ASIs.

Well, if we follow that precedent, and= we want to avoid modifying the ASI of the access control model, we'll need= to find another place to put the "magic".  Since the tmStateReference= pointer is only used in a "management" channel rather than a "message flow= " channel, maybe it doesn't need to affect VACM's ASI, anyway.
Any way you parse it, however, adding new functionality withou= t modifying APIs (yes, I meant API, as in concrete implementation interface= ) is difficult.

------=_Part_298188_2034400918.1248706052821-- From ietfdbh@comcast.net Mon Jul 27 08:10:37 2009 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 4A6BB3A6BF8 for ; Mon, 27 Jul 2009 08:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6QKOFNvlh1R for ; Mon, 27 Jul 2009 08:10:35 -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 771E03A6C41 for ; Mon, 27 Jul 2009 08:10:35 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id M00g1c0050mlR8UAF3AXWU; Mon, 27 Jul 2009 15:10:31 +0000 Received: from Harrington73653 ([130.129.18.98]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id M3AF1c00K26xVzW8X3AJbX; Mon, 27 Jul 2009 15:10:29 +0000 From: "David Harrington" To: References: <01e001ca0ec3$3cc670d0$7958404e@china.huawei.com> <885984616.6039461248705028174.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> Date: Mon, 27 Jul 2009 17:10:20 +0200 Message-ID: <020601ca0ecc$63f24720$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0207_01CA0EDD.277B1720" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoOxsl5K9Q7w38PS+KU3pSKPPLLgAAAQWug In-Reply-To: <885984616.6039461248705028174.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 15:10:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0207_01CA0EDD.277B1720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There would be no RADIUS attributes available if the transport model doesn't support RADIUS. Of course, that works on incoming traffic. For notifications access control is done before authentication in SNMP, so there would be no RADIUS attributes available (at least for the first time). I assume notifications might use pre-configured access controls. dbh _____ From: d.b.nelson@comcast.net [mailto:d.b.nelson@comcast.net] Sent: Monday, July 27, 2009 4:30 PM To: David Harrington Cc: isms@ietf.org; Juergen Schoenwaelder Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 David Harrington writes... > The RADIUS management attributes are principal-specific. > The principal-specific attributes can be found using > securitymodel/securityname/securitylevel. > isAccessAllowed already supports these fields. Yes. I think another way to frame Juergen's original comment is why the (augmented) VACM tables should useTSM in the securityModel field. My answer was that it need not be restricted to TSM, but it would need to be restricted to some security model that was "dependent" on a RADIUS-aware transport model. Today, that means TSM. ------=_NextPart_000_0207_01CA0EDD.277B1720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
There would be no RADIUS attributes available = if the=20 transport model doesn't support RADIUS.
Of course, that works on incoming=20 traffic.
 
For notifications access control is done = before=20 authentication in SNMP, so there would be no RADIUS attributes available = (at=20 least for the first time).
I assume notifications might use pre-configured = access=20 controls.
 
dbh

From: d.b.nelson@comcast.net=20 [mailto:d.b.nelson@comcast.net]
Sent: Monday, July 27, 2009 = 4:30=20 PM
To: David Harrington
Cc: isms@ietf.org; Juergen = Schoenwaelder
Subject: Re: [Isms] comments on=20 draft-nelson-isms-extended-vacm-00

David=20 Harrington writes...

> The RADIUS management attributes are = principal-specific.
> The=20 principal-specific attributes can be found using
>=20 securitymodel/securityname/securitylevel.
> isAccessAllowed = already=20 supports these fields.

Yes.

I think another way to frame Juergen's original comment is why = the=20 (augmented) VACM tables should useTSM in the securityModel = field.

My answer was that it need not be restricted to TSM, but it would = need to=20 be restricted to some security model that was "dependent" on a = RADIUS-aware=20 transport model.  Today, that means=20 TSM.

------=_NextPart_000_0207_01CA0EDD.277B1720-- From d.b.nelson@comcast.net Mon Jul 27 08:24:15 2009 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 DEA5C28C185 for ; Mon, 27 Jul 2009 08:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 ZMSChwdraViu for ; Mon, 27 Jul 2009 08:24:15 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 8621728C273 for ; Mon, 27 Jul 2009 08:23:56 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA08.westchester.pa.mail.comcast.net with comcast id M3BE1c0430bG4ec583PyYs; Mon, 27 Jul 2009 15:23:58 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by OMTA03.westchester.pa.mail.comcast.net with comcast id M3Py1c00F2PzLBw3P3PyKR; Mon, 27 Jul 2009 15:23:58 +0000 Date: Mon, 27 Jul 2009 15:23:58 +0000 (UTC) From: d.b.nelson@comcast.net To: isms@ietf.org Message-ID: <977816900.6071541248708238234.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <020601ca0ecc$63f24720$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.140.243.171] X-Mailer: Zimbra 5.0.16_GA_2927.RHEL5_64 (ZimbraWebClient - SAF3 (Mac)/5.0.16_GA_2927.RHEL5_64) Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 15:24:16 -0000 David Harrington writes... > There would be no RADIUS attributes available if the transport > model doesn't support RADIUS. Right. It's an open question whether that always works as expected, but if the table entries make intelligent use of the securityModel field, this should be doable. > Of course, that works on incoming traffic. Right. > For notifications access control is done before > authentication in SNMP... Indulging in a "rat hole" side-discussion -- applying authorization before performing authentication seems fundamentally broken to me. I know that we're not chartered to go down that "rat-hole", but I can't resist the observation in passing. > ...so there would be no RADIUS attributes available > (at least for the first time). Right. > I assume notifications might use pre-configured > access controls. Yeah, I guess so. Probably merits further thought. From j.schoenwaelder@jacobs-university.de Mon Jul 27 08:27:48 2009 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 BCFCA3A6B54 for ; Mon, 27 Jul 2009 08:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AifVf5Z6A1K1 for ; Mon, 27 Jul 2009 08:27: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 113613A6B1F for ; Mon, 27 Jul 2009 08:27:47 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12FC0C004A; Mon, 27 Jul 2009 17:27:48 +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 OIgtlvA35PMM; Mon, 27 Jul 2009 17:27: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 8361EC0043; Mon, 27 Jul 2009 17:27:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 38CB7B6DCED; Mon, 27 Jul 2009 17:27:17 +0200 (CEST) Date: Mon, 27 Jul 2009 17:27:17 +0200 From: Juergen Schoenwaelder To: "d.b.nelson@comcast.net" Message-ID: <20090727152717.GC11154@elstar.local> Mail-Followup-To: "d.b.nelson@comcast.net" , "isms@ietf.org" References: <20090727143655.GA11127@elstar.local> <2040424970.6048621248706052823.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2040424970.6048621248706052823.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 15:27:48 -0000 On Mon, Jul 27, 2009 at 04:47:32PM +0200, d.b.nelson@comcast.net wrote: > Well, if we follow that precedent, and we want to avoid modifying > the ASI of the access control model, we'll need to find another > place to put the "magic". Since the tmStateReference pointer is > only used in a "management" channel rather than a "message flow" > channel, maybe it doesn't need to affect VACM's ASI, anyway. > > Any way you parse it, however, adding new functionality without > modifying APIs (yes, I meant API, as in concrete implementation > interface) is difficult. I think Randy Presuhn's model was that the RADIUS client acts pretty much like an "embedded" SNMP manager doing a local set to modify the VACM table. At least this one model to look at this. Another is the black box magic (like someone /something modifying the SNMP agent's configuration file is just magic). The WG needs to figure out to which level of detail we want to / have to specify this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Mon Jul 27 08:35:03 2009 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 65FF63A6B54 for ; Mon, 27 Jul 2009 08:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 2ROOiFpIgxsn for ; Mon, 27 Jul 2009 08:35:02 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 7E59D3A6B15 for ; Mon, 27 Jul 2009 08:35:02 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA09.westchester.pa.mail.comcast.net with comcast id M0EN1c0050mv7h0593b4zQ; Mon, 27 Jul 2009 15:35:04 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by OMTA11.westchester.pa.mail.comcast.net with comcast id M3b41c0022PzLBw3X3b489; Mon, 27 Jul 2009 15:35:04 +0000 Date: Mon, 27 Jul 2009 15:35:03 +0000 (UTC) From: d.b.nelson@comcast.net To: isms@ietf.org Message-ID: <1928093991.6085651248708903331.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <20090727152717.GC11154@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.140.243.171] X-Mailer: Zimbra 5.0.16_GA_2927.RHEL5_64 (ZimbraWebClient - SAF3 (Mac)/5.0.16_GA_2927.RHEL5_64) Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00 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, 27 Jul 2009 15:35:03 -0000 Juergen Schoenwaelder writes... > I think Randy Presuhn's model was that the RADIUS > client acts pretty much like an "embedded" SNMP > manager doing a local set to modify the VACM table. I think that's the right generic model, except that it isn't the RADIUS client that does this work. (Another modularity discussion.) The RADIUS client is typically isolated from the SNMP engine by PAM and the SSH server. So, something external to the RADIUS client, that is triggered by the actions of the SSH server or the SSH Transport Model, will take the information from the tnStateReference and affect the VACM tables. From jhutz@cmu.edu Mon Jul 27 11:52:23 2009 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 528633A6CFE for ; Mon, 27 Jul 2009 11:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 YL91yOr67H-P for ; Mon, 27 Jul 2009 11:52:22 -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 77D7A3A6CF6 for ; Mon, 27 Jul 2009 11:52:22 -0700 (PDT) Received: from [10.0.0.3] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n6RIqKkE024679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 14:52:21 -0400 (EDT) Date: Mon, 27 Jul 2009 14:49:15 -0400 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , isms@ietf.org Message-ID: <9E45C460CFB7A443784BCFFB@atlantis.pc.cs.cmu.edu> In-Reply-To: <8130_1248679769_n6R7TS1V009686_20090727072924.GB10456@elstar.local> References: <8130_1248679769_n6R7TS1V009686_20090727072924.GB10456@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 Subject: Re: [Isms] snmp: URI scheme transport extensions 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, 27 Jul 2009 18:52:23 -0000 --On Monday, July 27, 2009 09:29:24 AM +0200 Juergen Schoenwaelder wrote: > Hi, > > while doing some SNMP during vacation, I did run into an issue with > the snmp: URI scheme defined in RFC 4088. When RFC 4088 was created, > we excluded transport information from SNMP service URIs. Now, with > the presence of much more transports, it would be really nice to have > the URI format supporting transport parameters, e.g. > > snmp://tester5@example.com:5161;transport=ssh > ^^^^^^^^^^^^^^ > new > > I would be willing to work on this because I need it for some tools; > perhaps this work should be hosted at OPSAWG? I obviously forgot to > bring this up while ISMS was rechartering. But the transports we have > to provision extend ISMS transports anyway so OPSAWG might be a good > choice. Anyway, at this point in time, I just bring this up to see > whether there is interest to work this out or it is just me. The traditional way to handle this seems to be to specify new URI schemes, like snmps (for tls) and snmpssh (for ssh). From jhutz@cmu.edu Mon Jul 27 15:03:53 2009 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 D4E823A69D5 for ; Mon, 27 Jul 2009 15:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 XIUcKSMVq99Y for ; Mon, 27 Jul 2009 15:03:52 -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 968DF3A685C for ; Mon, 27 Jul 2009 15:03:36 -0700 (PDT) Received: from [10.0.0.3] (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 n6RM3WOu002843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 18:03:33 -0400 (EDT) Date: Mon, 27 Jul 2009 18:03:32 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , David Harrington Message-ID: In-Reply-To: <8107_1248685985_n6R9D3gA023009_sdk51u5w17.fsf@wes.hardakers.net> References: <20090727072924.GB10456@elstar.local> <015b01ca0e96$e9f17840$7958404e@china.huawei.com> <8107_1248685985_n6R9D3gA023009_sdk51u5w17.fsf@wes.hardakers.net> 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] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 22:03:54 -0000 --On Monday, July 27, 2009 02:12:52 AM -0700 Wes Hardaker wrote: >>>>>> On Mon, 27 Jul 2009 10:47:36 +0200, "David Harrington" >>>>>> said: > > DH> Why do we need to specify the transport in the URI? We are already > DH> specifying port 5161, which is snmp/ssh. > > You're presuming TCP there. You're also presuming a standard port is > being used and you can determine from that what is running on it, which > isn't a safe assumption. Right. There are any number of reasons why I might want to run this on a non-standard port, or run something else -- even something SNMP related -- on port 5161. -- Jeff From jhutz@cmu.edu Mon Jul 27 15:09:04 2009 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 35A0A3A67B1 for ; Mon, 27 Jul 2009 15:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_93=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 4OXibGuLHhYO for ; Mon, 27 Jul 2009 15:09:03 -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 E96753A69CF for ; Mon, 27 Jul 2009 15:08:49 -0700 (PDT) Received: from [10.0.0.3] (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 n6RM8ln7003017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 18:08:47 -0400 (EDT) Date: Mon, 27 Jul 2009 18:08:47 -0400 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , Wes Hardaker Message-ID: <9CCC50259830C1C1C5837884@[10.0.0.3]> In-Reply-To: <18922_1248687129_n6R9W8h3025686_20090727093204.GA10532@elstar.local> References: <20090727072924.GB10456@elstar.local> <18922_1248687129_n6R9W8h3025686_20090727093204.GA10532@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] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 22:09:04 -0000 --On Monday, July 27, 2009 11:32:04 AM +0200 Juergen Schoenwaelder wrote: > On Mon, Jul 27, 2009 at 10:12:46AM +0200, Wes Hardaker wrote: >> >>>>> On Mon, 27 Jul 2009 09:29:24 +0200, Juergen Schoenwaelder >> >>>>> said: >> >> JS> snmp://tester5@example.com:5161;transport=ssh >> JS> ^^^^^^^^^^^^^^ >> JS> new >> >> I think you're still missing an important element, namely the >> securityModel. No where above does it specify TSM anywhere so I don't >> think it's complete as is. > > Yes, I agree. I was thinking about having a default for all this as we > do now - you get SNMPv3/USM/UDP. If you specify transport=ssh, you get > securitymodel=tsm as default - I did not spell this out. I still don't think transport= is the right approach. In your URL example, is 'tester' intended to be a securityName or part of the SSH transport address? I suspect the answer is that for UDP/USM it is a securityName, but for TCP/SSM/TSM it is part of the SSH transport address, indicating the SSH username to use. That is, the syntax depends on the transport being used. The right way to have differing syntax is to use different URI schemes. UDP, TCP, SSH, TLS, DTLS/UDP, and DTLS/SCTP should probably all have different URI schemes. Once you've done that, different schemes can imply different defaults, so the default security model for SSH, TLS, DTLS/UDP, and DtLS/SCTP is TSM, while the default security model for UDP and TCP is USM. -- Jeff From j.schoenwaelder@jacobs-university.de Mon Jul 27 15:56:27 2009 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 98E823A6BCC for ; Mon, 27 Jul 2009 15:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIc6j9oHlUlQ for ; Mon, 27 Jul 2009 15:56:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6AD6C3A67B3 for ; Mon, 27 Jul 2009 15:56:26 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7CF4C001D; Tue, 28 Jul 2009 00:56:26 +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 YxIuIhypkEgi; Tue, 28 Jul 2009 00:56:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EBB2C0007; Tue, 28 Jul 2009 00:56:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 58D3DB6E0BD; Tue, 28 Jul 2009 00:56:25 +0200 (CEST) Date: Tue, 28 Jul 2009 00:56:25 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20090727225625.GA11323@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , Wes Hardaker , "isms@ietf.org" References: <20090727072924.GB10456@elstar.local> <18922_1248687129_n6R9W8h3025686_20090727093204.GA10532@elstar.local> <9CCC50259830C1C1C5837884@[10.0.0.3]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9CCC50259830C1C1C5837884@[10.0.0.3]> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Ismssnmp: URI scheme transport extensions 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, 27 Jul 2009 22:56:27 -0000 On Tue, Jul 28, 2009 at 12:08:47AM +0200, Jeffrey Hutzelman wrote: > I still don't think transport= is the right approach. In your URL example, > is 'tester' intended to be a securityName or part of the SSH transport > address? I suspect the answer is that for UDP/USM it is a securityName, > but for TCP/SSM/TSM it is part of the SSH transport address, indicating the > SSH username to use. That is, the syntax depends on the transport being > used. In USM, you specify a user name - since in both cases (USM and SSH) the default transform is an identity transform, the difference between a user name and a securityName is subtle. > The right way to have differing syntax is to use different URI schemes. > UDP, TCP, SSH, TLS, DTLS/UDP, and DTLS/SCTP should probably all have > different URI schemes. > > Once you've done that, different schemes can imply different defaults, so > the default security model for SSH, TLS, DTLS/UDP, and DtLS/SCTP is TSM, > while the default security model for UDP and TCP is USM. I note this is legal: sip:alice:secretword@atlanta.com;transport=tcp They obviously do not have a siptcp: scheme - but they do have sips: (while they deprecated the sip:;transport=tls version but then I note that sips actually implies TLS over the complete E2E path and not just one hop). I guess we need advice from URI experts. There was probably a good reason why we ignored all this when we did RFC 4088... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Wed Jul 29 06:34:10 2009 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 7C4393A709B for ; Wed, 29 Jul 2009 06:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=-0.757, 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 Lwc4g1cjgeUH for ; Wed, 29 Jul 2009 06:34:09 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 60DCD3A6912 for ; Wed, 29 Jul 2009 06:33:50 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA08.westchester.pa.mail.comcast.net with comcast id MndF1c00C16LCl058pZslT; Wed, 29 Jul 2009 13:33:52 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA06.westchester.pa.mail.comcast.net with comcast id MpZs1c0064H2mdz3SpZsM3; Wed, 29 Jul 2009 13:33:52 +0000 From: "Dave Nelson" To: Date: Wed, 29 Jul 2009 09:34:00 -0400 Message-ID: <62F0B443BD34421EAC9F75018C722558@NEWTON603> 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.5579 Thread-Index: AcoQUTsX/nq4UqdYReukHzu+lljIHw== Subject: [Isms] Next steps for Extended VACM? 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, 29 Jul 2009 13:34:10 -0000 I wanted to parrot back some thoughts I took away from Monday's ISMS WG meeting on the direction for the RADIUS-aware Extended VACM draft, to see if others remember the discussion the same way. I also have some questions. (1) We don't want to specify _how_ the NAS moves the access policy information from the RADIUS client to the Extended VACM "manager", just that it predictably and reliably do so, and that it pay heed to session timeout limits, session disconnects, multiple sessions using the same policy, and so forth. Is that about right? (2) We don't want to suggest using the tmStateReference, even though this seems a likely container which already has similarly TM-session-scoped state information. (3) We don't want the Extended VACM "manager" to modify the existing VACM securityName-to-group MIB table, but rather to maintain a new Extended VACM securityName-to-group MIB table. This new table will look a lot like the old table, but will have a couple extra columns, one for "can RADIUS change this" and one that's an index of the corresponding row in the existing table. There are parts of this that I don't understand. Should the new table contain all entries from the old table, but with the "RADIUS can't change this" flag set? Internally, what should VACM do in following its EOP? Look only at the new table, with the old table being some form of "backing store"? Otherwise we need some sort of precedence relation between the two tables, and I didn't hear that being advocated. Do we need something to enable the VACM "extended mode"? Would it be useful to count the number to times that the VACM "manger" attempted to add a new row but couldn't because of a name collision? From ietfdbh@comcast.net Wed Jul 29 08:27:57 2009 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 4359A3A696F for ; Wed, 29 Jul 2009 08:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.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 9AINNmnj0QyC for ; Wed, 29 Jul 2009 08:27:56 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id 190753A6814 for ; Wed, 29 Jul 2009 08:27:56 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id Mpoa1c0060S2fkCAErTyp7; Wed, 29 Jul 2009 15:27:58 +0000 Received: from Harrington73653 ([78.64.88.202]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id MrTl1c0034Mwani8VrTpqQ; Wed, 29 Jul 2009 15:27:56 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <62F0B443BD34421EAC9F75018C722558@NEWTON603> Date: Wed, 29 Jul 2009 17:27:35 +0200 Message-ID: <055c01ca1061$200f0d90$7958404e@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoQUTsX/nq4UqdYReukHzu+lljIHwACxoVw In-Reply-To: <62F0B443BD34421EAC9F75018C722558@NEWTON603> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] Next steps for Extended VACM? 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, 29 Jul 2009 15:27:57 -0000 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Wednesday, July 29, 2009 3:34 PM > To: isms@ietf.org > Subject: [Isms] Next steps for Extended VACM? > > I wanted to parrot back some thoughts I took away from > Monday's ISMS WG > meeting on the direction for the RADIUS-aware Extended VACM > draft, to see if > others remember the discussion the same way. I also have > some questions. > > (1) We don't want to specify _how_ the NAS moves the access policy > information from the RADIUS client to the Extended VACM > "manager", just that > it predictably and reliably do so, and that it pay heed to > session timeout > limits, session disconnects, multiple sessions using the same > policy, and so > forth. Is that about right? We do not want to see how. We might want to specify what it must heed, and what behavior SHOULD be followed. I think this might be addressed in some EOP that precede the VACM EOM > > (2) We don't want to suggest using the tmStateReference, even > though this > seems a likely container which already has similarly > TM-session-scoped state > information. > The tmStateReference does not get passed to applications or ACM subsystems, and we do not want to rewrite the ASIs to do so. It does not seem to make much sense to explicitly store the info using a field in tmStateReference if the EOP cannot look at that field because the tmSateReference isn't passed to the ACM subsystem. >From RFC 5590: The tmState might contain both long-term and short-term information. The session information typically remains valid for the duration of the transport session, might be used for several messages, and might be stored in a local configuration datastore. It would seem appropriate to store the RADIUS attributes in the local datastore associated with a session. The RADIUS-handling EOP will need access to RADIUS attributes at a point where it has no access to tmStateReference. > (3) We don't want the Extended VACM "manager" to modify the > existing VACM > securityName-to-group MIB table, but rather to maintain a new > Extended VACM > securityName-to-group MIB table. This new table will look a > lot like the > old table, but will have a couple extra columns, one for "can > RADIUS change > this" and one that's an index of the corresponding row in the existing > table. > > There are parts of this that I don't understand. Should the new table > contain all entries from the old table, but with the "RADIUS > can't change > this" flag set? I think we want a MIB module to supplement the existing VACM MIB. The supplementary table is indexed using the same index as the VACM table. Since we are developing an extension to VACM, it can add rows and delete rows from the existing VACM table. We are developing RADIUS-aware VACM; I will refer to this extension in my email as RACM. All rows RACM creates/deletes MUST have an extra column that specifies it was created by RACM (and which indicates that the row might be deleted by RADIUS-aware VACM) and contains additional parameters, such as lifetime. The RACM doc should specify the EOP for creating a row. If a row exists for the user that was not created by the RACM, then RACM cannot create it, and should increment an error counter. This will probably be a RACM-specific error, and should be defined in the RACM-MIB. I believe the creation process should create the row in the same table that VACM currently uses. After RACM creates the row, normal VACM EOP processing is done, with no required changes. The RACM doc should specifiy the EOP for deleting a row. It does not try to restore previous row contents; it just deletes the row it created earlier. The rows should be deleted under certain conditions: 1) A SET changes RowStatus to delete 2) the session expires 3) a re-auth occurs occurs, forcing the deletion of the current row with the same index, and replacement by creation of a new row with the same index. All of this EOP happens outside the scope of VACM. I didn't check whether there are any conditions in which VACM EOP adds or deletes a row dynamically. I don't think there is. But if there is, then RACM may need to delete the corresponding extra columns. > > Internally, what should VACM do in following its EOP? Look > only at the new > table, with the old table being some form of "backing store"? > Otherwise we > need some sort of precedence relation between the two tables, > and I didn't > hear that being advocated. > > Do we need something to enable the VACM "extended mode"? It would probably be good to allow the operator to enable/disable the extension. If the switch is set to disable, then any exsting RACM entries should be deleted. The SecCons should discuss implications of this. > > Would it be useful to count the number to times that the VACM "manger" > attempted to add a new row but couldn't because of a name collision? discussed aove. > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From j.schoenwaelder@jacobs-university.de Wed Jul 29 10:10:40 2009 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 A01313A6ACF for ; Wed, 29 Jul 2009 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pooU2hw71of2 for ; Wed, 29 Jul 2009 10:10: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 B775C3A6A94 for ; Wed, 29 Jul 2009 10:10:38 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01238C00A7; Wed, 29 Jul 2009 19:10:40 +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 EgeIAbL5aa9b; Wed, 29 Jul 2009 19:10:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9446EC001A; Wed, 29 Jul 2009 19:10:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 92D01B70E40; Wed, 29 Jul 2009 19:10:38 +0200 (CEST) Date: Wed, 29 Jul 2009 19:10:38 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090729171038.GH14445@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <62F0B443BD34421EAC9F75018C722558@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62F0B443BD34421EAC9F75018C722558@NEWTON603> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Next steps for Extended VACM? 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, 29 Jul 2009 17:10:40 -0000 On Wed, Jul 29, 2009 at 03:34:00PM +0200, Dave Nelson wrote: > I wanted to parrot back some thoughts I took away from Monday's ISMS WG > meeting on the direction for the RADIUS-aware Extended VACM draft, to see if > others remember the discussion the same way. I also have some questions. > > (1) We don't want to specify _how_ the NAS moves the access policy > information from the RADIUS client to the Extended VACM "manager", just that > it predictably and reliably do so, and that it pay heed to session timeout > limits, session disconnects, multiple sessions using the same policy, and so > forth. Is that about right? I think this is fair statement. > (2) We don't want to suggest using the tmStateReference, even though this > seems a likely container which already has similarly TM-session-scoped state > information. Storing something in the tmStateReference has no value since it is never passed to the ACM and it is not needed since we do (1). > (3) We don't want the Extended VACM "manager" to modify the existing VACM > securityName-to-group MIB table, but rather to maintain a new Extended VACM > securityName-to-group MIB table. This new table will look a lot like the > old table, but will have a couple extra columns, one for "can RADIUS change > this" and one that's an index of the corresponding row in the existing > table. Not quite right. The VACM security to group mapping table remains the only table that does security to group mappings. A device supporting the radius extension will provide an augmenting table indicating which entries in the VACM security to group mapping table belong to the RADIUS client - and if needed providing any additional information we need to make visible. > Would it be useful to count the number to times that the VACM "manger" > attempted to add a new row but couldn't because of a name collision? It is common practice to have counters when the processing in elements of procedures stops due to such error situation. So I guess the answer is yes. /js (writing as technical contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Wed Jul 29 10:26:17 2009 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 3BC4B3A6A0B for ; Wed, 29 Jul 2009 10:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.576, 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 tlOYX-CLPCQI for ; Wed, 29 Jul 2009 10:26:16 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 1C0673A6A18 for ; Wed, 29 Jul 2009 10:26:15 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA04.westchester.pa.mail.comcast.net with comcast id MnUK1c0090bG4ec54tSJuP; Wed, 29 Jul 2009 17:26:18 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA03.westchester.pa.mail.comcast.net with comcast id MtSH1c00B4H2mdz3PtSJLP; Wed, 29 Jul 2009 17:26:18 +0000 From: "Dave Nelson" To: References: <62F0B443BD34421EAC9F75018C722558@NEWTON603> <20090729171038.GH14445@elstar.local> Date: Wed, 29 Jul 2009 13:26:26 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090729171038.GH14445@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcoQb4J7U8Uj9C/IStKasXbk6a80OQAAMBxg Subject: Re: [Isms] Next steps for Extended VACM? 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, 29 Jul 2009 17:26:17 -0000 Juergen Schoenwaelder writes... > > (2) We don't want to suggest using the tmStateReference, even though > > this seems a likely container which already has similarly TM-session- > > scoped state information. > > Storing something in the tmStateReference has no value since it is > never passed to the ACM and it is not needed since we do (1). Well, since (1) -- elided in this reply -- is completely unspecified, it *could* be implemented by passing a pointer to tmStateReference. How we pass information is opaque to the document, so one pointer is just as good as another, right? I'm going to think about whether it might be useful for the Extended VACM "manager" to have access to the tmStateRefeence for other reasons. That fact that it isn't passed to VACM in an ASI doesn't, IMHO, prevent it from being passed in an implementation-dependent fashion. After all, a "sneak path" is a "sneak path". :-) > > (3) We don't want the Extended VACM "manager" to modify the existing > > VACM securityName-to-group MIB table, but rather to maintain a new > > Extended VACM securityName-to-group MIB table. This new table will > > look a lot like the old table, but will have a couple extra columns, > > one for "can RADIUS change this" and one that's an index of the > > corresponding row in the existing table. > > Not quite right. The VACM security to group mapping table remains the > only table that does security to group mappings. A device supporting > the radius extension will provide an augmenting table indicating which > entries in the VACM security to group mapping table belong to the > RADIUS client - and if needed providing any additional information we > need to make visible. Ah, I see. An augmenting table, without use of the AUGMENTS keyword, using a common indexing scheme to tie back to the original table. Gotcha. I'm sure a first draft of the SMI will bring out more specific comments... From d.b.nelson@comcast.net Wed Jul 29 10:45:17 2009 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 9A0BC3A6843 for ; Wed, 29 Jul 2009 10:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.494, 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 d+PE1FnOLfJJ for ; Wed, 29 Jul 2009 10:45:16 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 8EA023A6774 for ; Wed, 29 Jul 2009 10:45:16 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with comcast id Mnvx1c0010mv7h05AtlKjQ; Wed, 29 Jul 2009 17:45:19 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA11.westchester.pa.mail.comcast.net with comcast id MtlJ1c00W4H2mdz3XtlJh0; Wed, 29 Jul 2009 17:45:19 +0000 From: "Dave Nelson" To: References: <62F0B443BD34421EAC9F75018C722558@NEWTON603> <055c01ca1061$200f0d90$7958404e@china.huawei.com> Date: Wed, 29 Jul 2009 13:45:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <055c01ca1061$200f0d90$7958404e@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcoQUTsX/nq4UqdYReukHzu+lljIHwACxoVwAAWW91A= Subject: Re: [Isms] Next steps for Extended VACM? 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, 29 Jul 2009 17:45:17 -0000 David Harrington writes... > We do not want to see how. > We might want to specify what it must heed, and what behavior > SHOULD be followed. I think this might be addressed in some > EOP that precede the VACM EOP. SHOULD or MUST? Since is this is an SNMP document, I think that specifying Elements of Procedure, and generally structuring is as much like other SNMP documents as the authors may be capable of is a reasonable suggestion. > It would seem appropriate to store the RADIUS attributes in the local > datastore associated with a session. And exactly how does the "local data-store associated with the session" differ from "tmStateReference"? A rose by any other name... > The RADIUS-handling EOP will need access to RADIUS attributes at a > point where it has no access to tmStateReference. Unless, of course, the implementation-dependent information passing method is simply to pass a pointer to the tmStateReference. :-) > We are developing RADIUS-aware VACM; I will refer to this extension in > my email as RACM. Hmmm. I'm not too fond of that nomenclature, so I won't adopt it. > The RACM doc should specify the EOP for creating a row. If a row > exists for the user that was not created by the RACM, then RACM cannot > create it, and should increment an error counter. This will probably > be a RACM-specific error, and should be defined in the RACM-MIB. I > believe the creation process should create the row in the same table > that VACM currently uses. After RACM creates the row, normal VACM EOP > processing is done, with no required changes. Right. > The RACM doc should specifiy the EOP for deleting a row. It does not > try to restore previous row contents; it just deletes the row it > created earlier. The rows should be deleted under certain conditions: > 1) A SET changes RowStatus to delete > 2) the session expires > 3) a re-auth occurs occurs, forcing the deletion of the current row > with the same index, and replacement by creation of a new row with the > same index. Sounds like a good start. > All of this EOP happens outside the scope of VACM. It happens in what I've been calling the VACM Extension or Extended VACM "manager" (in reference to its role in "managing" the VACM MIB table(s). I think we agree on where all this happens, but perhaps not yet on the best name for it. > I didn't check whether there are any conditions in which VACM EOP adds > or deletes a row dynamically. I don't think there is. But if there is, > then RACM may need to delete the corresponding extra columns. OK. From j.schoenwaelder@jacobs-university.de Thu Jul 30 01:21:28 2009 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 5466828C218 for ; Thu, 30 Jul 2009 01:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT1592UwEfPj for ; Thu, 30 Jul 2009 01:21:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3482F28C241 for ; Thu, 30 Jul 2009 01:21:23 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3378C0025 for ; Thu, 30 Jul 2009 10:21:24 +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 Mw1zEARMkKIP for ; Thu, 30 Jul 2009 10:21: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 056FCC00B6 for ; Thu, 30 Jul 2009 10:21:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 41A30B71ADC; Thu, 30 Jul 2009 10:21:25 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Thu, 30 Jul 2009 10:21:25 +0200 Resent-Message-ID: <20090730082125.GA15797@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.123) with Microsoft SMTP Server id 8.1.393.1; Thu, 30 Jul 2009 10:20:55 +0200 Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70E30C00B9 for ; Thu, 30 Jul 2009 10:20:55 +0200 (CEST) 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 KrYhGEHgs5DX; Thu, 30 Jul 2009 10:20:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81212C0025; Thu, 30 Jul 2009 10:20:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AC9F0B71AC2; Thu, 30 Jul 2009 10:20:54 +0200 (CEST) From: Juergen Schoenwaelder To: "saag@ietf.org" Date: Thu, 30 Jul 2009 10:20:54 +0200 Thread-Topic: ISMS report (IETF 75) Thread-Index: AcoQ7qj737TiPsPLT86NplRbUh1VJg== Message-ID: <20090730082054.GC15636@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mutt/1.5.19 (2009-01-05) x-virus-scanned: amavisd-new at jacobs-university.de Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Isms] ISMS report (IETF 75) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?iso-8859-1?Q?=22Sch=F6nw=E4lder=2C_J=FCrgen=22?= List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:21:28 -0000 The ISMS WG met on Monday afternoon at IETF 75. Since the last meeting at IETF 74, all chartered work items were completed (three RFCs published and one currently in AUTH48). A recharting discussion before IETF 75 let to the adoption of two additional work items: SNMP over TLS/DTLS and RADIUS authorization of SNMP access control policies. Two individual submissions were discussed at IETF 75 and the WG adopted them as working group items. The goal is to deliver the final versions of these documents in January 2010 to the IESG and then ISMS is likely done. /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 Pasi.Eronen@nokia.com Thu Jul 30 23:30:15 2009 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 683B33A696B for ; Thu, 30 Jul 2009 23:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 p5Dlb67E4eZj for ; Thu, 30 Jul 2009 23:30:14 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8D9603A680E for ; Thu, 30 Jul 2009 23:30:14 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6V6Tdjh030839 for ; Fri, 31 Jul 2009 01:30:01 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 09:30:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 09:29:56 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 31 Jul 2009 08:29:55 +0200 From: To: Date: Fri, 31 Jul 2009 08:29:55 +0200 Thread-Topic: New co-chair Thread-Index: AcoRqFGE2Kf4BbsBQIa4kjz/17eeMA== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A714EA2DA@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jul 2009 06:29:56.0504 (UTC) FILETIME=[5237B180:01CA11A8] X-Nokia-AV: Clean Subject: [Isms] New co-chair 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, 31 Jul 2009 06:30:15 -0000 Folks, Tim and I are happy to announce that Russ Mundy has agreed to co-chair the ISMS WG with Juergen. Best regards, Pasi & Tim