From mailman-bounces@ietf.org Mon Nov 1 05:10:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10848 for ; Mon, 1 Nov 2004 05:10:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COZO8-0003IU-OM for isms-archive@ietf.org; Mon, 01 Nov 2004 05:26:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZ1E-0005kX-FI for isms-archive@ietf.org; Mon, 01 Nov 2004 05:02:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: isms-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:01:06 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for isms-archive@ietf.org: List Password // URL ---- -------- isms@lists.ietf.org riufwi https://www1.ietf.org/mailman/options/isms/isms-archive%40ietf.org From isms-bounces@ietf.org Mon Nov 1 11:18:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27612; Mon, 1 Nov 2004 11:18:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COf8S-0002hh-M1; Mon, 01 Nov 2004 11:34:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COeDX-00087z-U1; Mon, 01 Nov 2004 10:35:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COc9a-0002SK-0N for isms@megatron.ietf.org; Mon, 01 Nov 2004 08:23:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00058 for ; Mon, 1 Nov 2004 08:23:19 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COcOQ-00072T-GY for isms@ietf.org; Mon, 01 Nov 2004 08:38:46 -0500 Received: from cmf.nrl.navy.mil (kh-dhcp-52.cmf.nrl.navy.mil [134.207.5.52]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id iA1DNBOh028446 for ; Mon, 1 Nov 2004 08:23:12 -0500 (EST) Message-Id: <200411011323.iA1DNBOh028446@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] meeting agenda? In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 01 Nov 2004 08:23:11 -0500 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a >Do we have a agenda thought out yet? There isn't one on the agenda >page yet. The obvious topics are probably protocol overviews (I'm not >sure they're worth the time or not since we've been briefed a bunch at >both BOFs), requirements discussions, requirements evaluation and >selection process, and, of course, everyone's favorite: the brawl. Here's what Juergen and I have so far. Comments welcome (yes, I know there isn't much time to comment on it; my apologies for the delay). --Ken Integrated Security Model for SNMP WG (isms) IETF #61 November 7, 2003 : 0900 - 1130 ============================================ Chairs: Ken Hornstein Juergen Quittek AGENDA: 1) Agenda bashing, WG Status ( 5 min) 2) Decision process (45 min) - security model requirements - evaluation criteria - evaluation procedure 3) Proposal presentations (30 min) - TLSM - Transport Layer Security Model 4) Proposal updates - SBSM - Session-Based Security Model (15 min) - EUSM - External User Security Model (15 min) 5) Discussion of proposals (30 min) 6) Wrap up (10 min) - action points, schedule for evalaution INTERNET DRAFTS: Transport Layer Security Model (TLSM) for the Simple Network Management Protocol version 3 (SNMPv3) http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-00.txt A Session-Based Security Model (SBSM) for version 3 of the Simple Network Management Protocol (SNMPv3) http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt External User Security Model (EUSM) for version 3 of the Simple Network Management Protocol (SNMPv3) http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-00.txt _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 1 11:29:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29057; Mon, 1 Nov 2004 11:29:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfIq-00039d-5W; Mon, 01 Nov 2004 11:45:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COecK-0003Id-TZ; Mon, 01 Nov 2004 11:01:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COdFP-0005Pf-8Z for isms@megatron.ietf.org; Mon, 01 Nov 2004 09:33:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07686 for ; Mon, 1 Nov 2004 09:33:26 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COdUJ-0008Jh-Uc for isms@ietf.org; Mon, 01 Nov 2004 09:48:52 -0500 Received: from dialin-145-254-215-237.arcor-ip.net (dialin-145-254-215-237.arcor-ip.net [145.254.215.237]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 1C3A81BACA3; Mon, 1 Nov 2004 15:32:53 +0100 (CET) Date: Mon, 01 Nov 2004 15:32:50 +0100 From: Juergen Quittek To: Wes Hardaker , isms@ietf.org Subject: Re: [Isms] meeting agenda? Message-ID: <2147483647.1099323169@dialin-145-254-215-237.arcor-ip.net> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Wes and all, Please find the agenda that Ken and I discussed at Of course, suggestions for changes are welcome and can be discussed at the beginning of our session. Then we can also discuss if we want to talk about the decision process before we hear the presentations on the three proposals or after them. I think it is better to discuss the process first. This gives the proposers a chance to address some decision process- related issues in their presentations that are not addressed by the respective I-Ds. We have not yet received a presentation of TSLM. Therefore, the agenda has a 30 minutes time slot for this model. For the other two models, just updates in 15 minutes time slot should be sufficient. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 29.10.2004 23:10 Uhr -0700 Wes Hardaker wrote: > > Do we have a agenda thought out yet? There isn't one on the agenda > page yet. The obvious topics are probably protocol overviews (I'm not > sure they're worth the time or not since we've been briefed a bunch at > both BOFs), requirements discussions, requirements evaluation and > selection process, and, of course, everyone's favorite: the brawl. > > -- > Wes Hardaker > Sparta > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 1 12:30:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06705; Mon, 1 Nov 2004 12:30:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgG8-00056I-Sl; Mon, 01 Nov 2004 12:46:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfdV-00015t-UY; Mon, 01 Nov 2004 12:06:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfIf-0006oF-FL for isms@megatron.ietf.org; Mon, 01 Nov 2004 11:44:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01061 for ; Mon, 1 Nov 2004 11:44:55 -0500 (EST) Message-Id: <200411011644.LAA01061@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfXX-0003ge-LF for isms@ietf.org; Mon, 01 Nov 2004 12:00:24 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <20041101164421012009krihe>; Mon, 1 Nov 2004 16:44:21 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , "'Wes Hardaker'" , Subject: RE: [Isms] meeting agenda? Date: Mon, 1 Nov 2004 11:44:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTAL/zFBHOXId1TTyKT1ZH/BplXQQAAcXrg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <2147483647.1099323169@dialin-145-254-215-237.arcor-ip.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Is there a written proposal for the evaluation process/guidelines? That would probably be helpful, although other WGs have learned that it is difficult to write evaluation "requirements" that are unbiased. dbh -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek Sent: Monday, November 01, 2004 9:33 AM To: Wes Hardaker; isms@ietf.org Subject: Re: [Isms] meeting agenda? Wes and all, Please find the agenda that Ken and I discussed at Of course, suggestions for changes are welcome and can be discussed at the beginning of our session. Then we can also discuss if we want to talk about the decision process before we hear the presentations on the three proposals or after them. I think it is better to discuss the process first. This gives the proposers a chance to address some decision process- related issues in their presentations that are not addressed by the respective I-Ds. We have not yet received a presentation of TSLM. Therefore, the agenda has a 30 minutes time slot for this model. For the other two models, just updates in 15 minutes time slot should be sufficient. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 29.10.2004 23:10 Uhr -0700 Wes Hardaker wrote: > > Do we have a agenda thought out yet? There isn't one on the agenda > page yet. The obvious topics are probably protocol overviews (I'm not > sure they're worth the time or not since we've been briefed a bunch at > both BOFs), requirements discussions, requirements evaluation and > selection process, and, of course, everyone's favorite: the brawl. > > -- > Wes Hardaker > Sparta > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 1 12:31:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06834; Mon, 1 Nov 2004 12:31:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgH8-00058D-31; Mon, 01 Nov 2004 12:47:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfeG-0001aj-Qa; Mon, 01 Nov 2004 12:07:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfM9-0008VC-2Y for isms@megatron.ietf.org; Mon, 01 Nov 2004 11:48:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01478 for ; Mon, 1 Nov 2004 11:48:31 -0500 (EST) Message-Id: <200411011648.LAA01478@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfb3-0003oO-6Y for isms@ietf.org; Mon, 01 Nov 2004 12:03:59 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc11) with SMTP id <20041101164759011002qpn6e>; Mon, 1 Nov 2004 16:47:59 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , "'Wes Hardaker'" , Subject: RE: [Isms] meeting agenda? Date: Mon, 1 Nov 2004 11:48:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTAL/zFBHOXId1TTyKT1ZH/BplXQQAAhXeQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <2147483647.1099323169@dialin-145-254-215-237.arcor-ip.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Hi, I will post an updated revision of the TLSM proposal to the list by Wednesday. I have done a substantial amount of work on the proposal. I recommend people don't bother to read the current TLSM proposal, because it is extremely preliminary and incomplete. dbh -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek Sent: Monday, November 01, 2004 9:33 AM To: Wes Hardaker; isms@ietf.org Subject: Re: [Isms] meeting agenda? Wes and all, Please find the agenda that Ken and I discussed at Of course, suggestions for changes are welcome and can be discussed at the beginning of our session. Then we can also discuss if we want to talk about the decision process before we hear the presentations on the three proposals or after them. I think it is better to discuss the process first. This gives the proposers a chance to address some decision process- related issues in their presentations that are not addressed by the respective I-Ds. We have not yet received a presentation of TSLM. Therefore, the agenda has a 30 minutes time slot for this model. For the other two models, just updates in 15 minutes time slot should be sufficient. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 29.10.2004 23:10 Uhr -0700 Wes Hardaker wrote: > > Do we have a agenda thought out yet? There isn't one on the agenda > page yet. The obvious topics are probably protocol overviews (I'm not > sure they're worth the time or not since we've been briefed a bunch at > both BOFs), requirements discussions, requirements evaluation and > selection process, and, of course, everyone's favorite: the brawl. > > -- > Wes Hardaker > Sparta > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Nov 3 13:02:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03233; Wed, 3 Nov 2004 13:02:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPhm-00031E-6q; Wed, 03 Nov 2004 13:17:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPNT-0000sH-6n; Wed, 03 Nov 2004 12:56:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPH1-00040A-1u for isms@megatron.ietf.org; Wed, 03 Nov 2004 12:50:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02217 for ; Wed, 3 Nov 2004 12:50:15 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPWM-0002kr-U8 for isms@ietf.org; Wed, 03 Nov 2004 13:06:11 -0500 Received: from [10.1.1.171] (dummy.netlab.nec.de [195.37.70.40]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 399E11BAC99 for ; Wed, 3 Nov 2004 18:49:43 +0100 (CET) Date: Wed, 03 Nov 2004 18:49:42 +0100 From: Juergen Quittek To: isms@ietf.org Message-ID: <2147483647.1099507782@[10.1.1.171]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Isms] ISMS evaluation team X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Dear all, Ken and I are still looking for volunteers for the evaluation team. Potential team members should have a strong background in existing security frameworks and/or in SNMP. They are expected to join the IETF #61 ISMS session on Monday and an evaluation team meeting some time during the IETF meeting. After the IETF meeting there might be a few phone conferences necessary until the team comes to a decision before November 29th. Ken and I will moderate the team meeting and phone conferences and take minutes. One or more team members should edit and I-D that explains the decision and that (ideally) should be submitted before Christmas. So if you would like to help us finding the best of the three proposals, please contact Ken and me (and please have the three I-Ds read before the ISMS session ;-). Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 4 18:44:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23949; Thu, 4 Nov 2004 18:44:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPrXC-0002ww-2s; Thu, 04 Nov 2004 19:00:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPr5X-0007tC-1G; Thu, 04 Nov 2004 18:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPr4F-0007IL-9A for isms@megatron.ietf.org; Thu, 04 Nov 2004 18:30:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22861 for ; Thu, 4 Nov 2004 18:30:56 -0500 (EST) Message-Id: <200411042330.SAA22861@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPrJq-0002gA-00 for isms@ietf.org; Thu, 04 Nov 2004 18:47:07 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004110423302401400s6kl3e>; Thu, 4 Nov 2004 23:30:24 +0000 From: "David B Harrington" To: Date: Thu, 4 Nov 2004 18:30:20 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B2_01C4C29C.574A7280" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTCxj+efSHglI7WRF+za2KUCRlIAw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9b9441a4a5b0bd4db4ba0f72cd2b21ac Subject: [Isms] Revised TLS proposal X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 654d8dea790bc7609adc97f133706ab1 This is a multi-part message in MIME format. ------=_NextPart_000_00B2_01C4C29C.574A7280 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I posted this revison yesterday, but it is in the queue for posting approval because I used a different email address. Let's try this address instead. David Harrington dbharrington@comcast.net ------=_NextPart_000_00B2_01C4C29C.574A7280 Content-Type: text/plain; name="draft-schoenw-snmp-tlsm-00-dbh3.txt" Content-Disposition: attachment; filename="draft-schoenw-snmp-tlsm-00-dbh3.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Harrington Internet-Draft Independent Expires: April 1, 2005 J. Schoenwaelder International University Bremen October 2004 Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol version 3 (SNMPv3) draft-schoenw-snmp-tlsm-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes a Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol (SNMP) architecture defined in RFC3411. At this stage, this document does not provide a complete solution - it rather identifies and discusses some key aspects that need discussion and future work. Harrington & Schoenwaelder Expires April 1, 2005 [Page 1] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements of a Transport Mapping Security Model . . . . . . 4 3.1 Security Requirements . . . . . . . . . . . . . . . . . . 4 3.2 Architectural Modularity Requirements . . . . . . . . . . 5 3.3 Passing messages between Dispatchers . . . . . . . . . . . 5 3.4 Security Parameter Passing Requirement . . . . . . . . . . 6 3.4.1 Using an ASI . . . . . . . . . . . . . . . . . . . . . 6 3.4.2 Using a cache . . . . . . . . . . . . . . . . . . . . 6 3.4.3 Using an encapsulating header . . . . . . . . . . . . 7 3.4.4 Using existing fields in a message . . . . . . . . . . 7 3.5 Access Control Requirements . . . . . . . . . . . . . . . 8 3.5.1 Architectural securityName Binding Requirement . . . . 8 4. Fields in the SNMPv3 message . . . . . . . . . . . . . . . . . 8 4.1 msgVersion . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 msgGlobalData . . . . . . . . . . . . . . . . . . . . . . 9 4.3 securityLevel and msgFlags . . . . . . . . . . . . . . . . 9 4.4 The tmStateReference for Passing Security Parameters . . . 11 4.5 securityStateReference Cached Security Data . . . . . . . 11 4.5.1 Prepare an Outgoing SNMP Message . . . . . . . . . . . 12 4.5.2 Prepare Data Elements from an Incoming SNMP Message . 12 4.6 Notifications . . . . . . . . . . . . . . . . . . . . . . 13 5. Transport Mapping Security Model Samples . . . . . . . . . . . 13 5.1 TLS/TCP Transport Mapping Security Model . . . . . . . . . 13 5.1.1 tmStateReference for TLS . . . . . . . . . . . . . . . 13 5.1.2 MP portion for TLS TM-Security Model . . . . . . . . . 14 5.1.3 MIB Module for TLS Security . . . . . . . . . . . . . 14 5.2 DTLS/UDP Transport Mapping Security Model . . . . . . . . 14 5.2.1 tmStateReference for DTLS . . . . . . . . . . . . . . 15 5.3 SASL Transport Mapping Security Model . . . . . . . . . . 16 5.3.1 tmStateReference for SASL DIGEST-MD5 . . . . . . . . 16 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 7.2 Informative References . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 A. Message security versus session security . . . . . . . . . . . 19 A.1 msgFlags versus actual security . . . . . . . . . . . . . 19 A.2 Message security versus session security . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 21 Harrington & Schoenwaelder Expires April 1, 2005 [Page 2] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 1. Introduction There are multiple ways to secure one's home or business, but they largely boil down to a continuum of alternatives. Let's consider three general approaches. In the first approach, an individual/ company could buy a gun, learn to use it, and sit on your front porch waiting for intruders. In the second approach, one could hire an employee with a gun, schedule the employee, position the employee to guard what you want protected, hire a second guard to cover if the first gets sick, and so on. In the third approach, you could hire a security company, tell them what you want protected, and they could hire employeess, train them, buy the guns, position the guards, schedule the guards, send a replacemnt when a guard cannot make it, etc., thus providing the security you want, with no significant effort on your part other than identifying requirements and verifying the quality of the service being provided. The User-based Security Model (USM) as defined in [RFC3414] largely uses the first approach - it provides its own security. It utiilizes existing mechanisms (MD5=3Dthe gun), but provides all the = coordination. USM provides for the authentication of a principal, message encryption, data integrity checking, timeliness checking, etc. USM was designed to be independent of other existing security infrastructures. USM therefore requires a separate user and key management infrastructure. Operators have reported that deploying another user and key management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3 at this point in time. It is possible but difficult to define external mechanisms that handle the distribution of keys for use by the USM approach. A solution based on the second approach might use a USM-compliant architecture, but replace the authentication mechanism with an external mechanism, such as RADIUS, to provide the authentication service. It might be possible to utilize an externa protocol to encrypt a message, to check timeliness, to check data integrity, etc. It is difficult to cobble together a number of sub-cintracted services and coordinate them however, because it is difficult to build solid security bindings between the various services, and potential for gaps in the security is significant. A solution based on the third approach might utilize one or more lower-layer security mechanisms to provide the message-oriented security services required. These would include authentication of the sender, encryption, timeliness checking, and data integrity checking. There are a number of IETF standards available or in development to address these problems at lower layers, frequently at the transport layer. A solution based on this approach mght also Harrington & Schoenwaelder Expires April 1, 2005 [Page 3] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 utilize a "transport" that is actually another application operating at the application layer, such as SSH [SSHauth] This document proposes a Transport Mapping Security Model (TMSM), as an extension of the SNMPv3 architecture, that would allow security to be provided an external protocol connected to the SNMP engine through an SNMP transport-mapping. Such a TMSM would then enable the use of existing security mechanisms such as (TLS) [RFC2246], Kerberos [RFC1510] or SASL [RFC2222] within the SNMPv3 architecture. As pointed out in the EUSM proposal [EUSM], it is desirable to use mechanisms that could "unify the approach for administrative security for SNMPv3 and CLI" and other management interfaces. The use of security services provided by lower layers or other applications is the approach commonly used for the CLI, and is the approach being proposed for NETCONF This document provides the motivation for leveraging transport layer security mechanisms for secure SNMP communication, identifies some key issues and provides some proposals for design choices that may be made to provide a workable solution that meets operational requirements and fits into the SNMP architecture defined in [RFC3411] 2. Motivation There are a number of Internet security protocols and mechanisms that are in wide spread use. Many of them try to provide a generic infrastructure to be used by many different application layer protocols. The motivation behind TMSM is to leverage these protocols where it seems useful. There are a number of challenges to be addressed to map the security provided by a secure transport into the SNMP architecture so that SNMP continues to work without any surprises. These are discussed in detail below. 3. Requirements of a Transport Mapping Security Model 3.1 Security Requirements Transport mapping security protocols SHOULD ideally provide the protection against the following message-related threats [RFC3411]: 1. modification of information 2. masquerade 3. message stream modification 4. disclosure Harrington & Schoenwaelder Expires April 1, 2005 [Page 4] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 According to [RFC3411], it is not required to protect against denial of service or traffic analysis. 3.2 Architectural Modularity Requirements [RFC3411] section 3 describes a modular architecture to allow the evolution of the SNMP protocol standards over time. This architecture includes a Security Subsystem which is responsible for realizing security services. Transport mapping security is by its very nature a security layer which is plugged in between the transport layer and the dispatcher. Conceptually, transport mapping security models will be called from within the Transport Mapping portion of an SNMP engine, or will be positioned between the transport mapping subsystem and the dispatcher. The design of a transport mapping security model must abide the goals of the RFC3411 architecture, section 1. To that end, this transport mapping security model proposal focuses on a modular subsystem that can be advanced through the standards process independently of other proposals, and independent of other susbsystems as much as possible. This subsystem is designed as an architectural extension that permits different transport mapping security protocols to be "plugged into" this subsystem, to support supplemental transport mapping security models in addition to those described here. IETF standards typically require one mandatory-to-implement solution, with the capability of adding new security mechanisms in the future. Any transport mapping security model should define one minimum-compliance mechanism, preferably one which is already widely deployed within the trasnport layer security protocol used. This architectural extension is illustrated by the following diagram, which is a modified version of the diagram taken from the SNMP architecture document. TODO: Insert drawing here... 3.3 Passing messages between Dispatchers Typically, with a TMSM model, the transport mapping will establish an encrypted tunnel between the transport mappings of two SNMP engines, without passing anything to the SNMP dispatcher. One transport mapping security model instance encrypts all messages, and the other transport mapping security model instance decrypts the messages. Harrington & Schoenwaelder Expires April 1, 2005 [Page 5] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 After the transport-layer tunnel is established, then SNMP messages can conceptually be sent through the tunnel from one SNMP engine dispatcher to another SNMP engine dispatcher. SNMP messages are passed unencrypted from the source dispatcher to its own TMSM, and presented unencrypted to the destination SNMP dispatcher. Once the tunnel is established, multiple SNMP messages may be able to be passed through the same tunnel. 3.4 Security Parameter Passing Requirement [RFC3411] section 4 describes primitives to describe the abstract service interfaces used to conceptually pass information between the various subsystems, models and applications within the architecture. A Transport mapping Security Model must pass information between subsystems as well. The RFC3411 architecture has no ASI parameters for passing security information between the transport mapping and the dispatcher, and between the dispatcher and the message processing model. Since the TM-security model and MP-security model are co-resident within an implementation, it is assumed there is a trust relationship that exists within the implementation. There are four approaches that could be used for passing information between the TM-securitymodel and the MP-security model : we could define an ASI to supplement the existing ASIs, or the TMSM could pass the information in an implementation-specific cache, or the TMSM could add a header to encapsulate the SNMP message, or the TMSM could utilize fields already defined in the existing SNMPv3 message. 3.4.1 Using an ASI RFC3411 discusses the purpose, and an explicit non-purpose, of the ASI approach: "This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation." An ASI is not an API, and following a defined ASI is not required for interoperability, so implementors are really free to use any method they choose. However, defining an ASI has the advantage of being consistent with existing RFC3411/3412 practice. 3.4.2 Using a cache A cache mechanism could be used, in which the TM-security model puts information about the security applied to an incoming message, and an MP-security model extracts that information from the cache. The cache is not passed via an explicit ASI. Given that there may be Harrington & Schoenwaelder Expires April 1, 2005 [Page 6] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 multiple TM-security caches, a cache-ID probably needs to be passed in the message in the ASI so the MP-security model knows which cache to consult. This approach would be consistent with the securityStateReference cache already being passed around in the ASI. The cache could be thought of as an additional parameter in the ASI. The ASI would not need to be changed since the SNMPv3 WG expected that additional parameters could be passed for value-add features of specific implementations. 3.4.3 Using an encapsulating header A header could encapsulate the SNMP message to pass necessary information from the TM-security model to the dispatcher and then to the MP-security model. The message header would be included in the wholeMessage ASI parameter, and would be removed by a corresponding messaging model. This would imply a new messaging model would need to be specified as well. The other approaches may be able to use the standard SNMPv3 messaging model, with a new MP-security model. 3.4.4 Using existing fields in a message [RFC3412] describes the SNMPv3 message, which contains fields to pass security-related parameters. The TMSM could use these fields in an SNMPv3 message, or comparable fields in other message formats to pass information between transport mapping security models in different SNMP engines, and to pass information between a TM security model and the corresponding MP security model. It is importnat to understand that SNMP messages are ASN.1 encoded, and the SNMP architecture places no constraints on how the ASN.1 gets decoded - it might be decoded in one massive decode, or individual portions of the message, such as individual varbinds, may be decoded only as needed. This is an implementation decision. If the fields in an incoming SNMPv3 message are changed by the TM portion before passing it to the MP portion, then the TM portion will need to encode its parameters in ASN.1 or the message model would need to be modified to permit non-encoded data to be added to the message in a manner that would not impact the existing ASN.1 encoding/decoding of the message. In addition, the MP portion may not be able to perform a transport-independent message integrity check, and transport-independent encryption may not be able to be performed by the MP portion of the model. While it may be desirable for most TMSM models to perform those services through the TM portion of the model, assuming the use of a cache or an encapsulating header would not impose such constraints on future models. Harrington & Schoenwaelder Expires April 1, 2005 [Page 7] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 This document will describe a cache approach, but an encapsulating header or other mechanisms could also be used if preferred for specific TM security models. 3.5 Access Control Requirements 3.5.1 Architectural securityName Binding Requirement For SNMP access control to function properly, the security mechanism must establish a securityName, which is the security model independent identifier for a principal, a security model identifier, and a securityLevel. The SNMPv3 message processing architecture subsystem relies on a message model based security model, such as USM, to play an role in security that goes beyond protecting the message - it ties various security models for the same principal to a security-model independent securityName which can be used for subsequent processing, such as for access control. The TMSM assumes two portions to a security model, one tied to the transport mapping and another tied to the message processing model. and will be referred to here as a TM-portion and an MP-portion of the security model. Depending on the specific design of the security model, different features might be provided by the TM portion or by the MP portion. For example, the binding of a mechanism-specific authenticated identity to a securityName might be done by the TM portion or by the MP portion. The SNMP architecture distinguishes between messages with no authentication and no privacy (noAuthNoPriv), authentication without privacy (authNoPriv) and authentication with privacy (authPriv). Hence, the authentication of a transport-layer identity plays an important role and must be considered by any transport layer security mechanism used. However, it is also possible that a second level of authentication, one provided by a AAA server, for example, may be used to provide the authentication identity which is bound to the securityName, if the type of authentication provided by the transport layer (e.g. host-based or anonymous) is considered adequate to secure and/or encrypt the message, but inadequate to provide the desired granularity of access control (e.g. user-based). 4. Fields in the SNMPv3 message 4.1 msgVersion For proposals that reuse the SNMPv3 message format, this field should contain the value 3. Harrington & Schoenwaelder Expires April 1, 2005 [Page 8] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 4.2 msgGlobalData msgID and msgMaxSize are used identically for the TMSM models as for the USM model. msgSecurityModel should be set to a value from the SnmpSecurityModel enumeration [RFC3410] to identify the specific TMSM model. msgSecurityParameters is used identically for the TMSM models as for the USM model. msgFlags have the same values for the TMSM models as for the USM model. "The authFlag and privFlag fields indicate the securityLevel that was applied to the message before it was sent on the wire." 4.3 securityLevel and msgFlags For an outgoing message, msgFlags is the requested security for the message; if a TMSM cannot provide the requested securityLevel, the model MUST describe a standard behavior that is followed for that situation. If the TMSM cannot provide at least the requested level of security, the TMSM MUST discard the request and SHOULD notify the message processing model that the request failed. [dbh: how is yet to be determined, and may be model-specific or implementation-specific.] For an outgoing message, if the TMSM is able to provide stronger than requested security, that may be acceptable. The transport layer protocol would need to indicate to the receiver what security has been applied to the actual message. To avoid the need to mess with the ASN.1 encoding, the SNMPv3 message carries the requested msgFlags, not the actual securityLevel applied to the message. If a non-SNMPv3 message format is used, then the new message may carry the more accurate securityLevel in the SNMP message. For an incoming message, the receiving TMSM knows what must be done to process the message based on the transport layer mechanisms. If the underlying transport security mechanisms for the receiver cannot provide the matching securityLevel, then the message should follow the standard behaviors for the transport security mechanism, or be discarded silently. Part of the responsibility of the TMSM is to ensure that the actual security provided by the underlying transport layer security mechansisms is configured to meet or exceed the securityLevel required by the msgFlags in the SNMP message. When the MP-security portion of the model processes the incoming message, it should compare the msgFlags field to the securityLevel actually provided for Harrington & Schoenwaelder Expires April 1, 2005 [Page 9] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 the message by the transport layer security. If they differ, the MP portion of the security model should determine whether the changed securityLevel is acceptable. If not, it should discard the message. Depending on the model, the MP portion may issue a reportPDU with the XXXXXXX model-specific counter. Questions about msgFlags: Is the seclevel looked at before the security model gets to it.? No. the security model has two parts - the TM portion and the MP portion. The seclevel is looked at by the TM portion before it gets to the MP piece, but both are parts of the same security model. Would it be legal for the security model to ignore the incoming flags and change them before passing them back up? If it changed them, it wouldn't necessarily be ignoring them. The TM portion should pass both an actual securityLevel applied to the message, and the msgFlags in the SNMP message to the MP piece for consideration related to access control.. The msgFlags parameter in the SNMP message is never changed when processing an incoming message. Would it be legal for the security model to ignore the outgoing flags and change them before passing them out? no; because the two portions are parts of the same security model, either the MP piece should recognize that a securityLevel cannot be met or exceeded, and reject the message during the message-build phase, or the TM piece should determine if it is possible to honor the request. It is possible to apply an increased securityLevel for an outgoing request, but the procedure to do so must be spelled out clearly in the model design. The security model would need to (MUST) check the incoming security level flags to make sure they matched the TLS/whatever session setup and if not drop the message. Yes, mostly. Depending on the model, either the TM portion or the MP portion MUST verify that the actual processing met or exceeded the securityLevel requested by the msgFlags and that it is acceptable to the specific-model processing (or operator configuration) for this different securitylevel to be applied to the message. This is also true (especially) for outgoing messages. You might legally be able to have a authNoPriv message that is actually encrypted via the transport (but not the other way around of course). Yes, a TMSM could define that as the behavior (or permit an operator to specifiy that is acceptable behavior) when a requested securityLevel cannot be provided, but a stronger securityLevel can be provided. See the Appendix A appendix for further discussion of the msgFlags field versus the actual securityLevel provided. [dbh: it may be a Harrington & Schoenwaelder Expires April 1, 2005 [Page 10] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 good thing to merge the Q and A with the appendix, either here or there.] 4.4 The tmStateReference for Passing Security Parameters A tmStateReference is used to pass data between the TM portion and the MP portion of the security model, similar to the securityStateReference described in RFC3412. This can be envisioned as being appended to the ASIs between the TM and the MP or as being passed in an encapsulating header. The TM portion of the security model may provide only some aspects of security, and leave some aspects to the MP portion of the model. tmStateReference should be used to pass any parameters, in a model- and mechanism-specific format, that will be needed to coordinate the activities of the TM and MP portions of the model, and the parameters subsequently passed in securityStateReference . For example, the TM portion may provide privacy and data integrity and authentication and authorization policy retrievals, or some subset of these features, depending on the features available in the transport mechanisms. A field in tmStatereference should identify which services were provided for each received message by the TM portion, the securityLevel applied to the received message, the model-specific security identity, the session identifier for session-based transport security, and so on. 4.5 securityStateReference Cached Security Data From RFC3411: "For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Local Configuration Datastore is altered between the time of the incoming request and the outgoing response. A Message Processing Model has the responsibility for explicitly releasing the cached data if such data is no longer needed. To enable this, an abstract securityStateReference data element is passed from the Security Model to the Message Processing Model. The cached security data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in section 4.5.1." To differentiate what information needs to be provided to the MP portion by the TM portion, and vice-versa, this document will differentiate the tmStateReference from the securityStateReference. An implementation MAY use one cache and one reference to serve both functions, but an implementer must be aware of the cache-release issues to prevent the cache from being released before the TM portion Harrington & Schoenwaelder Expires April 1, 2005 [Page 11] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 has had an opportunity to extract the information it needs. 4.5.1 Prepare an Outgoing SNMP Message According to RFC3412, section 7.1, the SNMPv3 message processing model calls the MP portion of the TM security model using the generateResponseMsg() or generateRequestMsg(). The MP portion of the model may need to put information into the tmStateReference cache for use by the TM portion of the model, such as: tmSecurityStateReference - the unique identifier for the cached information tmTransportDomain tmTransportAddress tmSecurityModel - an indicator of which mechanisms to use tmSecurityName - a model-specific identifier of the security principal tmSecurityLevel - an indicator of which security services are requested and may contain additional information such as tmSessionID tmSessionKey tmSessionMsgID 4.5.2 Prepare Data Elements from an Incoming SNMP Message For an incoming message, the TM portion of a model will need to put information from the transport mechanisms used into the tmStateReference so the MP portion of the model can extract the information and add it conceptually to the securityStateReference. The tmStateReference cache will likely contain at least the following information: tmStateReference - a unique identifier for the cached information tmSecurityStateReference - the unique identifier for the cached information tmTransportDomain tmTransportAddress tmSecurityModel - an indicator of which mechanisms to use tmSecurityName - a model-specific identifier of the security principal tmSecurityLevel - an indicator of which security services are requested tmAuthProtocol tmPrivProtocol and may contain additional information such as tmSessionID tmSessionKey Harrington & Schoenwaelder Expires April 1, 2005 [Page 12] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 tmSessionMsgID 4.6 Notifications For notifications, if the cache has been released and then session closed, then the MP-security model will request the TM-security model to establish a session, populate the cache, and pass the securityStateReference to the MP-security model. TODO: We need to determine what state needs to be saved here. 5. Transport Mapping Security Model Samples 5.1 TLS/TCP Transport Mapping Security Model SNMP supports multiple transports. The preferred transport for SNMP over IP is UDP [RFC3417]. An experimental transport for SNMP over TCP is defined in [RFC3430]. TLS/TCP will create an association between the TMSM of one SNMP entity and the TMSM of another SNMP entity. The created "tunnel" may provide encryption and data integrity. Both encryption and data integrity are optional features in TLS. The TLS TM-security model MUST provide authentication if auth is requested in the securityLevel of the SNMP message request (RFC3412 4.1.1). The TLS TM-security model MUST specify that the messages be encrypted if priv is requested in the securityLevel parameter of the SNMP message request (RFC3412 4.1.1). The TLS TM-security model SHOULD use the TLS Handshake Protocol with mutual authentication. 5.1.1 tmStateReference for TLS Upon establishment of a TLS session, the TM-security model will cache the state information. A tmStateReference that is unique within the SNMP entity will be stored in the cache, and passed to the corresponding MP-security model, to enable lookup. The MP security model will pass the securityStateReference to the Message Processing Model for memory management. The tmStateReference cache: tmStateReference tmSecurityStateReference tmTransportDomain =3D TCP/IPv4 tmTransportAddress =3D x.x.x.x:y tmSecurityModel - TLS TMSM Harrington & Schoenwaelder Expires April 1, 2005 [Page 13] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 tmSecurityName =3D "dbharrington" tmSecurityLevel =3D "authPriv" tmAuthProtocol =3D Handshake MD5 tmPrivProtocol =3D Handshake DES tmSessionID =3D Handshake session identifier tmSessionKey =3D Handshake peer certificate tmSessionMasterSecret =3D master secret tmSessionParameters =3D compression method, cipher spec, is-resumable 5.1.2 MP portion for TLS TM-Security Model messageProcessingModel =3D SNMPv3 securityModel =3D TLS TMSM securityName =3D tmSecurityName securityLevel =3D msgSecurityLevel 5.1.3 MIB Module for TLS Security Each security model should use its own mib module, rather than utilizing the USM MIB, to eliminate dependencies on a model that could be replaced some day. See RFC3411 section 4.1.1. The TLS mib module needs to provide the mapping from model-specific identity to a model-independent securityName. TODO: Module needs to be worked out once things become stable... 5.2 DTLS/UDP Transport Mapping Security Model DTLS has been proposed as a UDP-based TLS. Transport Layer Security (TLS) [RFC2246] traditionally requires a connection-oriented transport and is usually used over TCP. Datagram Transport Layer Security (DTLS) [DTLS] provides security services equivalent to TLS for connection-less transports such as UDP. DTLS provides all the security services needed from an SNMP architectural point of view. Although it is possible to derive a securityName from the public key certificates (e.g. the subject field), this approach requires to install certificates on agents and as well as managers, leading to a certificate management problem which again does not integrate well with established AAA systems. Another option is to run an authentication exchange which is integrated with TLS, such as Secure Remote Password with TLS [SRP-TLS]. A similar option would be to use Kerberos authentication with TLS as defined in [RFC2712]. Harrington & Schoenwaelder Expires April 1, 2005 [Page 14] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 It is important to stress that the authentication exchange must be integrated into the TLS mechanism to prevent man-in-the-middle attacks. While SASL [RFC2222] is often used on top of a TLS encrypted channel to authenticate users, this choice seems to be problematic until the mechanism to cryptographically bind SASL into the TLS mechanism has been defined. DTLS will create an association between the TMSM of one SNMP entity and the TMSM of another SNMP entity. The created "tunnel" may provide encryption and data integrity. Both encryption and data integrity are optional features in DTLS. The DTLS TM-security model MUST provide authentication if auth is requested in the securityLevel of the SNMP message request (RFC3412 4.1.1). The TLS TM-security model MUST specify that the messages be encrypted if priv is requested in the securityLevel parameter of the SNMP message request (RFC3412 4.1.1). The DTLS TM-security model SHOULD use the TLS Handshake Protocol with mutual authentication. 5.2.1 tmStateReference for DTLS Upon establishment of a DTLS session, the TM-security model will cache the state information. A tmStateReference that is unique within the SNMP entity will be stored in the cache, and passed to the corresponding MP-security model, to enable lookup. The MP security model will pass the securityStateReference to the Message Processing Model for memory management. The tmStateReference cache: tmStateReference tmSecurityStateReference tmTransportDomain =3D UDP/IPv4 tmTransportAddress =3D x.x.x.x:y tmSecurityModel - DTLS TMSM tmSecurityName =3D "dbharrington" tmSecurityLevel =3D "authPriv" tmAuthProtocol =3D Handshake MD5 tmPrivProtocol =3D Handshake DES tmSessionID =3D Handshake session identifier tmSessionKey =3D Handshake peer certificate tmSessionMasterSecret =3D master secret tmSessionParameters =3D compression method, cipher spec, is-resumable tmSessionSequence =3D epoch, sequence TODO: Harrington & Schoenwaelder Expires April 1, 2005 [Page 15] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 Need to discuss to what extent DTLS is a reasonable choice for SNMP interactions. What is the status of the work to cryptographically bind SASL to DTLS? More details need to be worked out... 5.3 SASL Transport Mapping Security Model The Simple Authentication and Security Layer (SASL) [RFC2222] provides a hook for authentication and security mechanisms to be used in application protocols. SASL supports a number of authentication and security mechanisms, among them Kerberos via the GSSAPI mechanism. This sample will use DIGEST-MD5 because it supports authentication, integrity checking, and confidentiality. DIGEST-MD5 supports auth, auth with integrity, and auth with confidentiality. Since SNMPv3 assumes integrity checking is part of authentication, if msgFlags is set to authNoPriv, the qop-value should be set to auth-int; if msgFlags is authPriv, then qop-value should be auth-conf. Realm is optional, but can be utilized by the securitymodel if desired. SNMP does not use this value, but a TMSM could map the realm into SNMP processing in various ways. For example, realm and username could be concatenated to be the securityName value, e.g. helpdesk::username", or the realm could be used to specify a groupname to use in the VACM access control. This would be similar to the EUSM's approach to having the securityName-to-group mapping done by the external AAA server. 5.3.1 tmStateReference for SASL DIGEST-MD5 The tmStateReference cache: tmStateReference tmSecurityStateReference tmTransportDomain =3D TCP/IPv4 tmTransportAddress =3D x.x.x.x:y tmSecurityModel - SASL TMSM tmSecurityName =3D username tmSecurityLevel =3D [auth-conf] tmAuthProtocol =3D md5-sess tmPrivProtocol =3D 3des tmServicesProvided =3D mutual authentication, reauthentication, Harrington & Schoenwaelder Expires April 1, 2005 [Page 16] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 integrity, encryption tmParameters =3D "realm=3Dhelpdesk, serv-type=3Dsnmp 6. Acknowledgments The authors would like to thank Ira McDonald, Ken Hornstein, and Nagendra Modadugu for their comments and suggestions. 7. References 7.1 Normative References [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message processing and Dispatching for SNMP", STD 62, RFC 3412, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3417] Presuhn (Editor), R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping", RFC 3430, December 2002. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", STD 62, RFC RFC2222, October 1997. [DTLS] Rescola, E. and N. Modadugu, "Datagram Transport Layer Security", ID draft-rescorla-dtls-01.txt, July 2004. Harrington & Schoenwaelder Expires April 1, 2005 [Page 17] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 7.2 Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. [SRP-TLS] Taylor, D., Wu, T., Mavroyanopoulos, M. and T. Perrin, "Using SRP for TLS Authentication", ID draft-ietf-tls-srp-08.txt, August 2004. [EUSM] Narayan, D., McCloghrie, K., Salowey, J. and C. Elliot, "External USM for SNMPvK", ID draft-kaushik-snmp-external-usm-00.txt, July 2004. [NETCONF] Enns, R., "NETCONF Configuration Protocol", ID draft-ietf-netconf-prot-04.txt, October 2004. [SSHauth] Lonvick, C., "SSH Authentication Protocol", ID draft-ietf-secsh-userauth-21.txt, June 2004. Authors' Addresses David Harrington Independent Harding Rd Portsmouth NH USA Phone: +1 603 436 8634 EMail: dbharrington@comcast.net Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Harrington & Schoenwaelder Expires April 1, 2005 [Page 18] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 Appendix A. Message security versus session security A.1 msgFlags versus actual security Using IPSEC, SSH, or SSL/TLS to provide security services "below" the SNMP message, the use of securityname and securityLevel will differ from the USM/VACM approach to SNMP access control. VACM uses the "securityName" and the "securityLevel" to determine if access is allowed. Wtih the SNMPv3 message and USM security model, both securityLevel and securityName are contained in every SNMPv3 message. Any proposal for a security model using IPSEC, SSH, or SSL/TLS needs to specify how this info is made available to the SNMPv3 message processing, and how it is used. One specific case to consider is the relationship between the msgFlags of an SNMPv3 message, and the actual services provided by the lower layer security. For example, if a session is set up with encryption, is the priv bit always (or never) set in the msgFlags field, and is the PDU never (or always) encrypted? Do msgFlags have to match the security services provided by the lower layer, or are the msgFlags ignored and the values from the lower layer used? A.2 Message security versus session security For SBSM, and for many TMSM models, securityname is specified during session setup, and associated with the session identifier. Is it possible for the request (and notification) originator to specify per message auth and encryption services, or are they are "fixed" by the transport/session model? If a session is created as 'authPriv', then keys for encryption would still be negotiated once at the beginning of the session. But if a message is presented to the session with a security level of authNoPriv, then that message could simply be authenticated and not encrypted. Wouldn't that also have some security benefit, in that it reduces the encrypted data available to an attacker gathering packets to try and discover the encryption keys? Agents are often resource-constrained. Adding sessions increases the need for resources, we shouldn't require two sessions when one can suffice. 2 bytes per session structure and a compare or two is much less of a resource burden on an agent than two separate sessions. It's not just about CPU power of the device but the percentage of CPU cycles that are spent on network management. There isn't much value in using encryption for a performance management system polling PEs for performance data on thousands of interfaces every ten minutes,it Harrington & Schoenwaelder Expires April 1, 2005 [Page 19] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 just adds significant overhead to processing of the packet. Using an encrypted TLS channel for everything may not work for use cases in performance management wherein we collect massive amounts of non sensitive data at periodic intervals. Each SNMP "session" would have to negotiate two separate protection channels (authPriv and authNoPriv) and for every packet the SNMP engine will use the appropriate channel based on the desired securityLevel. If the underlying transport layer security was configurable on a per-message basis, a TMSM could have a mib module with configurable maxSecurityLevel and a minSecurityLevel objects to identify the range of possible levels, and not all messages sent via that session are of the same level. A session's maxSecurityLevel would identify the maximum security it could provide, and a session created with a minSecurityLevel of authPriv would reject an attempt to send an authNoPriv message. Harrington & Schoenwaelder Expires April 1, 2005 [Page 20] =0C Internet-Draft SNMPv3 Transport Mapping Security Model October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Harrington & Schoenwaelder Expires April 1, 2005 [Page 21] =0C ------=_NextPart_000_00B2_01C4C29C.574A7280 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ------=_NextPart_000_00B2_01C4C29C.574A7280-- From isms-bounces@ietf.org Thu Nov 4 20:03:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29277; Thu, 4 Nov 2004 20:03:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPslt-0004Tz-Dv; Thu, 04 Nov 2004 20:20:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPsTB-0007Sf-Sc; Thu, 04 Nov 2004 20:00:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPsQa-0006rc-3q for isms@megatron.ietf.org; Thu, 04 Nov 2004 19:58:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28921 for ; Thu, 4 Nov 2004 19:58:05 -0500 (EST) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPsgC-0004Np-G3 for isms@ietf.org; Thu, 04 Nov 2004 20:14:17 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 784A711D8D5; Thu, 4 Nov 2004 16:58:02 -0800 (PST) To: Juergen Quittek Subject: Re: [Isms] ISMS evaluation team References: <2147483647.1099507782@[10.1.1.171]> From: Wes Hardaker Organization: Sparta Date: Thu, 04 Nov 2004 16:58:02 -0800 In-Reply-To: <2147483647.1099507782@[10.1.1.171]> (Juergen Quittek's message of "Wed, 03 Nov 2004 18:49:42 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 >>>>> On Wed, 03 Nov 2004 18:49:42 +0100, Juergen Quittek said: Juergen> Potential team members should have a strong background in existing Juergen> security frameworks and/or in SNMP. They are expected to join the Juergen> IETF #61 ISMS session on Monday and an evaluation team meeting some Juergen> time during the IETF meeting. And obviously should not be authors of or affiliated strongly with the existing proposals, right? -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 4 20:27:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01293; Thu, 4 Nov 2004 20:27:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPt8u-00050H-TT; Thu, 04 Nov 2004 20:43:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPssJ-0003Uh-Vj; Thu, 04 Nov 2004 20:26:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPsld-00022t-JP for isms@megatron.ietf.org; Thu, 04 Nov 2004 20:19:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00580 for ; Thu, 4 Nov 2004 20:19:52 -0500 (EST) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPt1G-0004oY-6P for isms@ietf.org; Thu, 04 Nov 2004 20:36:03 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 38D3911D9A8; Thu, 4 Nov 2004 17:19:49 -0800 (PST) To: ietfdbh@comcast.net Subject: Re: [Isms] Revised TLS proposal References: <200411042330.SAA22861@ietf.org> From: Wes Hardaker Organization: Sparta Date: Thu, 04 Nov 2004 17:19:49 -0800 In-Reply-To: <200411042330.SAA22861@ietf.org> (David B. Harrington's message of "Thu, 4 Nov 2004 18:30:20 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 >>>>> On Thu, 4 Nov 2004 18:30:20 -0500, "David B Harrington" said: David> The TLS TM-security model SHOULD use the TLS Handshake Protocol David> with mutual authentication. [I'm assuming at least auth here for the sake of the following discussion] IMHO, this should be a MUST. Doing anything less is actually arguably less secure than USM, which authenticates both sides (admittedly with the same key, but both sides can be proven to be the correct correspondence assuming no compromise has taken place). With your above statement, it means that no equal confidence can be made when using TLS. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 4 20:39:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02787; Thu, 4 Nov 2004 20:39:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPtJo-0005Ki-Hu; Thu, 04 Nov 2004 20:55:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPt0A-0005Dc-KR; Thu, 04 Nov 2004 20:34:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPsyn-0004vo-Bv for isms@megatron.ietf.org; Thu, 04 Nov 2004 20:33:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02064 for ; Thu, 4 Nov 2004 20:33:28 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPtEM-0005Ba-Nv for isms@ietf.org; Thu, 04 Nov 2004 20:49:39 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA25557; Thu, 4 Nov 2004 17:32:52 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iA51WqN19586; Thu, 4 Nov 2004 19:32:52 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 17:32:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Revised TLS proposal Date: Thu, 4 Nov 2004 17:32:51 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD9A0@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Revised TLS proposal Thread-Index: AcTC1q1SLFMyar6eS4OzbZQfKTsJ0wAAFksw From: "Fleischman, Eric" To: "Wes Hardaker" , X-OriginalArrivalTime: 05 Nov 2004 01:32:51.0717 (UTC) FILETIME=[5D974B50:01C4C2D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Hmm. If we were talking about using TLS for ISMS, I agree with you, Wes, that it must use mutual authentication. However, if we are seeking to require that ISMS must use TLS, then I would disagree. From where I sit, I am by no means convinced that TLS is the best alternative for us to pursue. Please note that I am not saying that it isn't. I am only saying that I am far from convinced that it is. -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 Sent: Thursday, November 04, 2004 5:20 PM To: ietfdbh@comcast.net Cc: isms@ietf.org Subject: Re: [Isms] Revised TLS proposal >>>>> On Thu, 4 Nov 2004 18:30:20 -0500, "David B Harrington"=20 >>>>> said: David> The TLS TM-security model SHOULD use the TLS Handshake Protocol=20 David> with mutual authentication. [I'm assuming at least auth here for the sake of the following discussion] IMHO, this should be a MUST. Doing anything less is actually arguably less secure than USM, which authenticates both sides (admittedly with the same key, but both sides can be proven to be the correct correspondence assuming no compromise has taken place). With your above statement, it means that no equal confidence can be made when using TLS. --=20 Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 4 22:20:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11742; Thu, 4 Nov 2004 22:20:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPuuQ-0007U4-9P; Thu, 04 Nov 2004 22:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPudy-00040x-FP; Thu, 04 Nov 2004 22:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPuQ1-0006Qn-KA for isms@megatron.ietf.org; Thu, 04 Nov 2004 22:05:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10790 for ; Thu, 4 Nov 2004 22:05:35 -0500 (EST) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPufb-0007DY-Ey for isms@ietf.org; Thu, 04 Nov 2004 22:21:47 -0500 Received: from h-66-167-207-65.snvacaid.dynamic.covad.net ([66.167.207.65] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CPuPu-00008T-00 for isms@ietf.org; Thu, 04 Nov 2004 19:05:34 -0800 Message-ID: <000e01c4c2e4$80750060$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 4 Nov 2004 19:06:53 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Isms] EUSM key localization details X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - Page16 of draft-kaushik-snmp-external-usm-00.txt describes how a RADIUS server will generate a localized key. It says that the server will have to have been configured with the set of SNMP Engine IDs in use by the AAA server. What isn't clear to me from the text is how the RADIUS server can know *which* of those SNMP Engine IDs to use in key localization. The RADIUS key request from the SNMPv3 agent carries the SNMP manager's IP address, (as the "Calling-Station-ID") and the user name (as the "User-Name"), but there's nothing for the agent's SNMP Engine ID. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 5 05:06:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24011; Fri, 5 Nov 2004 05:06:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ1EX-0006mH-Em; Fri, 05 Nov 2004 05:22:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0SW-0005tH-UJ; Fri, 05 Nov 2004 04:32:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0O8-0005BY-7j for isms@megatron.ietf.org; Fri, 05 Nov 2004 04:28:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19719 for ; Fri, 5 Nov 2004 04:28:06 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0dp-0005pv-NJ for isms@ietf.org; Fri, 05 Nov 2004 04:44:22 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59RZZu012588 for ; Fri, 5 Nov 2004 10:27:35 +0100 Message-Id: <200411050927.iA59RZZu012588@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:27:31 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGazt1LCCOcm2T2apAAkqHJ6U7Q== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Subject: [Isms] SSL VPN Conference: Call for proposals X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0498990337==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb This is a multi-part message in MIME format. --===============0498990337== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01C4C322.0F200E80" This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C4C322.0F200E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . How to provide SSL-based remote access to a broad range of Web and legacy applications? . What about application performance and requirements? . Are encrypted application tunnelling issues solved? . What differences with IPsec VPNs? These questions, among others, will be tackled by the most recognised experts in this field during the SSL VPN Conference to be held in Paris from April 5 to 8, 2005 The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/sslvpn05/sslvpn05intro.htm ------=_NextPart_000_00EE_01C4C322.0F200E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = How to provide SSL-based remote access to a broad range of Web and legacy applications?
• = What about application performance and requirements?
• = Are encrypted application tunnelling issues solved?
• = What differences with IPsec VPNs?

These questions, among others, will be tackled by the most recognised = experts in this field during the SSL VPN = Conference to be held in Paris from April 5 to 8, 2005

 

The call for proposal dead line has been = extended to November 30.

 

Details = at:

 

http://www.upperside.fr/sslvpn05/sslvpn05intro.htm

 

------=_NextPart_000_00EE_01C4C322.0F200E80-- --===============0498990337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0498990337==-- From isms-bounces@ietf.org Fri Nov 5 06:06:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00359; Fri, 5 Nov 2004 06:06:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ2B1-0008Sd-24; Fri, 05 Nov 2004 06:22:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ1sA-0005zW-Lo; Fri, 05 Nov 2004 06:03:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ1pc-0005Tu-IS for isms@megatron.ietf.org; Fri, 05 Nov 2004 06:00:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29918 for ; Fri, 5 Nov 2004 06:00:33 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ25J-0008Lj-QN for isms@ietf.org; Fri, 05 Nov 2004 06:16:51 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA5B0WvD023191 for ; Fri, 5 Nov 2004 12:00:32 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 12:00:27 +0100 Received: from [159.107.196.23] (mwlx004.eth.ericsson.se [159.107.196.23]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WFZHDXVW; Fri, 5 Nov 2004 12:00:27 +0100 Message-ID: <418B5D4A.9070407@ericsson.com> Date: Fri, 05 Nov 2004 12:00:26 +0100 X-Sybari-Trust: bb819234 ad48f3dd a54bb75c 00000179 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Isms] EUSM key localization details References: <000e01c4c2e4$80750060$7f1afea9@oemcomputer> In-Reply-To: <000e01c4c2e4$80750060$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2004 11:00:27.0387 (UTC) FILETIME=[A85A24B0:01C4C326] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hello All, As a new outsider to this discussion I have some questions: 1) EUSM allows the SNMP agent/manager to cash the localized key for some time. How long ? When will it loose it's validity ? 2) If the localized key has to be requested again after every n-th SNMP transaction this means that every n-th UDP package will need additional RADIUS traffic. How many additional packets/transactions does this mean ? 3) If the Radius server is unreachable is the SNMPv3 traffic according to EUASM dead ? Or ? Balazs Randy Presuhn wrote: > Hi - > > Page16 of draft-kaushik-snmp-external-usm-00.txt describes > how a RADIUS server will generate a localized key. It says that the > server will have to have been configured with the set of SNMP Engine > IDs in use by the AAA server. What isn't clear to me from the text is > how the RADIUS server can know *which* of those SNMP Engine IDs > to use in key localization. > > The RADIUS key request from the SNMPv3 agent carries the SNMP > manager's IP address, (as the "Calling-Station-ID") and the user > name (as the "User-Name"), but there's nothing for the agent's SNMP > Engine ID. > > Randy > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms -- Balazs Lengyel Ericsson Hungary Ltd. AXD Operational Suite (AOS) OPM & System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 5 12:39:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01480; Fri, 5 Nov 2004 12:39:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ8J4-0008IN-9N; Fri, 05 Nov 2004 12:55:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ7s5-0000lb-8m; Fri, 05 Nov 2004 12:27:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ7cC-0004De-FJ for isms@megatron.ietf.org; Fri, 05 Nov 2004 12:11:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29464 for ; Fri, 5 Nov 2004 12:11:05 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ7rx-0007kM-DE for isms@ietf.org; Fri, 05 Nov 2004 12:27:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 09:21:27 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA5HAVom010639; Fri, 5 Nov 2004 09:10:31 -0800 (PST) Received: from kaushik-w2k02.cisco.com ([128.107.169.142]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVJ83196; Fri, 5 Nov 2004 09:05:36 -0800 (PST) Message-Id: <6.0.0.22.0.20041105090438.03bb1610@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Nov 2004 09:10:30 -0800 To: randy_presuhn@mindspring.com From: Kaushik Narayan Subject: Re: Fwd: [Isms] EUSM key localization details In-Reply-To: <20041105170210.69661.qmail@web11329.mail.yahoo.com> References: <20041105170210.69661.qmail@web11329.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi Randy, Please find my reply inline. >Hi - > >Page16 of draft-kaushik-snmp-external-usm-00.txt describes >how a RADIUS server will generate a localized key. It says that the >server will have to have been configured with the set of SNMP Engine >IDs in use by the AAA server. What isn't clear to me from the text is >how the RADIUS server can know *which* of those SNMP Engine IDs >to use in key localization. Administrators MUST configure the SNMP-Engine-ID on the AAA server as part of the AAA client configuration for the SNMP agents. This will help the AAA server locate the SNMP-Engine-ID for the agent that is requesting keys. >The RADIUS key request from the SNMPv3 agent carries the SNMP >manager's IP address, (as the "Calling-Station-ID") and the user >name (as the "User-Name"), but there's nothing for the agent's SNMP >Engine ID. We did not want the agents to pass the SNMP-Engine-ID since a compromised agent can acquire localized keys for other agents. regards, kaushik! >Randy > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 5 12:39:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01556; Fri, 5 Nov 2004 12:39:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ8Jr-0008KA-95; Fri, 05 Nov 2004 12:56:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ7s6-0000my-MN; Fri, 05 Nov 2004 12:27:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ7dF-0004Ux-SM for isms@megatron.ietf.org; Fri, 05 Nov 2004 12:12:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29499 for ; Fri, 5 Nov 2004 12:12:11 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ7t1-0007lf-QC for isms@ietf.org; Fri, 05 Nov 2004 12:28:32 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 09:22:33 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA5HBZcp023131; Fri, 5 Nov 2004 09:11:35 -0800 (PST) Received: from kaushik-w2k02.cisco.com ([128.107.169.142]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVJ83280; Fri, 5 Nov 2004 09:06:37 -0800 (PST) Message-Id: <6.0.0.22.0.20041105083643.03bb19e8@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Nov 2004 09:11:32 -0800 To: Balazs Lengyel From: Kaushik Narayan Subject: Re: [Isms] EUSM key localization details In-Reply-To: <418B5D4A.9070407@ericsson.com> References: <000e01c4c2e4$80750060$7f1afea9@oemcomputer> <418B5D4A.9070407@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Hi Balazs, Please find my reply inline. At 03:00 AM 11/5/2004, Balazs Lengyel wrote: >Hello All, >As a new outsider to this discussion I have some questions: >1) EUSM allows the SNMP agent/manager to cash the localized key for some >time. How long ? When will it loose it's validity ? That has been described in the EUSM proposal. The key-cache-time will be signalled by the AAA server to the SNMP agents as part of the key distribution response. >2) If the localized key has to be requested again after every n-th SNMP >transaction this means that every n-th UDP package will need additional >RADIUS traffic. How many additional packets/transactions does this mean ? The key-cache-time is a configurable parameter on the AAA server and administrators can configure the time window based on the typical patterns. It is advisable that this window be in the order of 90-180 seconds since that this is the typical duration of job/operation. There aren't any fixed SNMP transactions in a session, it depends on the operation and the key-cache-time. >3) If the Radius server is unreachable is the SNMPv3 traffic according to >EUASM dead ? Or ? That has been specified in the proposal as well, agents will use USM in case the AAA server is down. regards, kaushik! >Balazs > >Randy Presuhn wrote: >>Hi - >>Page16 of draft-kaushik-snmp-external-usm-00.txt describes >>how a RADIUS server will generate a localized key. It says that the >>server will have to have been configured with the set of SNMP Engine >>IDs in use by the AAA server. What isn't clear to me from the text is >>how the RADIUS server can know *which* of those SNMP Engine IDs >>to use in key localization. >>The RADIUS key request from the SNMPv3 agent carries the SNMP >>manager's IP address, (as the "Calling-Station-ID") and the user >>name (as the "User-Name"), but there's nothing for the agent's SNMP >>Engine ID. >>Randy >> >>_______________________________________________ >>Isms mailing list >>Isms@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/isms > >-- >Balazs Lengyel Ericsson Hungary Ltd. >AXD Operational Suite (AOS) OPM & System Manager >ECN: 831 7320 Fax: +36 1 4377792 >Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 5 13:00:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03350; Fri, 5 Nov 2004 13:00:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ8dT-0000PI-2p; Fri, 05 Nov 2004 13:16:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ8N7-0007m6-FG; Fri, 05 Nov 2004 12:59:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ8Gm-0006Nn-8a for isms@megatron.ietf.org; Fri, 05 Nov 2004 12:53:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02813 for ; Fri, 5 Nov 2004 12:53:01 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ8WS-0000Eb-AY for isms@ietf.org; Fri, 05 Nov 2004 13:09:22 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 10:03:15 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA5HqLom008654 for ; Fri, 5 Nov 2004 09:52:22 -0800 (PST) Received: from kaushik-w2k02.cisco.com ([128.107.169.142]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVJ87423; Fri, 5 Nov 2004 09:47:24 -0800 (PST) Message-Id: <6.0.0.22.0.20041105095204.03ba2fc0@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Nov 2004 09:52:18 -0800 To: isms@ietf.org From: Kaushik Narayan Subject: Fwd: Re: [Isms] EUSM key localization details Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 > >Hi Balazs, > >Please find my reply inline. > > >At 09:25 AM 11/5/2004, Balazs Lengyel wrote: >>Hello Kausik, >>Tanks for the answers. >>- If Radius is unavailable we ought to use USM. But how is this USM >>configured ? Does it take the last valid EUSM key or are we back to >>normal USM configuration problems ? > > >The expectation is that USM users are configured for backup. The SNMPv3 >agent will continue to use the cached keys until they expire, after expiration >if the agent is unable to acquire keys from the AAA server (server is >down), the >agent will fallback to USM. This is no different from configuration of >local users > for fallback for CLI access. > >>- Why is it advisable to have a new key for each transaction (90-180 >>sec)? Is that not "too" secure a bit ? In my area we have quite a bit of >>SNMP traffic e.g. we can get performance measurements every 15 seconds. >>Asking for a fresh password every 180 sec in this case seems a bit overkill. > > >That's the reason we have a configurable cache-key-time, typically >configuration jobs, periodic inventory collection would have a time >window of about 90-180 seconds. Periodic performance collection >has a completely different characteristic and the key-cache-time >might be configured to provide for larger window. > >regards, > kaushik! > > >>Regards Balazs >> >>Kaushik Narayan wrote: >>>Hi Balazs, >>>Please find my reply inline. >>> >>>At 03:00 AM 11/5/2004, Balazs Lengyel wrote: >>> >>>>Hello All, >>>>As a new outsider to this discussion I have some questions: >>>>1) EUSM allows the SNMP agent/manager to cash the localized key for >>>>some time. How long ? When will it loose it's validity ? >>> >>>That has been described in the EUSM proposal. The key-cache-time will >>>be signalled by the AAA server to the SNMP agents as part of the key >>>distribution response. >>> >>>>2) If the localized key has to be requested again after every n-th SNMP >>>>transaction this means that every n-th UDP package will need >>>>additional RADIUS traffic. How many additional packets/transactions >>>>does this mean ? >>> >>>The key-cache-time is a configurable parameter on the AAA server and >>>administrators can configure the time window based on the typical >>>patterns. It is advisable that this window be in the order of 90-180 >>>seconds since that this is the typical duration of job/operation. >>>There aren't any fixed SNMP transactions in a session, it depends on >>>the operation and the key-cache-time. >>> >>> >>>>3) If the Radius server is unreachable is the SNMPv3 traffic according >>>>to EUASM dead ? Or ? >>> >>>That has been specified in the proposal as well, agents will use USM in >>>case the AAA server is down. >>>regards, >>> kaushik! >>> >>> >>>>Balazs >>>> >>>>Randy Presuhn wrote: >>>> >>>>>Hi - >>>>>Page16 of draft-kaushik-snmp-external-usm-00.txt describes >>>>>how a RADIUS server will generate a localized key. It says that the >>>>>server will have to have been configured with the set of SNMP Engine >>>>>IDs in use by the AAA server. What isn't clear to me from the text is >>>>>how the RADIUS server can know *which* of those SNMP Engine IDs >>>>>to use in key localization. >>>>>The RADIUS key request from the SNMPv3 agent carries the SNMP >>>>>manager's IP address, (as the "Calling-Station-ID") and the user >>>>>name (as the "User-Name"), but there's nothing for the agent's SNMP >>>>>Engine ID. >>>>>Randy >>>>> >>>>>_______________________________________________ >>>>>Isms mailing list >>>>>Isms@lists.ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/isms >>>> >>>> >>>>-- >>>>Balazs Lengyel Ericsson Hungary Ltd. >>>>AXD Operational Suite (AOS) OPM & System Manager >>>>ECN: 831 7320 Fax: +36 1 4377792 >>>>Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com >>>> >>>>_______________________________________________ >>>>Isms mailing list >>>>Isms@lists.ietf.org >>>>https://www1.ietf.org/mailman/listinfo/isms >> >>-- >>Balazs Lengyel Ericsson Hungary Ltd. >>AXD Operational Suite (AOS) OPM & System Manager >>ECN: 831 7320 Fax: +36 1 4377792 >>Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 5 15:16:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13339; Fri, 5 Nov 2004 15:16:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQAlB-00033Z-1K; Fri, 05 Nov 2004 15:32:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAP1-0004Hu-M1; Fri, 05 Nov 2004 15:09:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQADt-00038O-NJ for isms@megatron.ietf.org; Fri, 05 Nov 2004 14:58:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11283 for ; Fri, 5 Nov 2004 14:58:11 -0500 (EST) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQATh-0002gr-0Z for isms@ietf.org; Fri, 05 Nov 2004 15:14:33 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 6202B11D9A4; Fri, 5 Nov 2004 11:58:09 -0800 (PST) To: Kaushik Narayan Subject: Re: Fwd: [Isms] EUSM key localization details References: <20041105170210.69661.qmail@web11329.mail.yahoo.com> <6.0.0.22.0.20041105090438.03bb1610@mira-sjc5-a.cisco.com> From: Wes Hardaker Organization: Sparta Date: Fri, 05 Nov 2004 11:58:09 -0800 In-Reply-To: <6.0.0.22.0.20041105090438.03bb1610@mira-sjc5-a.cisco.com> (Kaushik Narayan's message of "Fri, 05 Nov 2004 09:10:30 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >>>>> On Fri, 05 Nov 2004 09:10:30 -0800, Kaushik Narayan said: Kaushik> Administrators MUST configure the SNMP-Engine-ID on the AAA Kaushik> server as part of the AAA client configuration for the SNMP Kaushik> agents. This will help the AAA server locate the Kaushik> SNMP-Engine-ID for the agent that is requesting keys. That's not very scalable though. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 5 17:52:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27556; Fri, 5 Nov 2004 17:52:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQCwo-0006rz-6J; Fri, 05 Nov 2004 17:52:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQCop-0004gn-8k; Fri, 05 Nov 2004 17:44:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQClx-0003uw-UJ for isms@megatron.ietf.org; Fri, 05 Nov 2004 17:41:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26713 for ; Fri, 5 Nov 2004 17:41:31 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQClx-0006bv-0w for isms@ietf.org; Fri, 05 Nov 2004 17:41:34 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 05 Nov 2004 14:54:06 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA5Mewcp011320; Fri, 5 Nov 2004 14:40:59 -0800 (PST) Received: from kaushik-w2k02.cisco.com ([128.107.169.142]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVK20627; Fri, 5 Nov 2004 14:36:00 -0800 (PST) Message-Id: <6.0.0.22.0.20041105130509.03bac240@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Nov 2004 14:40:58 -0800 To: Wes Hardaker From: Kaushik Narayan Subject: Re: Fwd: [Isms] EUSM key localization details In-Reply-To: References: <20041105170210.69661.qmail@web11329.mail.yahoo.com> <6.0.0.22.0.20041105090438.03bb1610@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi Wes, We have discussed the scalibility issue since manually configuring the AAA server with all SNMP engine IDs can be really tedious and were looking at optimization where we had the SNMP agent pass the SNMP engine ID and the AAA server would verify that engine ID if it was configured or accept the SNMP engine ID passed by the agent if none is configured. regards, kaushik! At 11:58 AM 11/5/2004, Wes Hardaker wrote: > >>>>> On Fri, 05 Nov 2004 09:10:30 -0800, Kaushik Narayan > said: > >Kaushik> Administrators MUST configure the SNMP-Engine-ID on the AAA >Kaushik> server as part of the AAA client configuration for the SNMP >Kaushik> agents. This will help the AAA server locate the >Kaushik> SNMP-Engine-ID for the agent that is requesting keys. > >That's not very scalable though. > > >-- >Wes Hardaker >Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 5 18:41:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01587; Fri, 5 Nov 2004 18:41:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDiE-0007oE-8E; Fri, 05 Nov 2004 18:41:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDWm-0003om-R9; Fri, 05 Nov 2004 18:29:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDRi-0002tQ-Qs for isms@megatron.ietf.org; Fri, 05 Nov 2004 18:24:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00655 for ; Fri, 5 Nov 2004 18:24:39 -0500 (EST) Message-Id: <200411052324.SAA00655@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDRj-0007TU-8a for isms@ietf.org; Fri, 05 Nov 2004 18:24:43 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004110523240901300c052he>; Fri, 5 Nov 2004 23:24:10 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" , "'Wes Hardaker'" Subject: RE: Fwd: [Isms] EUSM key localization details Date: Fri, 5 Nov 2004 18:24:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTDiin0bCM9mvR3Swms/al9adiOTAAA837A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <6.0.0.22.0.20041105130509.03bac240@mira-sjc5-a.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit If the AAA server doesn't recognize the engineID, what authorization does it give by default? I would expect that the AAA server would need to know which group permissions should be given to a user on a per-device basis. This could be handled by simply associating the user toa group, and then configuring only certain groups to certain devices, but that makes the configuration of VACM more difficult. At some point the difficulty of configuring engineIDs into a centralized AAA server may be easier than configuring different VACM policies onto different devices. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan > Sent: Friday, November 05, 2004 5:41 PM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: Fwd: [Isms] EUSM key localization details > > Hi Wes, > > We have discussed the scalibility issue since manually > configuring the AAA server with all SNMP engine IDs can be > really tedious and were looking at optimization where we had > the SNMP agent pass the SNMP engine ID and the AAA server > would verify that engine ID if it was configured or accept > the SNMP engine ID passed by the agent if none is configured. > > regards, > kaushik! > > At 11:58 AM 11/5/2004, Wes Hardaker wrote: > > >>>>> On Fri, 05 Nov 2004 09:10:30 -0800, Kaushik Narayan > > said: > > > >Kaushik> Administrators MUST configure the SNMP-Engine-ID on the AAA > >Kaushik> server as part of the AAA client configuration for the SNMP > >Kaushik> agents. This will help the AAA server locate the > >Kaushik> SNMP-Engine-ID for the agent that is requesting keys. > > > >That's not very scalable though. > > > > > >-- > >Wes Hardaker > >Sparta > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 5 20:11:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08992; Fri, 5 Nov 2004 20:11:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQF7U-0001gO-VC; Fri, 05 Nov 2004 20:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQExm-0000zw-ND; Fri, 05 Nov 2004 20:01:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEt8-0007XA-N0 for isms@megatron.ietf.org; Fri, 05 Nov 2004 19:57:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07637 for ; Fri, 5 Nov 2004 19:57:03 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQEt9-0001AI-1i for isms@ietf.org; Fri, 05 Nov 2004 19:57:08 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 05 Nov 2004 17:09:39 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA60uRom019234; Fri, 5 Nov 2004 16:56:28 -0800 (PST) Received: from kaushik-w2k02.cisco.com ([128.107.169.142]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVK32254; Fri, 5 Nov 2004 16:51:31 -0800 (PST) Message-Id: <6.0.0.22.0.20041105154242.03c180f8@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 05 Nov 2004 16:56:30 -0800 To: From: Kaushik Narayan Subject: RE: Fwd: [Isms] EUSM key localization details In-Reply-To: <3fjeto$a46n4@sj-inbound-b.cisco.com> References: <6.0.0.22.0.20041105130509.03bac240@mira-sjc5-a.cisco.com> <3fjeto$a46n4@sj-inbound-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hi Dave, The authorization of the engine IDs can be done via a variety of policies including user groups assigned to the user. In most of our prototype work we have had the AAA server import the devices and their engine IDs from SNMP Manager. regards, kaushik! At 03:24 PM 11/5/2004, David B Harrington wrote: >If the AAA server doesn't recognize the engineID, what authorization >does it give by default? >I would expect that the AAA server would need to know which group >permissions should be given to a user on a per-device basis. > >This could be handled by simply associating the user toa group, and >then configuring only certain groups to certain devices, but that >makes the configuration of VACM more difficult. At some point the >difficulty of configuring engineIDs into a centralized AAA server may >be easier than configuring different VACM policies onto different >devices. > >David Harrington >dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan > > Sent: Friday, November 05, 2004 5:41 PM > > To: Wes Hardaker > > Cc: isms@ietf.org > > Subject: Re: Fwd: [Isms] EUSM key localization details > > > > Hi Wes, > > > > We have discussed the scalibility issue since manually > > configuring the AAA server with all SNMP engine IDs can be > > really tedious and were looking at optimization where we had > > the SNMP agent pass the SNMP engine ID and the AAA server > > would verify that engine ID if it was configured or accept > > the SNMP engine ID passed by the agent if none is configured. > > > > regards, > > kaushik! > > > > At 11:58 AM 11/5/2004, Wes Hardaker wrote: > > > >>>>> On Fri, 05 Nov 2004 09:10:30 -0800, Kaushik Narayan > > > said: > > > > > >Kaushik> Administrators MUST configure the SNMP-Engine-ID on the >AAA > > >Kaushik> server as part of the AAA client configuration for the >SNMP > > >Kaushik> agents. This will help the AAA server locate the > > >Kaushik> SNMP-Engine-ID for the agent that is requesting keys. > > > > > >That's not very scalable though. > > > > > > > > >-- > > >Wes Hardaker > > >Sparta > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Nov 6 00:26:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26346; Sat, 6 Nov 2004 00:26:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQJ5V-0006jr-Cn; Sat, 06 Nov 2004 00:26:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQJ3a-0002V2-F7; Sat, 06 Nov 2004 00:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQIzG-0001iY-SP for isms@megatron.ietf.org; Sat, 06 Nov 2004 00:19:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26091 for ; Sat, 6 Nov 2004 00:19:39 -0500 (EST) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQIzH-0006er-Lp for isms@ietf.org; Sat, 06 Nov 2004 00:19:46 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id A0E7E11D9A4; Fri, 5 Nov 2004 21:19:33 -0800 (PST) To: Kaushik Narayan Subject: Re: Fwd: [Isms] EUSM key localization details References: <6.0.0.22.0.20041105130509.03bac240@mira-sjc5-a.cisco.com> <3fjeto$a46n4@sj-inbound-b.cisco.com> <6.0.0.22.0.20041105154242.03c180f8@mira-sjc5-a.cisco.com> From: Wes Hardaker Organization: Sparta Date: Fri, 05 Nov 2004 21:19:33 -0800 In-Reply-To: <6.0.0.22.0.20041105154242.03c180f8@mira-sjc5-a.cisco.com> (Kaushik Narayan's message of "Fri, 05 Nov 2004 16:56:30 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c >>>>> On Fri, 05 Nov 2004 16:56:30 -0800, Kaushik Narayan said: Kaushik> In most of our prototype work we have had the AAA server Kaushik> import the devices and their engine IDs from SNMP Manager. Chicken, meet Egg. Egg, meet Chicken. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Nov 6 13:42:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26987; Sat, 6 Nov 2004 13:42:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQVWj-00040C-Im; Sat, 06 Nov 2004 13:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQVQf-0000nt-4a; Sat, 06 Nov 2004 13:36:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQVOO-0000Wj-SB for isms@megatron.ietf.org; Sat, 06 Nov 2004 13:34:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26460 for ; Sat, 6 Nov 2004 13:34:25 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQVOY-0003sd-SX for isms@ietf.org; Sat, 06 Nov 2004 13:34:40 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2004 10:45:00 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA6IXscp021725; Sat, 6 Nov 2004 10:33:54 -0800 (PST) Received: from kaushik-w2k02.cisco.com (sjc-vpn2-710.cisco.com [10.21.114.198]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVK50801; Sat, 6 Nov 2004 10:28:46 -0800 (PST) Message-Id: <6.0.0.22.0.20041106101614.031f0260@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 06 Nov 2004 10:33:44 -0800 To: Wes Hardaker From: Kaushik Narayan Subject: Re: Fwd: [Isms] EUSM key localization details In-Reply-To: References: <6.0.0.22.0.20041105130509.03bac240@mira-sjc5-a.cisco.com> <3fjeto$a46n4@sj-inbound-b.cisco.com> <6.0.0.22.0.20041105154242.03c180f8@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi Wes, Actually it was not a chicken and egg problem with EUSM since the process for Discovery of engine IDs for authoritative agents still stays the same as described in RFC3414, i.e. we continue to use a Request message with a securityLevel of noAuthNoPriv and the response to this message will be a Report message containing the snmpEngineID. This would mean that agents do-not need to acquire keys to serve an SNMPv3 engine ID discovery request and SNMP Managers can discovery engine IDs and bootstrap the AAA server. regards, kaushik! At 09:19 PM 11/5/2004, Wes Hardaker wrote: > >>>>> On Fri, 05 Nov 2004 16:56:30 -0800, Kaushik Narayan > said: > >Kaushik> In most of our prototype work we have had the AAA server >Kaushik> import the devices and their engine IDs from SNMP Manager. > >Chicken, meet Egg. Egg, meet Chicken. > >-- >Wes Hardaker >Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Nov 7 22:52:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01849; Sun, 7 Nov 2004 22:52:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR0ai-0004lK-49; Sun, 07 Nov 2004 22:53:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR0WU-00063f-W5; Sun, 07 Nov 2004 22:48:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR0VP-0005Vs-W8 for isms@megatron.ietf.org; Sun, 07 Nov 2004 22:47:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01431 for ; Sun, 7 Nov 2004 22:47:45 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR0Vs-0004d0-Fh for isms@ietf.org; Sun, 07 Nov 2004 22:48:16 -0500 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id iA83lDHP016099; Sun, 7 Nov 2004 19:47:13 -0800 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) (authenticated bits=0) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id iA83lBvC005638; Sun, 7 Nov 2004 19:47:13 -0800 Message-Id: <5.2.0.9.2.20041107192759.02886e40@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 07 Nov 2004 19:41:19 -0800 To: Juergen Quittek , isms@ietf.org From: "David T. Perkins" Subject: Re: [Isms] ISMS solution selection procedure In-Reply-To: <1171138004.1095960180@[10.1.1.171]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 HI, Back in the BOFs I presented some slides that went through the scenarios with regards to what was needed to be done in the operations that have to do with security. That is, for operational actions such as deploying a new device (such as a router), adding access for a new user, removing access for a user, changing a user's secrets, etc, what were the additional steps that had to be taken for SNMP. And by additional steps, it was the realization that a large majority of devices already used other management interfaces (such as a command line via serial line or via SSH, or Web Browser) that had to be set up for security, and that if nothing else was needed to be done for SNMP, then the goal of integration had occured. So, I suggest that the selection procedure consist of listing the operational tasks. And then list the actions needed to support each operational task for each ISMS proposal with each of the leading security authentication infrastructures/methods. Once this is done, if a clear choice is not obvious, then additional approaches can also be used. Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 8 03:07:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08028; Mon, 8 Nov 2004 03:07:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR4Ye-0001ZV-0V; Mon, 08 Nov 2004 03:07:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR4XR-0005SJ-DK; Mon, 08 Nov 2004 03:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR4TB-0004y8-EN for isms@megatron.ietf.org; Mon, 08 Nov 2004 03:01:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07467 for ; Mon, 8 Nov 2004 03:01:43 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR4Tg-0001TG-3Y for isms@ietf.org; Mon, 08 Nov 2004 03:02:16 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iA881XvD022463 for ; Mon, 8 Nov 2004 09:01:33 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Nov 2004 09:01:32 +0100 Received: from [159.107.196.23] (mwlx004.eth.ericsson.se [159.107.196.23]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WHL3V5X6; Mon, 8 Nov 2004 09:01:31 +0100 Message-ID: <418F27DE.6030809@ericsson.com> Date: Mon, 08 Nov 2004 09:01:34 +0100 X-Sybari-Trust: c013f395 bfd556f1 72bdc7df 00000139 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: isms@ietf.org Subject: Re: Fwd: Re: [Isms] EUSM key localization details References: <6.0.0.22.0.20041105095204.03ba2fc0@mira-sjc5-a.cisco.com> In-Reply-To: <6.0.0.22.0.20041105095204.03ba2fc0@mira-sjc5-a.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2004 08:01:32.0057 (UTC) FILETIME=[28D60890:01C4C569] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Hello Kaushik, An even more basic question: If the problem with SNMPv3 was only that it is difficult to manage keys why don't we just let radius to assign the keys that the real USM can use for a long time ? Then we could let it be the administrators job to decide if he wants to change keys every 2 minutes or every two months. Is it really a design goal to push the administrators into using short lived keys (60-180 sec) ? Or in other words, do you see problems with setting the cache period to 2 months ? If Radius is unavailable why can't we just keep on using the last valid EUSM keys in USM this way we might avoid the need to configure USM as a backup. regards Balazs Kaushik Narayan wrote: > >> >> Hi Balazs, >> >> Please find my reply inline. >> >> >> At 09:25 AM 11/5/2004, Balazs Lengyel wrote: >> >>> Hello Kausik, >>> Tanks for the answers. >>> - If Radius is unavailable we ought to use USM. But how is this USM >>> configured ? Does it take the last valid EUSM key or are we back to >>> normal USM configuration problems ? >> >> >> >> The expectation is that USM users are configured for backup. The SNMPv3 >> agent will continue to use the cached keys until they expire, after >> expiration >> if the agent is unable to acquire keys from the AAA server (server is >> down), the >> agent will fallback to USM. This is no different from configuration of >> local users >> for fallback for CLI access. >> >>> - Why is it advisable to have a new key for each transaction (90-180 >>> sec)? Is that not "too" secure a bit ? In my area we have quite a bit >>> of SNMP traffic e.g. we can get performance measurements every 15 >>> seconds. Asking for a fresh password every 180 sec in this case seems >>> a bit overkill. >> >> >> >> That's the reason we have a configurable cache-key-time, typically >> configuration jobs, periodic inventory collection would have a time >> window of about 90-180 seconds. Periodic performance collection >> has a completely different characteristic and the key-cache-time >> might be configured to provide for larger window. >> >> regards, >> kaushik! >> >> >>> Regards Balazs >>> >>> Kaushik Narayan wrote: >>> >>>> Hi Balazs, >>>> Please find my reply inline. >>>> >>>> At 03:00 AM 11/5/2004, Balazs Lengyel wrote: >>>> >>>>> Hello All, >>>>> As a new outsider to this discussion I have some questions: >>>>> 1) EUSM allows the SNMP agent/manager to cash the localized key for >>>>> some time. How long ? When will it loose it's validity ? >>>> >>>> >>>> That has been described in the EUSM proposal. The key-cache-time will >>>> be signalled by the AAA server to the SNMP agents as part of the key >>>> distribution response. >>>> >>>>> 2) If the localized key has to be requested again after every n-th >>>>> SNMP transaction this means that every n-th UDP package will need >>>>> additional RADIUS traffic. How many additional packets/transactions >>>>> does this mean ? >>>> >>>> >>>> The key-cache-time is a configurable parameter on the AAA server and >>>> administrators can configure the time window based on the typical >>>> patterns. It is advisable that this window be in the order of 90-180 >>>> seconds since that this is the typical duration of job/operation. >>>> There aren't any fixed SNMP transactions in a session, it depends on >>>> the operation and the key-cache-time. >>>> >>>> >>>>> 3) If the Radius server is unreachable is the SNMPv3 traffic >>>>> according to EUASM dead ? Or ? >>>> >>>> >>>> That has been specified in the proposal as well, agents will use USM in >>>> case the AAA server is down. >>>> regards, >>>> kaushik! >>>> >>>> >>>>> Balazs >>>>> >>>>> Randy Presuhn wrote: >>>>> >>>>>> Hi - >>>>>> Page16 of draft-kaushik-snmp-external-usm-00.txt describes >>>>>> how a RADIUS server will generate a localized key. It says that the >>>>>> server will have to have been configured with the set of SNMP Engine >>>>>> IDs in use by the AAA server. What isn't clear to me from the >>>>>> text is >>>>>> how the RADIUS server can know *which* of those SNMP Engine IDs >>>>>> to use in key localization. >>>>>> The RADIUS key request from the SNMPv3 agent carries the SNMP >>>>>> manager's IP address, (as the "Calling-Station-ID") and the user >>>>>> name (as the "User-Name"), but there's nothing for the agent's SNMP >>>>>> Engine ID. >>>>>> Randy >>>>>> >>>>>> _______________________________________________ >>>>>> Isms mailing list >>>>>> Isms@lists.ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/isms >>>>> >>>>> >>>>> >>>>> -- >>>>> Balazs Lengyel Ericsson Hungary Ltd. >>>>> AXD Operational Suite (AOS) OPM & System Manager >>>>> ECN: 831 7320 Fax: +36 1 4377792 >>>>> Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com >>>>> >>>>> _______________________________________________ >>>>> Isms mailing list >>>>> Isms@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/isms >>> >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> AXD Operational Suite (AOS) OPM & System Manager >>> ECN: 831 7320 Fax: +36 1 4377792 >>> Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > -- Balazs Lengyel Ericsson Hungary Ltd. AXD Operational Suite (AOS) OPM & System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 8 14:44:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19516; Mon, 8 Nov 2004 14:44:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFRc-0003F2-Pn; Mon, 08 Nov 2004 14:44:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRF33-0007rH-II; Mon, 08 Nov 2004 14:19:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREys-0005gi-I9 for isms@megatron.ietf.org; Mon, 08 Nov 2004 14:15:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16218 for ; Mon, 8 Nov 2004 14:15:08 -0500 (EST) Message-Id: <200411081915.OAA16218@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREzS-0002IZ-LU for isms@ietf.org; Mon, 08 Nov 2004 14:15:47 -0500 Received: from djyxpy41 (unknown[130.129.134.230]) by comcast.net (sccrmhc12) with SMTP id <20041108191438012008umshe> (Authid: ietfdbh); Mon, 8 Nov 2004 19:14:38 +0000 From: "David B Harrington" To: "'Wes Hardaker'" Subject: RE: [Isms] Revised TLS proposal Date: Mon, 8 Nov 2004 14:14:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTC1ZI1qIEtfCR4SpOQA389eAhgaQC8QAZg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit The SHOULD refers to using the specific protocol, with the specific level of authentication. It is my understanding that the TLS Handshake Protocol is one option for atuthentication, which might be superceded in the future, so it can only be a SHOULD. I have no difficulty requiring mutual authentication when TLS Handshake is used. dbh > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Thursday, November 04, 2004 8:20 PM > To: ietfdbh@comcast.net > Cc: isms@ietf.org > Subject: Re: [Isms] Revised TLS proposal > > >>>>> On Thu, 4 Nov 2004 18:30:20 -0500, "David B Harrington" > said: > > > David> The TLS TM-security model SHOULD use the TLS Handshake > Protocol > David> with mutual authentication. > > [I'm assuming at least auth here for the sake of the > following discussion] > > IMHO, this should be a MUST. Doing anything less is actually > arguably less secure than USM, which authenticates both sides > (admittedly with the same key, but both sides can be proven > to be the correct correspondence assuming no compromise has > taken place). With your above statement, it means that no > equal confidence can be made when using TLS. > > -- > Wes Hardaker > Sparta > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 9 13:46:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29358; Tue, 9 Nov 2004 13:46:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRb1w-0003Dz-BW; Tue, 09 Nov 2004 13:47:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRapb-0000EG-0R; Tue, 09 Nov 2004 13:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRapF-0008Tb-8H for isms@megatron.ietf.org; Tue, 09 Nov 2004 13:34:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28172 for ; Tue, 9 Nov 2004 13:34:37 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRaps-0002vb-DU for isms@ietf.org; Tue, 09 Nov 2004 13:35:31 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA06631; Tue, 9 Nov 2004 10:33:43 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iA9IXgZ08669; Tue, 9 Nov 2004 10:33:42 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Nov 2004 10:33:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fwd: Re: [Isms] EUSM key localization details Date: Tue, 9 Nov 2004 10:33:41 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD9C0@xch-nw-09.nw.nos.boeing.com> Thread-Topic: Fwd: Re: [Isms] EUSM key localization details Thread-Index: AcTFaf3AB3OEfjEgRrWktlIzdksKDQBG0GhQ From: "Fleischman, Eric" To: "Balazs Lengyel" , X-OriginalArrivalTime: 09 Nov 2004 18:33:42.0251 (UTC) FILETIME=[A36813B0:01C4C68A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Balazs, The key management problem is indeed an issue (i.e., SNMPv3 deployments are often operationally insecure). However, the following is my list of what I believe to be the problems with SNMP security (listed in order of increasing importance): 1) no provisions for two-factored authentication 2) SNMP symmetric keys may be assembled from passwords 3) Key updates do not provide for Perfect Forward Security 4) Inherent Symmetric Key distribution problems 5) Lack of viable session keys I want to encourage your thoughts about using Radius. However, I also want to encourage Kerberos and PKI-based solutions since each of these are viable enterprise-wide solutions. The fact that in my analysis PKI solutions are the best alternative for our company's networks does not mean that other companies wouldn't be better served by a Kerberos or Radius solution. However, it does mean that I would like the ultimate solution to be also able to support PKI. --Eric -----Original Message----- From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]=20 Sent: Monday, November 08, 2004 12:02 AM To: isms@ietf.org Subject: Re: Fwd: Re: [Isms] EUSM key localization details Hello Kaushik, An even more basic question: If the problem with SNMPv3 was only that it is difficult to=20 manage keys why don't we just let radius to assign the keys that the real USM can use for a=20 long time ? Then we could let it be the administrators job to decide if he wants to change=20 keys every 2 minutes or every two months. Is it really a design goal to push the administrators into using short lived keys (60-180=20 sec) ? Or in other words, do you see problems with setting the cache period to 2 months ? If Radius is unavailable why can't we just keep on using the last valid EUSM keys in USM=20 this way we might avoid the need to configure USM as a backup. regards Balazs _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 9 14:54:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05526; Tue, 9 Nov 2004 14:54:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRc59-0004qY-0P; Tue, 09 Nov 2004 14:55:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbvZ-0004ws-7m; Tue, 09 Nov 2004 14:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbsv-0004H9-SJ for isms@megatron.ietf.org; Tue, 09 Nov 2004 14:42:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04723 for ; Tue, 9 Nov 2004 14:42:32 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbtj-0004aV-Pa for isms@ietf.org; Tue, 09 Nov 2004 14:43:24 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2004 11:53:41 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA9Jfwcp007896; Tue, 9 Nov 2004 11:41:59 -0800 (PST) Received: from kaushik-w2k02.cisco.com (dhcp-171-71-254-119.cisco.com [171.71.254.119]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVM15184; Tue, 9 Nov 2004 11:36:15 -0800 (PST) Message-Id: <6.0.0.22.0.20041109113700.03897988@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 09 Nov 2004 11:41:58 -0800 To: Balazs Lengyel From: Kaushik Narayan Subject: Re: Fwd: Re: [Isms] EUSM key localization details In-Reply-To: <418F27DE.6030809@ericsson.com> References: <6.0.0.22.0.20041105095204.03ba2fc0@mira-sjc5-a.cisco.com> <418F27DE.6030809@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Hi Balazs, Please find my reply inline. At 12:01 AM 11/8/2004, Balazs Lengyel wrote: >Hello Kaushik, >An even more basic question: If the problem with SNMPv3 was only that it >is difficult to manage keys why don't we just let radius to assign the >keys that the real USM can use for a long time ? Then we could let it be >the administrators job to decide if he wants to change keys every 2 >minutes or every two months. > >Is it really a design goal to push the administrators into using short >lived keys (60-180 sec) ? Or in other words, do you see problems with >setting the cache period to 2 months ? The problem with long lasting keys is that there isn't a scheme for revocation described in Radius. The proposal does not try to limit the use of the key lifetime to 60-180 seconds but definitely does not believe that the time should be any where around 2 months given the inability for revocation. >If Radius is unavailable why can't we just keep on using the last valid >EUSM keys in USM this way we might avoid the need to configure USM as a backup. The configuration of backup is required since other means of management such as CLI require local accounts. I also believe that the way to handle the fallback case is to make AAA services more available rather trying to define schemes that involve caching keys for long durations. regards, kaushik! >regards Balazs > >Kaushik Narayan wrote: >> >>> >>>Hi Balazs, >>> >>>Please find my reply inline. >>> >>> >>>At 09:25 AM 11/5/2004, Balazs Lengyel wrote: >>> >>>>Hello Kausik, >>>>Tanks for the answers. >>>>- If Radius is unavailable we ought to use USM. But how is this USM >>>>configured ? Does it take the last valid EUSM key or are we back to >>>>normal USM configuration problems ? >>> >>> >>> >>>The expectation is that USM users are configured for backup. The SNMPv3 >>>agent will continue to use the cached keys until they expire, after >>>expiration >>>if the agent is unable to acquire keys from the AAA server (server is >>>down), the >>>agent will fallback to USM. This is no different from configuration of >>>local users >>> for fallback for CLI access. >>> >>>>- Why is it advisable to have a new key for each transaction (90-180 >>>>sec)? Is that not "too" secure a bit ? In my area we have quite a bit >>>>of SNMP traffic e.g. we can get performance measurements every 15 >>>>seconds. Asking for a fresh password every 180 sec in this case seems a >>>>bit overkill. >>> >>> >>> >>>That's the reason we have a configurable cache-key-time, typically >>>configuration jobs, periodic inventory collection would have a time >>>window of about 90-180 seconds. Periodic performance collection >>>has a completely different characteristic and the key-cache-time >>>might be configured to provide for larger window. >>> >>>regards, >>> kaushik! >>> >>> >>>>Regards Balazs >>>> >>>>Kaushik Narayan wrote: >>>> >>>>>Hi Balazs, >>>>>Please find my reply inline. >>>>> >>>>>At 03:00 AM 11/5/2004, Balazs Lengyel wrote: >>>>> >>>>>>Hello All, >>>>>>As a new outsider to this discussion I have some questions: >>>>>>1) EUSM allows the SNMP agent/manager to cash the localized key for >>>>>>some time. How long ? When will it loose it's validity ? >>>>> >>>>> >>>>>That has been described in the EUSM proposal. The key-cache-time will >>>>>be signalled by the AAA server to the SNMP agents as part of the key >>>>>distribution response. >>>>> >>>>>>2) If the localized key has to be requested again after every n-th >>>>>>SNMP transaction this means that every n-th UDP package will need >>>>>>additional RADIUS traffic. How many additional packets/transactions >>>>>>does this mean ? >>>>> >>>>> >>>>>The key-cache-time is a configurable parameter on the AAA server and >>>>>administrators can configure the time window based on the typical >>>>>patterns. It is advisable that this window be in the order of 90-180 >>>>>seconds since that this is the typical duration of job/operation. >>>>>There aren't any fixed SNMP transactions in a session, it depends on >>>>>the operation and the key-cache-time. >>>>> >>>>> >>>>>>3) If the Radius server is unreachable is the SNMPv3 traffic >>>>>>according to EUASM dead ? Or ? >>>>> >>>>> >>>>>That has been specified in the proposal as well, agents will use USM in >>>>>case the AAA server is down. >>>>>regards, >>>>> kaushik! >>>>> >>>>> >>>>>>Balazs >>>>>> >>>>>>Randy Presuhn wrote: >>>>>> >>>>>>>Hi - >>>>>>>Page16 of draft-kaushik-snmp-external-usm-00.txt describes >>>>>>>how a RADIUS server will generate a localized key. It says that the >>>>>>>server will have to have been configured with the set of SNMP Engine >>>>>>>IDs in use by the AAA server. What isn't clear to me from the text is >>>>>>>how the RADIUS server can know *which* of those SNMP Engine IDs >>>>>>>to use in key localization. >>>>>>>The RADIUS key request from the SNMPv3 agent carries the SNMP >>>>>>>manager's IP address, (as the "Calling-Station-ID") and the user >>>>>>>name (as the "User-Name"), but there's nothing for the agent's SNMP >>>>>>>Engine ID. >>>>>>>Randy >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Isms mailing list >>>>>>>Isms@lists.ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/isms >>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>>Balazs Lengyel Ericsson Hungary Ltd. >>>>>>AXD Operational Suite (AOS) OPM & System Manager >>>>>>ECN: 831 7320 Fax: +36 1 4377792 >>>>>>Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com >>>>>> >>>>>>_______________________________________________ >>>>>>Isms mailing list >>>>>>Isms@lists.ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/isms >>>> >>>> >>>>-- >>>>Balazs Lengyel Ericsson Hungary Ltd. >>>>AXD Operational Suite (AOS) OPM & System Manager >>>>ECN: 831 7320 Fax: +36 1 4377792 >>>>Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com >> >>_______________________________________________ >>Isms mailing list >>Isms@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/isms > >-- >Balazs Lengyel Ericsson Hungary Ltd. >AXD Operational Suite (AOS) OPM & System Manager >ECN: 831 7320 Fax: +36 1 4377792 >Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 9 15:49:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11534; Tue, 9 Nov 2004 15:49:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRcwq-00069R-IM; Tue, 09 Nov 2004 15:50:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcvG-0003z7-EK; Tue, 09 Nov 2004 15:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRctJ-0002fb-MY for isms@megatron.ietf.org; Tue, 09 Nov 2004 15:47:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11249 for ; Tue, 9 Nov 2004 15:46:59 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRcu7-00064c-RJ for isms@ietf.org; Tue, 09 Nov 2004 15:47:52 -0500 Received: from cmf.nrl.navy.mil ([130.129.135.57]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id iA9KkncB011852 for ; Tue, 9 Nov 2004 15:46:54 -0500 (EST) Message-Id: <200411092046.iA9KkncB011852@ginger.cmf.nrl.navy.mil> To: isms@ietf.org X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 09 Nov 2004 15:46:49 -0500 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: fc231bf912a450f71747fa7a4e3e2f5a Subject: [Isms] DRAFT minutes for ISMS X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1 Howdy all, Here is a draft minutes for the ISMS WG meeting yesterday. Please let me know if you have any comments or suggestions. Particularly let me know if I've misattributed something in the minutes. --Ken DRAFT Minutes for the Integrated Security Model for SNMPv3 (ISMS) WG IETF 61, November 8th, 2004 The meeting was opened by chairs Ken Hornstein (KH) and Juergen Quittek (JQ). (JQ) - Review of meeting goals Oct 4 cut off for proposal submission Nov we decide which solution Currently there are three proposals: SBSM - A higher-level approach EUSM - Straight forward extension of USM to support AAA TLSM - SNMP over TLS (or some other transport mapping service). Traditional agenda bashing was next (minor changes to the order were suggested, but the original agenda order was kept). (JQ) - procedure Question, due we want to create evaluation team to decide on which proposal? Wes Hardaker (Wes) - maybe only examine proposals that work group want (i.e. not necessarily all three) JQ - let's select criteria for proposal acceptance Unknown - Perhaps we should use proposals to drive requirements Wes - lets bring it back to talking about criteria again Dave Perkins (DP) - looking at what drives operations for the same, we should look at each proposal to see if we can reduce the pain level for managers to use and implement. Ken - Our charter: maximize usability in environment integration into existing infrastructures. must not modify SNMPv3 protocol should be compliant with SNMPV3 security model, RFC 3411/2 if at all possible, don't change any other protocols Unknown - make sure existing SNMPv3 support isn't changed Ken - we're still going over charter right now. Ken - discussion of per-PDU encryption on the list, regarding the ability to have different encryption/authentication per PDU Wes - point of order, what things are in scope at this point are we listing anything (i.e. goals and/or requirements?), JQ - we should make a difference between requirements and nice to haves Wes - I believe one of requirements is must not decrease security. Ken - technically that is not in charter Wes - It has been discussed before. Jürgen Schönwälder (JS) - what does that mean? Wes - we can't create a new protocol that doesn't provide same strengths that USM provides. But some of operators didn't like strengths USM provides, they send passwords in clear so that they can log in to the machines. i.e. they don't find USM usable, so there may be some question as to what strengths we need to support. But we should have encryption / authentication capability and the protection of breaking one client not breaking all clients. Unknown - Operators pass passwords in clear for convenience; they prefer convenience in this case instead of security. Jeff Case (JC) - I'm concerned about usability line derived from the charter, can it be broken into 4 things from the line in charter: usability, deployment success, minimize implementation cost, quick time to market... usability minimum implementation cost minimum deployment cost time to market JC - should we consider what they export/import restrictions in top countries in world so that the technology selected is acceptable to most/all of them Steve Belovin (SB) [AD] - we design technically sound protocols, let the lawyers fight over legal acceptability. Unknown - questioning usability, be clearer on what we do mean. Ken - example of problem with USM, large scale re-keying of passwords... In the eye of the beholder. JQ - usability, what functions are needed and how easy is it to use them Michael St.John? (MSJ) - should differentiate between agent and manager Sam Hartman (SH) - deployment ease : security should work with existing the authentication infrastructure you have Wes - operator desirability, operators have varying environments so we should have flexibility in ISMS, (within reasons). Would operators want to use it?, would someone actually start using it? JQ - desirability Wes - should we strike usability JQ - we're high in abstraction, we should be talking about a lower level DH - 7 (integration into infrastructure) should be split into two parts, management and security integration Ken - management is done by SNMP proper DH - snmp parity as example, it was nice and secure but one had to go to the box to configure. people use HP OV to find devices on network but had to configure box before it could be discovered, it wasn't usable. DP - somewhat different view that when someone deploys a new box, if they just plug it into the network, they have unreal expectations if they think the can, without configuration, manage it and manage it securely. Many different ways to do initial configuration, but something that may not be obvious to anyone is that wouldn't it be nice if they didn't have to do anything extra to integrate with SNMPv3. Should go through use cases. DH - said you disagreed with what I said, but I just meant we should be able to do discovery DP - but I disagree, you should need to configure a box when putting it on a network DH - but I want to find a rogue box put on network. Ken - I think both are compatible DP - but different way of looking on world, a manager will need to configure any device put on network Unknown - don't break basic discovery. JQ - let's move this discussion off-line Unknown - we should support engine ID discovery for example JQ - on the list we have integration into infrastructure, let's keep requirements, but we can discuss details later. Uri - change item 12 ??? Ken - since we're not changing SNMPv3, USM is still there, engine ID discovery could be done via USM, just to throw an idea out there JQ - does any one think we should have more criteria here? DH - re URI, in RFC 3412 noAuthNoPriv specified in architectural portion not security portion. --- TLSM proposal Dave Harrington Transport Mapping Security Model lot's of people on list said they wanted to see a TLS model, so I did one. Not a strong proponent but I thought it needed to be done. Lower Layer protocols, TLS, DTLS, SASL, SSH, others... tried to create a proposal that would allow fitting a transport layer mapping to the SNMP engine. different protocols provide different services. TM model, should understand what service mechanisms? available, which services, which security principle DP - from the list, if we provide lower level transport, do you ignore the security level field in PDU or does it have to match the transport or what. How do these interact? DH - message flags are SNMP requirements, that must be communicated to lower layer. Bert Wijnen (BW) [AD] - on the receiving side if the two don't match, what do you do. It just needs to be worked out. DH - quick tangent, this was a last minute proposal, a new version of the proposal was published and a lot of these questions are answered in it. In the new version the MP portion does same analysis of message to see if security level maps to session. If PDU security level is greater than session it is dropped. undecided what to do if it PDU security level is less than session. Don't Know - alternative thing, ???, this is case that it isn't an attack but a bug in implementation Wes - the current draft doesn't talk about parameters to pass between different lower level protocols. DH - the appendix does have some mappings of security wrappings JC - addressing DP questions, the ASI at the invoker says wants to use a particular security level / security model. What's in the PDU may not match the security level of the SM or of the ASI information to the application.... The message wrapper of security model may need separate security bits to indicate security level and info separate from security level in PDU. DP - need clarification of ASI's JC - a proposal would need to define, in separate bits or others ??? Gary? - no complete control between layers... DH - in first iteration, I was going to pass to sets of bits, security model level and message and placed in security parameters. Didn't think ASN.1'ing of that was worthwhile. So new version of draft uses cache, a pointer is passed to indicate a session's security information for a packet. Randy? - should probably skip some of the technical aspects here and discuss on list Wes - just though of another problem. if encrypt packets that the manager doesn't know are encrypted it will mess up benchmarking. And more importantly it could mess up what is sent to VACM for access control. DH - if they don't match, ??? Randy - don't mess with flags if you need more security, it means you need to create a new channel (session). Unknown - how to handle different credential types with underlying transports. talks about Transpor Layer - SNMP transaction but not with security negotiations within the transport layer. JQ - next presentation, please. Wes - update of ISMS quick overview current is draft-hardaker-snmp-sbsm-03.txt creates session between two points 3 phases, init, running , closing The init PDU'S are get and report PDU's. Applications never see these PDU's. This is similar to engieID discovery or time synching today) picture of message flow... Re-uses all existing transports because not tied to it. SNMPv3 architecture, application compliant re-uses exist authentication systems to extend authentication definitions. compression, id disclosure protection, replay protection, negation but rigid??? based on SIGMA already have basic implementation 19.5 hours to implement (with a developer that has expert knowledge SNMP toolkit used) Eric - it's a re-invent of IKE Wes - much simpler than IKE, based on SIGMA not IKE Eric - both based on STS, I think that it's more complex than it looks. Adding new authentication schemes will each add a large amount of complexity. IKE's complex, but it is finished. Wes - I agree that inter-operability needs are important... ??? Eric - TLS took a long time to finalize exchanges, 2-4 years Wes - 1-2 pages to define, but that doesn't count WG consensus time. The current way is simple...??? Eric - key exchange will get complicated very fast. Unknown - haven't read draft, but flow diagram seems to violate some of the layers... How is closing done? Wes - applications can close, low layer library can close. It can be an application decision, a toolset issue not a protocol issue Nico Williams (NW) - besides echoing Eric, we (ietf) already have a lot of key exchange protocol, I don't want to see another. One thing that worries me is that you're deriving keys for the existing v3 model. Wes - no, only two modes defined in USM NW - if transport layer model is rejected, you might want to consider the way per PDU protection is done ??? adding new mechanisms to SNMPv3 NW - adding new mechanisms to SNMPv3 not within charter Wes - the reasons the modes are there today, is that is what is available to SNMPv3. NW - lastly shouldn't create a new key exchange protocol Wes - you could conceivable do IKE within in SNMPv3, but IKE has lots of deployment problems. I think we have two choices, place authentication / encryption in lower layer underneath or you do it within SNMP. Eric - three levels, lower layer, SNMP, or side negotiations. It is a choice between transport mapping and application specific protocol and which integrates better into SNMPv3 model. choice of which key exchange protocol to use determined by assessment of applicability of exchange models to user environment. Wes - some background, one purpose of ISMS is to fix a major complaint. People are not using authentication mechanisms of SNMPv3. Eric - at minimum there are already at least 4 ways to do key exchange and they support multiple protocols. Wes - so many mechanisms in use. it's difficult to choose. Unknown - pick one but don't go with all of them. Wes - I agree... I designed an architecture that would let this work group pick one. Unknown - shouldn't try to meet all cases. EUSM presentation -- Kaushik Narayan (KN) I'll talk about changes and uniqueness from other proposals. no new fields, but it uses existing SNMPv3 - USM as described in RFCs few small changes, setting up session is a high cost, so a goal was to have the session / key negotiation setup be done by third party. It uses existing key exchange protocols. EAP was one example in draft, but not only one possible. Randy - how does agent know what keying info to use with info from radius server. Dave Harrington - SNMPv3 created engine ID, because a differentiation was necessary. We need to the engine id for this. KN - caching, typical duration of 90-180 seconds for a 'session'. JC - why choose that length. KN - time window is not definitive just an example. want to avoid keeping keys on an agent for a long duration, but time should be configurable. It's not hard coded. It is configurable. KN - have a prototype implementation in AAA server and Cisco Works product. A motivations was as minimal changes to SNMP as possible, and also to make sure that peer to peer exchanges for key creation was not necessary (so use of third party AAA server) DP - have you come out with a new draft. KN - not yet DP - In the current draft, it talked about in-band set up of keys. Is that expanded upon in new draft? KN - It will be covered in new draft. DP - in draft and presentation the term AAA was used, this is fuzzy to me what does this mean more precisely Radius, TACX+?, etc... KN - when I'm talking about AAA in this context, I've been talking about Radius and TACX+, but I want to make the protocol more generic to allow others AAA servers. DP - ??? (question of fuzzyness of AAA term) KN - It does not require change in protocol to support different types of AAA servers. DP - It sound like you've done use case analysis, but I haven't seen a use case of what to do when one adds a new box, adds a new user, deletes a user,... ??? KN - reason to integrate with AAA servers is so that adding/deleting user is covered by adding deleting user to AAA servers. Other proposals don't show these use cases either. Should we cover these use cases? DP - use cases covered in IBSM in BOF's Wes - should the WG require the use case? DP - I'd like concrete steps to be able to understand how the protocols work. DH - I think that would be very useful Gary - and it would apply to all proposals DP - absolutely Wes - ???... people still need to use USM, big difference because the users today that don't use USM now, won't use it in the future if AAA server is down (faulty network case???). KN - ??? Wes - one USM user is required in this case and the operators do not have any currently. KN - if an authentication mechanism of local user is required, EUSM could add it easily. IBSM would have same problem. Wes - local user's already exist and IBSM can use local user, EUSM still requires a local USM user which don't exist. Gary - Could you clarify that? Wes - EUSM still requires AAA server, if the network is broken this is a problem. KN - can fall back to USM users? Gary? - if network not up, can't talk to machine anyway? Ken - using other servers in the past have raised many complaints in the SNMP community. Gary? - biggest comment is shortness of key lifetime, but should discuss on mailing list. DP - We should accept that we sometimes need quick revocation of keys (e.g. if someone is fired) Randy - a comment on all proposals. The reason integration of current security models is important is because operators want to log onto a machine without knowing how well or sick a network is. So with a fall back to a local account, you'd really like the mechanism to allow the same account to be able to fall back to the same user? KN - we'll clarify fall back to USM in draft. Ken - should take this to mailing list. Gary? - this issue will exist with any mechanism except local accounts. For revocation, either need to check over the network or fall back. Unknown - The way a broken device is handle today in operations, it requires special procedures to fall back to a local user. Particular you can't assume you can use the same credentials on the box as off. DH - I was wondering how much radius is used on core devices KN - I think it's pretty universal for edge or core. DH - in SNMP architecture we deliberatively moved away from manager-agent terminology and your draft uses those terms. KN - I need to clean up terminology in draft. DH - can the key from the manager side be used for informs? KN - one of the things we worried about is should the agent have to talk to the AAA server ...???..., think we should discuss this on list. DH - ?? KN - ?? DH - can a radius server revoke a key? KN - handle this via shortened key lifetime (although master key could be revoked on server) JQ - go back to criteria list, check blue sheets what are some of the key differences in proposals? KN - I think one of the big difference is use of third party by EUSM for key acquiring. Unknown - ??? something like EUSM sounds like a good idea with fall back to USM is good but replication of all users to all devices is bad idea. KN - I think fall back has been beaten to death but not any different from fall back to CLI or Netconf?? Unknown - not disagreeing, just want to reiterate, don't replicate authentication of DB's everywhere JQ - any difference of proposals for - no decrease of security Wes - .... difficult to cover this in one spreadsheet row JC - should replay protection be optimal or mandatory? Randy - is available a bit in SNMP via some parameters Eric - ... let's concentrate on inherent design of protocols and not minor details. JQ - close additional security features, items 9, 10, 11 are all good let's discuss integration (8). JC - should have chart show: same as USM, more than USM, or less than USM, instead of OK JQ - we agree they all have at least as much, but which has more we're unable to resolve today. Wes - ... probably won't be able solve discussion of which is more secure today. Randy - one thing they all have in common is the use of sessions. With the introduction of that concept we might want to examine how many exchanges it takes to initialize a session and to close a session. What types of operations to add/delete user in the big sense. How long to propagate that knowledge out to nodes. Eric - want to look at big picture, the key important question is, what type of architecture do you want. One bound tightly to SNMP, like EUSM (IBSM??), layered on top, like TLSM, external keying system that wires into SNMP, like EUSM. Many of these proposals are orthogonal to requirement choices? Wes - do we have time to make major changes to proposals. Unknown - .... can we make a choice between to instead of three. Ken - not sure we have consensus to remove one. Wes - ... a significant difference between IBSM and EUSM, EUSM forces third party keying. KN - (respond to EUSM not be scaling any better than Kereberos?), a motivation for EUSM proposals, we wanted to make sure that we made as minimal a change to SNMP as possible because we have code already and wanted to minimize the cost to upgrade. Sam? - speaking as future AD, it would be difficult to get architecture choice by March. JQ - I don't think we can drop any of the three, so we will pass all three onto to evaluation team. Ken - listed possibles, 4-5, for evaluation team DP - any operations people Ken - any here that want to volunteer DH - want to know how many of the operators think all three of these are viable. I'd like to eliminate one of these. Particular I think we should drop the TLSM (DH's) proposal. JQ - don't think we can resolve this today. Wes - one of the goals to pick quickly is because we have a very tight deadline. If the AD's want us to consider all the proposals, I'm worried we won't make our deadlines. Sam? - I don't care if one is dropped on the mailing list, I don't think there is enough time today to make a good decision. With no further discussion, the meeting was closed. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Nov 10 11:00:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23892; Wed, 10 Nov 2004 11:00:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuuN-0005oN-W8; Wed, 10 Nov 2004 11:01:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuf0-0007MG-Uu; Wed, 10 Nov 2004 10:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRucE-0006jv-FR for isms@megatron.ietf.org; Wed, 10 Nov 2004 10:42:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21682 for ; Wed, 10 Nov 2004 10:42:31 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRudC-0005IV-9j for isms@ietf.org; Wed, 10 Nov 2004 10:43:35 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAAFfxW15556 for ; Wed, 10 Nov 2004 10:41:59 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 10:41:59 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B401CD9C53@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: isms@ietf.org Subject: RE: [Isms] DRAFT minutes for ISMS Date: Wed, 10 Nov 2004 10:41:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3c5809f82a2ef36c74d8c0ab21f70455 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 86a4d7ebdc337882c86d755b1c60a122 Content-Transfer-Encoding: quoted-printable hi Jabber=20 http://www.xmpp.org/ietf-logs/isms@ietf.xmpp.org/2004-11-08.html Sharon -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] = On Behalf Of Ken Hornstein Sent: Tuesday, November 09, 2004 3:47 PM To: isms@ietf.org Subject: [Isms] DRAFT minutes for ISMS Howdy all, Here is a draft minutes for the ISMS WG meeting yesterday. Please let = me know if you have any comments or suggestions. Particularly let me know = if I've misattributed something in the minutes. --Ken DRAFT Minutes for the Integrated Security Model for SNMPv3 (ISMS) WG = IETF 61, November 8th, 2004 The meeting was opened by chairs Ken Hornstein (KH) and Juergen Quittek (JQ). (JQ) - Review of meeting goals Oct 4 cut off for proposal submission Nov we decide which solution Currently there are three proposals: SBSM - A higher-level approach EUSM - Straight forward extension of USM to support AAA TLSM - SNMP over TLS (or some other transport mapping service). Traditional agenda bashing was next (minor changes to the order were suggested, but the original agenda order was kept). (JQ) - procedure Question, due we want to create evaluation team to decide on which proposal? Wes Hardaker (Wes) - maybe only examine proposals that work group want (i.e. not necessarily all three) JQ - let's select criteria for proposal acceptance=20 Unknown - Perhaps we should use proposals to drive requirements Wes - lets bring it back to talking about criteria again Dave Perkins (DP) - looking at what drives operations for the same, we should look at each proposal to see if we can reduce the pain level for managers to use and implement. Ken - Our charter: maximize usability in environment integration into existing infrastructures. must not modify SNMPv3 protocol should be compliant with SNMPV3 security model, RFC 3411/2 if at all possible, don't change any other protocols Unknown - make sure existing SNMPv3 support isn't changed Ken - we're still going over charter right now. Ken - discussion of per-PDU encryption on the list, regarding the = ability to have different encryption/authentication per PDU Wes - point of order, what things are in scope at this point are we = listing anything (i.e. goals and/or requirements?), JQ - we should make a difference between requirements and nice to haves Wes - I believe one of requirements is must not decrease security. Ken - technically that is not in charter Wes - It has been discussed before. J=FCrgen Sch=F6nw=E4lder (JS) - what does that mean? Wes - we can't create a new protocol that doesn't provide same = strengths that USM provides. But some of operators didn't like strengths USM provides, they send passwords in clear so that they can log in to the machines. i.e. they don't find USM usable, so there may be some = question as to what strengths we need to support. But we should have encryption / authentication capability and the protection of breaking one client not breaking all clients. Unknown - Operators pass passwords in clear for convenience; they = prefer convenience in this case instead of security. Jeff Case (JC) - I'm concerned about usability line derived from the charter, can it be broken into 4 things from the line in charter: = usability, deployment success, minimize implementation cost, quick time to = market... usability minimum implementation cost minimum deployment cost time to market JC - should we consider what they export/import restrictions in top countries in world so that the technology selected is acceptable to = most/all of them Steve Belovin (SB) [AD] - we design technically sound protocols, let = the lawyers fight over legal acceptability. Unknown - questioning usability, be clearer on what we do mean. Ken - example of problem with USM, large scale re-keying of = passwords... In the eye of the beholder.=20 JQ - usability, what functions are needed and how easy is it to use = them Michael St.John? (MSJ) - should differentiate between agent and manager Sam Hartman (SH) - deployment ease : security should work with existing = the authentication infrastructure you have Wes - operator desirability, operators have varying environments so we should have flexibility in ISMS, (within reasons). Would operators = want to use it?, would someone actually start using it? JQ - desirability Wes - should we strike usability JQ - we're high in abstraction, we should be talking about a lower = level DH - 7 (integration into infrastructure) should be split into two = parts, management and security integration Ken - management is done by SNMP proper DH - snmp parity as example, it was nice and secure but one had to go = to the box to configure. people use HP OV to find devices on network but had = to configure box before it could be discovered, it wasn't usable. DP - somewhat different view that when someone deploys a new box, if = they just plug it into the network, they have unreal expectations if they = think the can, without configuration, manage it and manage it securely. Many different ways to do initial configuration, but something that may not = be obvious to anyone is that wouldn't it be nice if they didn't have to do anything extra to integrate with SNMPv3. Should go through use cases. DH - said you disagreed with what I said, but I just meant we should be = able to do discovery DP - but I disagree, you should need to configure a box when putting it = on a network DH - but I want to find a rogue box put on network. Ken - I think both are compatible DP - but different way of looking on world, a manager will need to = configure any device put on network Unknown - don't break basic discovery. JQ - let's move this discussion off-line Unknown - we should support engine ID discovery for example JQ - on the list we have integration into infrastructure, let's keep requirements, but we can discuss details later. Uri - change item 12 ??? Ken - since we're not changing SNMPv3, USM is still there, engine ID discovery could be done via USM, just to throw an idea out there JQ - does any one think we should have more criteria here? DH - re URI, in RFC 3412 noAuthNoPriv specified in architectural = portion not security portion. --- TLSM proposal Dave Harrington Transport Mapping Security Model lot's of people on list said they wanted to see a TLS model, so I did = one. Not a strong proponent but I thought it needed to be done. Lower Layer protocols, TLS, DTLS, SASL, SSH, others... tried to create a proposal that would allow fitting a transport layer mapping to the SNMP engine. different protocols provide different services. TM model, should understand what service mechanisms? available, which services, which security principle DP - from the list, if we provide lower level transport, do you ignore = the security level field in PDU or does it have to match the transport or = what. How do these interact? DH - message flags are SNMP requirements, that must be communicated to = lower layer. Bert Wijnen (BW) [AD] - on the receiving side if the two don't match, = what do you do. It just needs to be worked out. DH - quick tangent, this was a last minute proposal, a new version of = the proposal was published and a lot of these questions are answered in it. = In the new version the MP portion does same analysis of message to see if security level maps to session. If PDU security level is greater than session it is dropped. undecided what to do if it PDU security level is = less than session. Don't Know - alternative thing, ???, this is case that it isn't an = attack but a bug in implementation Wes - the current draft doesn't talk about parameters to pass between different lower level protocols. DH - the appendix does have some mappings of security wrappings JC - addressing DP questions, the ASI at the invoker says wants to use = a particular security level / security model. What's in the PDU may not = match the security level of the SM or of the ASI information to the application.... The message wrapper of security model may need separate security bits to indicate security level and info separate from = security level in PDU. DP - need clarification of ASI's JC - a proposal would need to define, in separate bits or others ??? Gary? - no complete control between layers... DH - in first iteration, I was going to pass to sets of bits, security = model level and message and placed in security parameters. Didn't think = ASN.1'ing of that was worthwhile. So new version of draft uses cache, a pointer = is passed to indicate a session's security information for a packet. Randy? - should probably skip some of the technical aspects here and = discuss on list Wes - just though of another problem. if encrypt packets that the = manager doesn't know are encrypted it will mess up benchmarking. And more importantly it could mess up what is sent to VACM for access control. DH - if they don't match, ??? Randy - don't mess with flags if you need more security, it means you = need to create a new channel (session). Unknown - how to handle different credential types with underlying transports. talks about Transpor Layer - SNMP transaction but not with security negotiations within the transport layer. JQ - next presentation, please. Wes - update of ISMS quick overview current is draft-hardaker-snmp-sbsm-03.txt creates session between two points 3 phases, init, running , closing The init PDU'S are get and report PDU's. Applications never see these PDU's. This is similar to engieID discovery or time synching today) picture of message flow... Re-uses all existing transports because not tied to it. SNMPv3 architecture, application compliant re-uses exist authentication = systems to extend authentication definitions. compression, id disclosure = protection, replay protection, negation but rigid??? based on SIGMA already have basic implementation 19.5 hours to implement (with a developer that has expert knowledge = SNMP toolkit used) Eric - it's a re-invent of IKE Wes - much simpler than IKE, based on SIGMA not IKE Eric - both based on STS, I think that it's more complex than it looks. Adding new authentication schemes will each add a large amount of complexity. IKE's complex, but it is finished. Wes - I agree that inter-operability needs are important... ??? Eric - TLS took a long time to finalize exchanges, 2-4 years Wes - 1-2 pages to define, but that doesn't count WG consensus time. The current way is simple...??? Eric - key exchange will get complicated very fast. Unknown - haven't read draft, but flow diagram seems to violate some of = the layers... How is closing done?=20 Wes - applications can close, low layer library can close. It can be = an application decision, a toolset issue not a protocol issue Nico Williams (NW) - besides echoing Eric, we (ietf) already have a lot = of key exchange protocol, I don't want to see another. One thing that = worries me is that you're deriving keys for the existing v3 model. Wes - no, only two modes defined in USM NW - if transport layer model is rejected, you might want to consider = the way per PDU protection is done ??? adding new mechanisms to SNMPv3 NW - adding new mechanisms to SNMPv3 not within charter Wes - the reasons the modes are there today, is that is what is = available to SNMPv3. NW - lastly shouldn't create a new key exchange protocol Wes - you could conceivable do IKE within in SNMPv3, but IKE has lots = of deployment problems. I think we have two choices, place authentication = / encryption in lower layer underneath or you do it within SNMP. Eric - three levels, lower layer, SNMP, or side negotiations. It is a choice between transport mapping and application specific protocol and = which integrates better into SNMPv3 model. choice of which key exchange = protocol to use determined by assessment of applicability of exchange models to = user environment. Wes - some background, one purpose of ISMS is to fix a major complaint. People are not using authentication mechanisms of SNMPv3. Eric - at minimum there are already at least 4 ways to do key exchange = and they support multiple protocols. Wes - so many mechanisms in use. it's difficult to choose. Unknown - pick one but don't go with all of them. Wes - I agree... I designed an architecture that would let this work = group pick one. Unknown - shouldn't try to meet all cases. EUSM presentation -- Kaushik Narayan (KN) I'll talk about changes and uniqueness from other proposals. no new fields, but it uses existing SNMPv3 - USM as described in RFCs few small changes, setting up session is a high cost, so a goal was to = have the session / key negotiation setup be done by third party. It uses = existing key exchange protocols. EAP was one example in draft, but not only one possible. Randy - how does agent know what keying info to use with info from = radius server. Dave Harrington - SNMPv3 created engine ID, because a differentiation = was necessary. We need to the engine id for this. KN - caching, typical duration of 90-180 seconds for a 'session'. JC - why choose that length. KN - time window is not definitive just an example. want to avoid = keeping keys on an agent for a long duration, but time should be configurable. = It's not hard coded. It is configurable. KN - have a prototype implementation in AAA server and Cisco Works = product. A motivations was as minimal changes to SNMP as possible, and also to = make sure that peer to peer exchanges for key creation was not necessary (so = use of third party AAA server) DP - have you come out with a new draft. KN - not yet DP - In the current draft, it talked about in-band set up of keys. Is = that expanded upon in new draft? KN - It will be covered in new draft. DP - in draft and presentation the term AAA was used, this is fuzzy to = me what does this mean more precisely Radius, TACX+?, etc... KN - when I'm talking about AAA in this context, I've been talking = about Radius and TACX+, but I want to make the protocol more generic to allow others AAA servers. DP - ??? (question of fuzzyness of AAA term) KN - It does not require change in protocol to support different types = of AAA servers. DP - It sound like you've done use case analysis, but I haven't seen a = use case of what to do when one adds a new box, adds a new user, deletes a user,... ??? KN - reason to integrate with AAA servers is so that adding/deleting = user is covered by adding deleting user to AAA servers. Other proposals don't = show these use cases either. Should we cover these use cases? DP - use cases covered in IBSM in BOF's Wes - should the WG require the use case? DP - I'd like concrete steps to be able to understand how the protocols work. DH - I think that would be very useful Gary - and it would apply to all proposals DP - absolutely Wes - ???... people still need to use USM, big difference because the = users today that don't use USM now, won't use it in the future if AAA server = is down (faulty network case???). KN - ??? Wes - one USM user is required in this case and the operators do not = have any currently. KN - if an authentication mechanism of local user is required, EUSM = could add it easily. IBSM would have same problem. Wes - local user's already exist and IBSM can use local user, EUSM = still requires a local USM user which don't exist. Gary - Could you clarify that? Wes - EUSM still requires AAA server, if the network is broken this is = a problem. KN - can fall back to USM users? Gary? - if network not up, can't talk to machine anyway? Ken - using other servers in the past have raised many complaints in = the SNMP community. Gary? - biggest comment is shortness of key lifetime, but should = discuss on mailing list. DP - We should accept that we sometimes need quick revocation of keys = (e.g. if someone is fired) Randy - a comment on all proposals. The reason integration of current security models is important is because operators want to log onto a = machine without knowing how well or sick a network is. So with a fall back to a local account, you'd really like the mechanism to allow the same = account to be able to fall back to the same user? KN - we'll clarify fall back to USM in draft. Ken - should take this to mailing list. Gary? - this issue will exist with any mechanism except local accounts. = For revocation, either need to check over the network or fall back. Unknown - The way a broken device is handle today in operations, it = requires special procedures to fall back to a local user. Particular you can't = assume you can use the same credentials on the box as off. DH - I was wondering how much radius is used on core devices KN - I think it's pretty universal for edge or core. DH - in SNMP architecture we deliberatively moved away from = manager-agent terminology and your draft uses those terms. KN - I need to clean up terminology in draft. DH - can the key from the manager side be used for informs? KN - one of the things we worried about is should the agent have to = talk to the AAA server ...???..., think we should discuss this on list. DH - ?? KN - ?? DH - can a radius server revoke a key? KN - handle this via shortened key lifetime (although master key could = be revoked on server) JQ - go back to criteria list, check blue sheets what are some of the = key differences in proposals? KN - I think one of the big difference is use of third party by EUSM = for key acquiring. Unknown - ??? something like EUSM sounds like a good idea with fall = back to USM is good but replication of all users to all devices is bad idea. KN - I think fall back has been beaten to death but not any different = from fall back to CLI or Netconf?? Unknown - not disagreeing, just want to reiterate, don't replicate authentication of DB's everywhere JQ - any difference of proposals for=20 - no decrease of security Wes - .... difficult to cover this in one spreadsheet row JC - should replay protection be optimal or mandatory? Randy - is available a bit in SNMP via some parameters Eric - ... let's concentrate on inherent design of protocols and not = minor details. JQ - close additional security features, items 9, 10, 11 are all good = let's discuss integration (8). JC - should have chart show: same as USM, more than USM, or less than = USM, instead of OK JQ - we agree they all have at least as much, but which has more we're unable to resolve today. Wes - ... probably won't be able solve discussion of which is more = secure today. Randy - one thing they all have in common is the use of sessions. With = the introduction of that concept we might want to examine how many = exchanges it takes to initialize a session and to close a session. What types of operations to add/delete user in the big sense. How long to propagate = that knowledge out to nodes. Eric - want to look at big picture, the key important question is, what = type of architecture do you want. One bound tightly to SNMP, like EUSM = (IBSM??), layered on top, like TLSM, external keying system that wires into SNMP, = like EUSM. Many of these proposals are orthogonal to requirement choices? Wes - do we have time to make major changes to proposals. Unknown - .... can we make a choice between to instead of three. Ken - not sure we have consensus to remove one. Wes - ... a significant difference between IBSM and EUSM, EUSM forces = third party keying. KN - (respond to EUSM not be scaling any better than Kereberos?), a motivation for EUSM proposals, we wanted to make sure that we made as minimal a change to SNMP as possible because we have code already and = wanted to minimize the cost to upgrade. Sam? - speaking as future AD, it would be difficult to get architecture choice by March. JQ - I don't think we can drop any of the three, so we will pass all = three onto to evaluation team. =20 Ken - listed possibles, 4-5, for evaluation team DP - any operations people Ken - any here that want to volunteer DH - want to know how many of the operators think all three of these = are viable. I'd like to eliminate one of these. Particular I think we = should drop the TLSM (DH's) proposal. JQ - don't think we can resolve this today. Wes - one of the goals to pick quickly is because we have a very tight deadline. If the AD's want us to consider all the proposals, I'm = worried we won't make our deadlines. Sam? - I don't care if one is dropped on the mailing list, I don't = think there is enough time today to make a good decision. With no further discussion, the meeting was closed. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 11 14:09:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13247; Thu, 11 Nov 2004 14:09:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKLc-0001g9-QE; Thu, 11 Nov 2004 14:11:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKIe-00059e-0g; Thu, 11 Nov 2004 14:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKDP-0003on-IN for isms@megatron.ietf.org; Thu, 11 Nov 2004 14:02:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12517 for ; Thu, 11 Nov 2004 14:02:38 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKEc-0001TD-2r for isms@ietf.org; Thu, 11 Nov 2004 14:03:55 -0500 Received: from cmf.nrl.navy.mil ([130.129.135.57]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id iABJ2VH7016578 for ; Thu, 11 Nov 2004 14:02:32 -0500 (EST) Message-Id: <200411111902.iABJ2VH7016578@ginger.cmf.nrl.navy.mil> To: isms@ietf.org X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Date: Thu, 11 Nov 2004 14:02:32 -0500 X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Isms] ISMS WG Meeting Summary X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 WG members, Below you will find a summary of the working group meeting that took place at this IETF (Washington, DC). More detailed minutes will be forthcoming. I plan on integrating the current minutes (thanks to Mike Baer) with the excellent job Sharon Chishom did as Jabber scribe. ISMS WG - IETF 61 Meeting Summary The deadlines of the WG were discussed. - October 2004 cutoff for for proposals - November 2004 decision by WG on direction to take - March 2005 recharter to focus on direction or shut down There was a general discussion about selection critera. The three different proposals were then discussed. The first proposal was TLSM, by David Harrington. - Using a lower level transport layer (such as TLS) to provide SNMP security - Considerable discussion on this topic. - David Harrington is not convinced it was the best, but "needed to be done" Next proposal was SBSM, by Wes Hardaker. - Creates a "session" and negotiates security in-band. - Implemented in Net-SNMP - Considerable concern from WG attendees about creating a new key exchange mechanism. - Suggested that one should reuse another key exchange mechanism Third proposal was EUSM, by Kaushik Narayan. - Uses USM, but talks to a third party (AAA) server - Implemented by people at Cisco. - Concerns about key lifetime and robustness. There was significant discussion about the proposals. It was agreed that an evaluation team should be used, and evaluation team members were chosen. The evaluation team members are: Randy Presuhn Eric Rescorla Uri Blumenthal Lakshminath Dondeti The evaluation team should make a decision by the end of November. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 15 02:07:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21964; Mon, 15 Nov 2004 02:07:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTaz0-0000jI-G9; Mon, 15 Nov 2004 02:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTavF-0007EW-B6; Mon, 15 Nov 2004 02:05:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTauo-0006w6-Me for isms@megatron.ietf.org; Mon, 15 Nov 2004 02:04:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20072 for ; Mon, 15 Nov 2004 02:04:40 -0500 (EST) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTawh-0000hH-LL for isms@ietf.org; Mon, 15 Nov 2004 02:06:42 -0500 Received: from h-69-3-91-158.snvacaid.dynamic.covad.net ([69.3.91.158] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CTaui-0006zh-00 for isms@ietf.org; Sun, 14 Nov 2004 23:04:37 -0800 Message-ID: <016901c4cae1$9ce32240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.0.0.22.0.20041105130509.03bac240@mira-sjc5-a.cisco.com><3fjeto$a46n4@sj-inbound-b.cisco.com><6.0.0.22.0.20041105154242.03c180f8@mira-sjc5-a.cisco.com> <6.0.0.22.0.20041106101614.031f0260@mira-sjc5-a.cisco.com> Subject: Re: Fwd: [Isms] EUSM key localization details Date: Sun, 14 Nov 2004 23:06:21 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi - > From: "Kaushik Narayan" > To: "Wes Hardaker" > Cc: > Sent: Saturday, November 06, 2004 10:33 AM > Subject: Re: Fwd: [Isms] EUSM key localization details ... > This would mean that agents do-not need to acquire keys to serve > an SNMPv3 engine ID discovery request and SNMP Managers can > discovery engine IDs and bootstrap the AAA server. ... Which brings us back to my question at the start of this thread: how does the AAA server know *which* of the SNMP engine IDs to use? The information described in the proposal as flowing in the RADIUS Key_Request (Key (App ID), Calling-Station-ID, User-Name) is not sufficient to map to a single engine ID, since there may be multiple SNMP engines in a single system. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 15 11:54:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10413; Mon, 15 Nov 2004 11:54:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTk9a-0002gp-Rc; Mon, 15 Nov 2004 11:56:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTk4g-0006xh-Bn; Mon, 15 Nov 2004 11:51:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTk3o-0006pS-2V for isms@megatron.ietf.org; Mon, 15 Nov 2004 11:50:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09775 for ; Mon, 15 Nov 2004 11:50:33 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTk5o-0002Yf-S5 for isms@ietf.org; Mon, 15 Nov 2004 11:52:42 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2004 08:50:14 -0800 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAFGo0uk000226; Mon, 15 Nov 2004 08:50:01 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.217.5]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Nov 2004 08:51:53 -0800 From: "Joseph Salowey" To: "'Randy Presuhn'" , Subject: RE: Fwd: [Isms] EUSM key localization details Date: Mon, 15 Nov 2004 08:49:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTK4glCuCdtaXi+Sb6JtzEmDCPwZwAUJfQA In-Reply-To: <016901c4cae1$9ce32240$7f1afea9@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: X-OriginalArrivalTime: 15 Nov 2004 16:51:53.0860 (UTC) FILETIME=[69001440:01C4CB33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit isms-bounces@lists.ietf.org wrote: > Hi - > >> From: "Kaushik Narayan" >> To: "Wes Hardaker" >> Cc: >> Sent: Saturday, November 06, 2004 10:33 AM >> Subject: Re: Fwd: [Isms] EUSM key localization details ... >> This would mean that agents do-not need to acquire keys to serve an >> SNMPv3 engine ID discovery request and SNMP Managers can discovery >> engine IDs and bootstrap the AAA server. > ... > > Which brings us back to my question at the start of this thread: > how does the AAA server know *which* of the SNMP engine IDs > to use? The information described in the proposal as flowing in > the RADIUS Key_Request (Key (App ID), Calling-Station-ID, > User-Name) is not sufficient to map to a single engine ID, > since there may be multiple SNMP engines in a single system. > [Joe] Yes I think we need an attribute to contain the SNMP Engine ID making the request. I'm not sure if we can use existing attributes to convey this information, we may need to create a new one. The AAA server still should verify that the engine ID is authorized to the RADIUS client making the request. > Randy > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 15 12:24:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12388; Mon, 15 Nov 2004 12:24:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTkcO-0003DX-Cj; Mon, 15 Nov 2004 12:26:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTkTa-0002a6-1G; Mon, 15 Nov 2004 12:17:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTkNK-0000nG-L9 for isms@megatron.ietf.org; Mon, 15 Nov 2004 12:10:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11380 for ; Mon, 15 Nov 2004 12:10:44 -0500 (EST) Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTkPN-0002xR-0w for isms@ietf.org; Mon, 15 Nov 2004 12:12:53 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc, v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id iAFH9gYo003278 for ; Mon, 15 Nov 2004 17:09:42 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iAFHA1BY002901 for ; Mon, 15 Nov 2004 17:10:08 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004111509100728727 for ; Mon, 15 Nov 2004 09:10:07 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Nov 2004 09:10:07 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Nov 2004 09:10:07 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Nov 2004 12:10:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fwd: [Isms] EUSM key localization details Date: Mon, 15 Nov 2004 12:10:05 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C59294BD976@pysmsx401.amr.corp.intel.com> Thread-Topic: Fwd: [Isms] EUSM key localization details Thread-Index: AcTK4glCuCdtaXi+Sb6JtzEmDCPwZwAUJfQAAACkXmA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 15 Nov 2004 17:10:06.0274 (UTC) FILETIME=[F4213A20:01C4CB35] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Yes, AAA must receive the snmpEngineID in order to compute localized key, and AAA should verify authorization. Re. newtributes - a new EAP method is being defined anyway, right? -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Joseph Salowey Sent: Monday, November 15, 2004 11:50 AM To: 'Randy Presuhn'; isms@ietf.org Subject: RE: Fwd: [Isms] EUSM key localization details isms-bounces@lists.ietf.org wrote: > Hi - >=20 >> From: "Kaushik Narayan" >> To: "Wes Hardaker" >> Cc: >> Sent: Saturday, November 06, 2004 10:33 AM >> Subject: Re: Fwd: [Isms] EUSM key localization details ... >> This would mean that agents do-not need to acquire keys to serve an >> SNMPv3 engine ID discovery request and SNMP Managers can discovery >> engine IDs and bootstrap the AAA server. > ... >=20 > Which brings us back to my question at the start of this thread: > how does the AAA server know *which* of the SNMP engine IDs > to use? The information described in the proposal as flowing in > the RADIUS Key_Request (Key (App ID), Calling-Station-ID, > User-Name) is not sufficient to map to a single engine ID, > since there may be multiple SNMP engines in a single system. >=20 [Joe] Yes I think we need an attribute to contain the SNMP Engine ID making the request. I'm not sure if we can use existing attributes to convey this information, we may need to create a new one. The AAA server still should verify that the engine ID is authorized to the RADIUS client making the request. =20 > Randy >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 15 13:31:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18049; Mon, 15 Nov 2004 13:31:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTlfF-0004hC-Mv; Mon, 15 Nov 2004 13:33:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTlby-0007zU-CW; Mon, 15 Nov 2004 13:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTlae-0007qq-0W for isms@megatron.ietf.org; Mon, 15 Nov 2004 13:28:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17830 for ; Mon, 15 Nov 2004 13:28:32 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTlcf-0004eT-8h for isms@ietf.org; Mon, 15 Nov 2004 13:30:43 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2004 10:28:12 -0800 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAFHlHvO009885; Mon, 15 Nov 2004 10:27:58 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.217.5]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Nov 2004 10:22:43 -0800 From: "Joseph Salowey" To: "'Blumenthal, Uri'" , Subject: RE: Fwd: [Isms] EUSM key localization details Date: Mon, 15 Nov 2004 10:20:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTK4glCuCdtaXi+Sb6JtzEmDCPwZwAUJfQAAACkXmAAARnBsA== In-Reply-To: <3DEC199BD7489643817ECA151F7C59294BD976@pysmsx401.amr.corp.intel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: X-OriginalArrivalTime: 15 Nov 2004 18:22:43.0908 (UTC) FILETIME=[197B6840:01C4CB40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Hi Uri, We should use existing EAP methods that generate keys, we don't really want to create special methods for SNMP. There are basically three parts to the proposal. 1. Authenticated Key setup between SNMP manager and key server This protocol should authenticate the user and the key server, establish a strong key, and be flexible in mechanism. We suggest using EAP in RADIUS. The EAP framwework is useful because it integrates with AAA servers for authentication. The EAP methods used should not be SNMP specific. 2. Communication of keys from key server to SNMP agent This requires secure transmission of the correct localized SNMPv3 keys from key server to agent. If the key server is co-located with the agent then this is a local API matter. If the key server is remote from the agent then you can gain the benefit that one key setup procedure can be used to set up a key that can be the basis for security for many agents. We suggest using some extensions to RADIUS for this key transport. It would also be useful to communicate other parameters such as VACM information to the agent in this protocol as well. RADIUS is useful since many entities containing agents are RADIUS clients as well. 3. EUSM enhancement to SNMPv3 between agent and manager This is enhancements to SNMPv3 to support key material that is established external to SNMP processing. The main goal here was to keep changes to SNMPv3 as minimal as possible. Joe isms-bounces@lists.ietf.org wrote: > Yes, AAA must receive the snmpEngineID in order to compute > localized key, and AAA should verify authorization. Re. > newtributes - a new EAP method is being defined anyway, right? > > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Joseph Salowey > Sent: Monday, November 15, 2004 11:50 AM > To: 'Randy Presuhn'; isms@ietf.org > Subject: RE: Fwd: [Isms] EUSM key localization details > > > > isms-bounces@lists.ietf.org wrote: >> Hi - >> >>> From: "Kaushik Narayan" >>> To: "Wes Hardaker" >>> Cc: >>> Sent: Saturday, November 06, 2004 10:33 AM >>> Subject: Re: Fwd: [Isms] EUSM key localization details ... >>> This would mean that agents do-not need to acquire keys to serve an >>> SNMPv3 engine ID discovery request and SNMP Managers can discovery >>> engine IDs and bootstrap the AAA server. >> ... >> >> Which brings us back to my question at the start of this thread: >> how does the AAA server know *which* of the SNMP engine IDs to use? >> The information described in the proposal as flowing in >> the RADIUS Key_Request (Key (App ID), Calling-Station-ID, >> User-Name) is not sufficient to map to a single engine ID, since >> there may be multiple SNMP engines in a single system. >> > > [Joe] Yes I think we need an attribute to contain the SNMP > Engine ID making the request. I'm not sure if we can use > existing attributes to convey this information, we may need > to create a new one. The AAA server still should verify that > the engine ID is authorized to the RADIUS client making the request. > >> Randy >> >> >> >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 15 14:56:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25691; Mon, 15 Nov 2004 14:56:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTmzc-0006f5-L6; Mon, 15 Nov 2004 14:58:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTmtS-0005F3-Uu; Mon, 15 Nov 2004 14:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTmo9-0004Hj-B3 for isms@megatron.ietf.org; Mon, 15 Nov 2004 14:46:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25040 for ; Mon, 15 Nov 2004 14:46:35 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTmq9-0006Se-Mr for isms@ietf.org; Mon, 15 Nov 2004 14:48:45 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Nov 2004 13:07:26 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAFJhvw0026815; Mon, 15 Nov 2004 11:43:58 -0800 (PST) Received: from kaushik-w2k02.cisco.com (dhcp-171-69-125-33.cisco.com [171.69.125.33]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVP89100; Mon, 15 Nov 2004 11:37:13 -0800 (PST) Message-Id: <6.0.0.22.0.20041115112329.04332cb8@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 15 Nov 2004 11:44:03 -0800 To: "Joseph Salowey" From: Kaushik Narayan Subject: RE: Fwd: [Isms] EUSM key localization details In-Reply-To: References: <016901c4cae1$9ce32240$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Hi All, There can be multiple schemes of authorization as discussed previously on the list. You could verify the engine ID to authorize based on the identity of the engine requesting the keys, there could also be policies for unknown engine IDs which might be based on user access to agents. regards, kaushik! At 08:49 AM 11/15/2004, Joseph Salowey wrote: >isms-bounces@lists.ietf.org wrote: > > Hi - > > > >> From: "Kaushik Narayan" > >> To: "Wes Hardaker" > >> Cc: > >> Sent: Saturday, November 06, 2004 10:33 AM > >> Subject: Re: Fwd: [Isms] EUSM key localization details ... > >> This would mean that agents do-not need to acquire keys to serve an > >> SNMPv3 engine ID discovery request and SNMP Managers can discovery > >> engine IDs and bootstrap the AAA server. > > ... > > > > Which brings us back to my question at the start of this thread: > > how does the AAA server know *which* of the SNMP engine IDs > > to use? The information described in the proposal as flowing in > > the RADIUS Key_Request (Key (App ID), Calling-Station-ID, > > User-Name) is not sufficient to map to a single engine ID, > > since there may be multiple SNMP engines in a single system. > > > >[Joe] Yes I think we need an attribute to contain the SNMP Engine ID making >the request. I'm not sure if we can use existing attributes to convey this >information, we may need to create a new one. The AAA server still should >verify that the engine ID is authorized to the RADIUS client making the >request. > > > Randy > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 15 15:18:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28225; Mon, 15 Nov 2004 15:18:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnKh-00076I-U6; Mon, 15 Nov 2004 15:20:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnE1-0007ux-PU; Mon, 15 Nov 2004 15:13:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTn9g-0004st-GQ for isms@megatron.ietf.org; Mon, 15 Nov 2004 15:08:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26931 for ; Mon, 15 Nov 2004 15:08:50 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnBg-0006u3-RV for isms@ietf.org; Mon, 15 Nov 2004 15:11:00 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4DB5931EC; Mon, 15 Nov 2004 21:08:08 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08149-07; Mon, 15 Nov 2004 21:08:07 +0100 (CET) Received: from james (unknown [169.237.218.227]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 3D2F13164; Mon, 15 Nov 2004 21:08:07 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CTn8t-0000zW-DH; Mon, 15 Nov 2004 21:08:03 +0100 Date: Mon, 15 Nov 2004 21:08:03 +0100 From: Juergen Schoenwaelder To: Kaushik Narayan Subject: Re: Fwd: [Isms] EUSM key localization details Message-ID: <20041115200803.GA3793@james> Mail-Followup-To: Kaushik Narayan , Joseph Salowey , isms@ietf.org References: <016901c4cae1$9ce32240$7f1afea9@oemcomputer> <6.0.0.22.0.20041115112329.04332cb8@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.22.0.20041115112329.04332cb8@mira-sjc5-a.cisco.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Mon, Nov 15, 2004 at 11:44:03AM -0800, Kaushik Narayan wrote: > There can be multiple schemes of authorization as discussed previously > on the list. You could verify the engine ID to authorize based on the > identity > of the engine requesting the keys, there could also be policies for unknown > engine IDs which might be based on user access to agents. Would it make sense to leverage SNMP URIs in this context? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 16 12:58:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24729; Tue, 16 Nov 2004 12:58:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7dB-0003Vj-Ox; Tue, 16 Nov 2004 13:00:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7RA-0003i7-Ak; Tue, 16 Nov 2004 12:48:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7K8-0001g9-6v for isms@megatron.ietf.org; Tue, 16 Nov 2004 12:41:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23016 for ; Tue, 16 Nov 2004 12:40:57 -0500 (EST) Message-Id: <200411161740.MAA23016@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7MM-0002yp-3R for isms@ietf.org; Tue, 16 Nov 2004 12:43:19 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <2004111617402101600t8meie> (Authid: dbharrington); Tue, 16 Nov 2004 17:40:21 +0000 From: "David B Harrington" To: Date: Tue, 16 Nov 2004 12:40:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTMA1WqFbGbpVDORi6TBRMM+g6MAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Isms] Draft-schoenw-snmp-tlsm-01.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Hi, Today I submitted draft-schoenw-snmp-tlsm-01.txt to internet-drafts for publication. This is the updated version I referenced during the meeting. I recommend the eval team use the -02- version rather than the -00- version. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 18 14:33:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24613; Thu, 18 Nov 2004 14:33:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUs56-0001Lt-Nw; Thu, 18 Nov 2004 14:36:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrqG-0002IO-EM; Thu, 18 Nov 2004 14:21:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrlI-00014I-VP for isms@megatron.ietf.org; Thu, 18 Nov 2004 14:16:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23169 for ; Thu, 18 Nov 2004 14:16:07 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUrnv-0000vX-0g for isms@ietf.org; Thu, 18 Nov 2004 14:18:55 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2004 12:20:18 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAIJFRPJ019753; Thu, 18 Nov 2004 11:15:27 -0800 (PST) Received: from kaushik-w2k02.cisco.com (dhcp-171-69-71-122.cisco.com [171.69.71.122]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVW13498; Thu, 18 Nov 2004 11:14:22 -0800 (PST) Message-Id: <6.0.0.22.0.20041118111038.03ae4fc8@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 18 Nov 2004 11:15:26 -0800 To: j.schoenwaelder@iu-bremen.de From: Kaushik Narayan Subject: Re: Fwd: [Isms] EUSM key localization details In-Reply-To: <20041115200803.GA3793@james> References: <016901c4cae1$9ce32240$7f1afea9@oemcomputer> <6.0.0.22.0.20041115112329.04332cb8@mira-sjc5-a.cisco.com> <20041115200803.GA3793@james> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi Juergen, Are you suggesting the use of SNMP URIs to identify agents and passed in the key request to the key server? regards, kaushik! At 12:08 PM 11/15/2004, Juergen Schoenwaelder wrote: >On Mon, Nov 15, 2004 at 11:44:03AM -0800, Kaushik Narayan wrote: > > > There can be multiple schemes of authorization as discussed previously > > on the list. You could verify the engine ID to authorize based on the > > identity > > of the engine requesting the keys, there could also be policies for unknown > > engine IDs which might be based on user access to agents. > >Would it make sense to leverage SNMP URIs in this context? > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 18 14:58:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28745; Thu, 18 Nov 2004 14:58:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsTC-000212-Iq; Thu, 18 Nov 2004 15:01:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsJb-0000AW-Dn; Thu, 18 Nov 2004 14:51:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsCm-0006ze-Sx for isms@megatron.ietf.org; Thu, 18 Nov 2004 14:44:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25748 for ; Thu, 18 Nov 2004 14:44:30 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsFR-0001YJ-UG for isms@ietf.org; Thu, 18 Nov 2004 14:47:19 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 22E40352A; Thu, 18 Nov 2004 20:43:46 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24326-05; Thu, 18 Nov 2004 20:43:45 +0100 (CET) Received: from james (unknown [169.237.218.204]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 91E9E3544; Thu, 18 Nov 2004 20:43:44 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CUsBy-0000yX-Rz; Thu, 18 Nov 2004 20:43:42 +0100 Date: Thu, 18 Nov 2004 20:43:42 +0100 From: Juergen Schoenwaelder To: Kaushik Narayan Subject: Re: Fwd: [Isms] EUSM key localization details Message-ID: <20041118194342.GA3735@james> Mail-Followup-To: Kaushik Narayan , Joseph Salowey , isms@ietf.org References: <016901c4cae1$9ce32240$7f1afea9@oemcomputer> <6.0.0.22.0.20041115112329.04332cb8@mira-sjc5-a.cisco.com> <20041115200803.GA3793@james> <6.0.0.22.0.20041118111038.03ae4fc8@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.22.0.20041118111038.03ae4fc8@mira-sjc5-a.cisco.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Thu, Nov 18, 2004 at 11:15:26AM -0800, Kaushik Narayan wrote: > Are you suggesting the use of SNMP URIs to identify agents > and passed in the key request to the key server? I have not read the EUSM specs in detail - it just sounded from the uniformed outside like you needed to identify SNMP service endpoints which SNMP URIs are supposed to do (and they can carry engineIDs). So take it as a suggestion to think about - I am not going to fight for this if the folks who are much more familiar with EUSM think this is a stupid suggestion. (Keith is involved in the SNMP URI stuff and in EUSM so he should be able to give a quick answer.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 18 16:37:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18690; Thu, 18 Nov 2004 16:37:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUu1I-0007YL-GR; Thu, 18 Nov 2004 16:40:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtet-0004F3-6B; Thu, 18 Nov 2004 16:17:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsv1-0008AP-7n for isms@megatron.ietf.org; Thu, 18 Nov 2004 15:30:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03633 for ; Thu, 18 Nov 2004 15:30:12 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsxg-0002wh-T5 for isms@ietf.org; Thu, 18 Nov 2004 15:33:02 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 18 Nov 2004 12:33:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAIKTT3O021558; Thu, 18 Nov 2004 12:29:29 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA04598; Thu, 18 Nov 2004 12:29:39 -0800 (PST) From: Keith McCloghrie Message-Id: <200411182029.MAA04598@cisco.com> Subject: Re: Fwd: [Isms] EUSM key localization details To: j.schoenwaelder@iu-bremen.de Date: Thu, 18 Nov 2004 12:29:39 -0800 (PST) In-Reply-To: <20041118194342.GA3735@james> from "Juergen Schoenwaelder" at Nov 18, 2004 08:43:42 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit > > Are you suggesting the use of SNMP URIs to identify agents > > and passed in the key request to the key server? > > I have not read the EUSM specs in detail - it just sounded from the > uniformed outside like you needed to identify SNMP service endpoints > which SNMP URIs are supposed to do (and they can carry engineIDs). > > So take it as a suggestion to think about - I am not going to fight > for this if the folks who are much more familiar with EUSM think > this is a stupid suggestion. (Keith is involved in the SNMP URI > stuff and in EUSM so he should be able to give a quick answer.) There is at least one non-SNMP situation (and there will likely be more in the future), where a URL/URI format was selected as a generic mechanism to identify management information (and how to access it). In order to extend that one situation to include SNMP and MIB objects, and because there was no standard method to use for such encoding, an ad hoc method was used. The "SNMP URI stuff" is trying to do catch-up by specifying a standard and avoid future anarchy in such situations. I think it would be overkill to use an URI in EUSM merely for the purpose of encoding an engine-id. Keith. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Nov 25 11:02:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24229; Thu, 25 Nov 2004 11:02:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXM8g-0007H2-7X; Thu, 25 Nov 2004 11:06:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLzU-00057K-EO; Thu, 25 Nov 2004 10:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLqr-0002Rl-8G for isms@megatron.ietf.org; Thu, 25 Nov 2004 10:48:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23024 for ; Thu, 25 Nov 2004 10:48:06 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXLux-0006ry-39 for isms@ietf.org; Thu, 25 Nov 2004 10:52:23 -0500 Received: from pc6 (1Cust148.tnt109.lnd4.gbr.da.uu.net [62.188.172.148]) by galaxy.systems.pipex.net (Postfix) with SMTP id 64288E000312; Thu, 25 Nov 2004 15:47:32 +0000 (GMT) Message-ID: <001901c4d2fd$accd21a0$0601a8c0@pc6> From: "Tom Petch" To: "Joseph Salowey" , References: Subject: Re: Fwd: [Isms] EUSM key localization details Date: Thu, 25 Nov 2004 14:15:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit I wish you did not use the terms SNMP agent and SNMP manager; I am never quite sure if that is what you mean, perhaps because manager-manager communication has been an integral part of network management for me for ages. I think SNMPv3 got it right in principle with authoritative and non-authoratitive engines, but might have found better words, easier to say, spell and type:-( I prefer client and server or in my own private jottings use autheng and nautheng. Tom Petch NW Networks ----- Original Message ----- From: "Joseph Salowey" To: "'Blumenthal, Uri'" ; Sent: Monday, November 15, 2004 7:20 PM Subject: RE: Fwd: [Isms] EUSM key localization details > Hi Uri, > > We should use existing EAP methods that generate keys, we don't really want > to create special methods for SNMP. > > There are basically three parts to the proposal. > > 1. Authenticated Key setup between SNMP manager and key server > > This protocol should authenticate the user and the key server, establish a > strong key, and be flexible in mechanism. We suggest using EAP in RADIUS. > The EAP framwework is useful because it integrates with AAA servers for > authentication. The EAP methods used should not be SNMP specific. > > 2. Communication of keys from key server to SNMP agent > > This requires secure transmission of the correct localized SNMPv3 keys from > key server to agent. If the key server is co-located with the agent then > this is a local API matter. If the key server is remote from the agent then > you can gain the benefit that one key setup procedure can be used to set up > a key that can be the basis for security for many agents. We suggest using > some extensions to RADIUS for this key transport. It would also be useful > to communicate other parameters such as VACM information to the agent in > this protocol as well. RADIUS is useful since many entities containing > agents are RADIUS clients as well. > > 3. EUSM enhancement to SNMPv3 between agent and manager > > This is enhancements to SNMPv3 to support key material that is established > external to SNMP processing. The main goal here was to keep changes to > SNMPv3 as minimal as possible. > > Joe > > isms-bounces@lists.ietf.org wrote: > > Yes, AAA must receive the snmpEngineID in order to compute > > localized key, and AAA should verify authorization. Re. > > newtributes - a new EAP method is being defined anyway, right? > > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Joseph Salowey > > Sent: Monday, November 15, 2004 11:50 AM > > To: 'Randy Presuhn'; isms@ietf.org > > Subject: RE: Fwd: [Isms] EUSM key localization details > > > > > > > > isms-bounces@lists.ietf.org wrote: > >> Hi - > >> > >>> From: "Kaushik Narayan" > >>> To: "Wes Hardaker" > >>> Cc: > >>> Sent: Saturday, November 06, 2004 10:33 AM > >>> Subject: Re: Fwd: [Isms] EUSM key localization details ... > >>> This would mean that agents do-not need to acquire keys to serve an > >>> SNMPv3 engine ID discovery request and SNMP Managers can discovery > >>> engine IDs and bootstrap the AAA server. > >> ... > >> > >> Which brings us back to my question at the start of this thread: > >> how does the AAA server know *which* of the SNMP engine IDs to use? > >> The information described in the proposal as flowing in > >> the RADIUS Key_Request (Key (App ID), Calling-Station-ID, > >> User-Name) is not sufficient to map to a single engine ID, since > >> there may be multiple SNMP engines in a single system. > >> > > > > [Joe] Yes I think we need an attribute to contain the SNMP > > Engine ID making the request. I'm not sure if we can use > > existing attributes to convey this information, we may need > > to create a new one. The AAA server still should verify that > > the engine ID is authorized to the RADIUS client making the request. > > > >> Randy > >> > >> > >> > >> _______________________________________________ > >> Isms mailing list > >> Isms@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 26 14:12:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11136; Fri, 26 Nov 2004 14:12:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXlao-0002Gb-JN; Fri, 26 Nov 2004 14:17:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXlVS-0000ai-DC; Fri, 26 Nov 2004 14:11:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXlRq-00089U-0L for isms@megatron.ietf.org; Fri, 26 Nov 2004 14:08:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10710 for ; Fri, 26 Nov 2004 14:08:01 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXlWA-00026l-5I for isms@ietf.org; Fri, 26 Nov 2004 14:12:31 -0500 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CXlRi-0002ZA-7T for isms@ietf.org; Fri, 26 Nov 2004 14:07:54 -0500 Date: Fri, 26 Nov 2004 14:07:55 -0500 From: Robert Story To: isms@ietf.org Message-ID: <20041126140755.0485f3b6@dev.localdomain> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Isms] Evaluation process? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit As the November deadline for the evaluation team is rapidly approaching, I was wondering how the evaluation team was doing. Is it appropriate to ask, or is the evaluation process done behind closed doors? -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 26 14:24:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12445; Fri, 26 Nov 2004 14:24:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXllf-0002jB-BV; Fri, 26 Nov 2004 14:28:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXlfP-0002Gn-2y; Fri, 26 Nov 2004 14:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXldl-0001tr-TP for isms@megatron.ietf.org; Fri, 26 Nov 2004 14:20:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11949 for ; Fri, 26 Nov 2004 14:20:20 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXli6-0002YL-LY for isms@ietf.org; Fri, 26 Nov 2004 14:24:51 -0500 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id iAQJJdKk026144; Fri, 26 Nov 2004 11:19:39 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id iAQJJctS027671; Fri, 26 Nov 2004 11:19:38 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id iAQJJcm5027666; Fri, 26 Nov 2004 11:19:38 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 26 Nov 2004 11:19:38 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Tom Petch Subject: Re: Fwd: [Isms] EUSM key localization details In-Reply-To: <001901c4d2fd$accd21a0$0601a8c0@pc6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 HI, Tom - it is difficult to determine, since it was somewhat of a passing reference, but you raised some red flags and may not understand the SNMPv3 architecture and protocol. The terms "authoritative and non-authoritative engineIDs" are NOT SNMPv3 protocol terms, but are specific to the user security model (USM). The concept is required in USM due to the shared value of a "clock" that is used to help with replay protection, and to a lesser degree the shared identity (and keys) used for message integrity and content privacy. Other security models don't use the terms "authoritative and non-autoritative engineIDs". Also, with USM these terms do not map to "operation initiator and responder" or "client and server". So, I'm confused as to why you used them in complaining about use of terms manager and agent. Would you explain. On Thu, 25 Nov 2004, Tom Petch wrote: > I wish you did not use the terms SNMP agent and SNMP manager; I am never > quite sure if that is what you mean, perhaps because manager-manager > communication has been an integral part of network management for me for > ages. > > I think SNMPv3 got it right in principle with authoritative and > non-authoratitive engines, but might have found better words, easier to > say, spell and type:-( > > I prefer client and server or in my own private jottings use autheng and > nautheng. > > Tom Petch > NW Networks Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Nov 26 16:26:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24830; Fri, 26 Nov 2004 16:26:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXngQ-0007hr-4B; Fri, 26 Nov 2004 16:31:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXnb6-00029O-ES; Fri, 26 Nov 2004 16:25:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXnap-00025X-N6 for isms@megatron.ietf.org; Fri, 26 Nov 2004 16:25:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24757 for ; Fri, 26 Nov 2004 16:25:25 -0500 (EST) Message-Id: <200411262125.QAA24757@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXnfB-0007bp-Kv for isms@ietf.org; Fri, 26 Nov 2004 16:29:58 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004112621245501400reio9e>; Fri, 26 Nov 2004 21:24:55 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'Joseph Salowey'" , Subject: RE: Fwd: [Isms] EUSM key localization details Date: Fri, 26 Nov 2004 16:24:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <001901c4d2fd$accd21a0$0601a8c0@pc6> Thread-Index: AcTTCCNh+A8Yk5pfSoObn/PhJgZimAA6X91A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: 7bit Hi Tom, Let mne respond to two threads within the current thread. 1) Distinguishing Entities I suggest the better choice of wording to distinguish the roles of two SNMPv3 entities is to discuss the application being used, per RFC3413. Is each role one of command generator, command responder, notification originator, notification receiver, proxy forwarder, or other yet-to-be-defined application role? We deliberately stopped using agent and manager after the SNMPv2 and its variations because too many entities do not fit the classic definition of agent or manager, and the need to keep security vitual databases on both the agent and receiver made it very complex to determine whether an emtity was operating in an agent or manager role. 2) Authoritative and the SNMPv3 Architecture The concept of an authoritative engine is part of the architecture described in RFC3411 and RFC3412; it is part of the generateRequestMsg(), processIncomingMsg(), generateResponseMsg() ASIs between the message-processing subsystem and the security subsystem. It is important to identify which virtual database should be used for the security credentials when processing an SNMP message. USM is the first concrete specification of how and when to utilize authoritative credentials, and the SNMPv3 message format is the first concrete specification of a message format which includes a securityEngineID. RFC3412 section 7 is devoted to SNMPv3-message processing (v3MP), and describes how the v3MP and potentially-multiple security models share the knowledge of which engine is authoritative. Another message processing model would be expected to pass the authoritative engine between subsystems. Different add-on message processing models and different add-on security models may impact which engine is authoritative, and no assumptions should be made that future usage will necessarily be consistent with the v3MP/USM usage. The use of authoritative is rather complex, and I recommend that it NOT be used to distinguish the functional roles of the entities. I recommend it only be used when discussing a specific security model's approach to authoritative. General note on ASIs: Note that RFC3411 and RFC3412 describe conceptual application service interfaces (ASIs), which are present only to make it easier to develop add-on modules, such as new security models. The ASIs of RFC3411 and RFC3412 identify the conceptual information that theoretically is necessary to share between architectural subsystems (and models of those subsystems). When a security model uses an authoritative engine, it shares the identity of the authoritative engine with the messaging processing subsystem in the architecture via the securityEngineID parameter of the relevant ASI. The SNMPv3 design team recommended that the conceptual information used within a subsystem's model SHOULD NOT be shared with other subsystems, unless necessary, in order to prevent creating dependencies between models of different subsystems, i.e. for "data hiding" reasons. The avoidance of inter-subsystem dependencies was very deliberately done to allow different models to advance in the standards track independently of each other. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Thursday, November 25, 2004 8:15 AM > To: Joseph Salowey; isms@ietf.org > Subject: Re: Fwd: [Isms] EUSM key localization details > > I wish you did not use the terms SNMP agent and SNMP manager; > I am never quite sure if that is what you mean, perhaps > because manager-manager communication has been an integral > part of network management for me for ages. > > I think SNMPv3 got it right in principle with authoritative > and non-authoratitive engines, but might have found better > words, easier to say, spell and type:-( > > I prefer client and server or in my own private jottings use > autheng and nautheng. > > Tom Petch > NW Networks > ----- Original Message ----- > From: "Joseph Salowey" > To: "'Blumenthal, Uri'" ; > Sent: Monday, November 15, 2004 7:20 PM > Subject: RE: Fwd: [Isms] EUSM key localization details > > > > Hi Uri, > > > > We should use existing EAP methods that generate keys, we > don't really > want > > to create special methods for SNMP. > > > > There are basically three parts to the proposal. > > > > 1. Authenticated Key setup between SNMP manager and key server > > > > This protocol should authenticate the user and the key server, > establish a > > strong key, and be flexible in mechanism. We suggest using EAP in > RADIUS. > > The EAP framwework is useful because it integrates with AAA servers > for > > authentication. The EAP methods used should not be SNMP specific. > > > > 2. Communication of keys from key server to SNMP agent > > > > This requires secure transmission of the correct localized > SNMPv3 keys > from > > key server to agent. If the key server is co-located with the agent > then > > this is a local API matter. If the key server is remote from the > agent then > > you can gain the benefit that one key setup procedure can be used to > set up > > a key that can be the basis for security for many agents. > We suggest > using > > some extensions to RADIUS for this key transport. It would also be > useful > > to communicate other parameters such as VACM information to > the agent > in > > this protocol as well. RADIUS is useful since many entities > containing > > agents are RADIUS clients as well. > > > > 3. EUSM enhancement to SNMPv3 between agent and manager > > > > This is enhancements to SNMPv3 to support key material that is > established > > external to SNMP processing. The main goal here was to keep changes > to > > SNMPv3 as minimal as possible. > > > > Joe > > > > isms-bounces@lists.ietf.org wrote: > > > Yes, AAA must receive the snmpEngineID in order to compute > > > localized key, and AAA should verify authorization. Re. > > > newtributes - a new EAP method is being defined anyway, right? > > > > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Joseph Salowey > > > Sent: Monday, November 15, 2004 11:50 AM > > > To: 'Randy Presuhn'; isms@ietf.org > > > Subject: RE: Fwd: [Isms] EUSM key localization details > > > > > > > > > > > > isms-bounces@lists.ietf.org wrote: > > >> Hi - > > >> > > >>> From: "Kaushik Narayan" > > >>> To: "Wes Hardaker" > > >>> Cc: > > >>> Sent: Saturday, November 06, 2004 10:33 AM > > >>> Subject: Re: Fwd: [Isms] EUSM key localization details ... > > >>> This would mean that agents do-not need to acquire keys to serve > an > > >>> SNMPv3 engine ID discovery request and SNMP Managers > can discovery > > >>> engine IDs and bootstrap the AAA server. > > >> ... > > >> > > >> Which brings us back to my question at the start of this thread: > > >> how does the AAA server know *which* of the SNMP engine > IDs to use? > > >> The information described in the proposal as flowing in > > >> the RADIUS Key_Request (Key (App ID), Calling-Station-ID, > > >> User-Name) is not sufficient to map to a single engine ID, since > > >> there may be multiple SNMP engines in a single system. > > >> > > > > > > [Joe] Yes I think we need an attribute to contain the > SNMP Engine ID > > > making the request. I'm not sure if we can use existing > attributes > > > to convey this information, we may need to create a new one. The > > > AAA server still should verify that the engine ID is > authorized to > > > the RADIUS client making the request. > > > > > >> Randy > > >> > > >> > > >> > > >> _______________________________________________ > > >> Isms mailing list > > >> Isms@lists.ietf.org > > >> https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Nov 28 17:42:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22363; Sun, 28 Nov 2004 17:42:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYXor-0007SJ-9g; Sun, 28 Nov 2004 17:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYXeP-0007f4-An; Sun, 28 Nov 2004 17:36:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYXd9-0007R7-Ej for isms@megatron.ietf.org; Sun, 28 Nov 2004 17:34:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21867 for ; Sun, 28 Nov 2004 17:34:53 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYXhv-0007Jz-5P for isms@ietf.org; Sun, 28 Nov 2004 17:39:51 -0500 Received: from pc6 (1Cust80.tnt7.lnd4.gbr.da.uu.net [62.188.136.80]) by galaxy.systems.pipex.net (Postfix) with SMTP id A4A14E0000FE; Sun, 28 Nov 2004 22:34:16 +0000 (GMT) Message-ID: <02eb01c4d591$fa8dfcc0$5088bc3e@pc6> From: "Tom Petch" To: , References: <20041126212456.0C128E0001DB@banzai.systems.pipex.net> Subject: Re: Fwd: [Isms] EUSM key localization details Date: Sun, 28 Nov 2004 22:33:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Content-Transfer-Encoding: 7bit David Thanks for puting me right - I was mixing up several ideas in my enthusiasm to get away from the terminology of agent and manager (which I always see as a bit rigid). Tom Petch NW Networks ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" ; "'Joseph Salowey'" ; Sent: Friday, November 26, 2004 10:24 PM Subject: RE: Fwd: [Isms] EUSM key localization details > Hi Tom, > > Let mne respond to two threads within the current thread. > > 1) Distinguishing Entities > > I suggest the better choice of wording to distinguish the roles of two > SNMPv3 entities is to discuss the application being used, per RFC3413. > Is each role one of command generator, command responder, notification > originator, notification receiver, proxy forwarder, or other > yet-to-be-defined application role? > > We deliberately stopped using agent and manager after the SNMPv2 and > its variations because too many entities do not fit the classic > definition of agent or manager, and the need to keep security vitual > databases on both the agent and receiver made it very complex to > determine whether an emtity was operating in an agent or manager role. > > 2) Authoritative and the SNMPv3 Architecture > > The concept of an authoritative engine is part of the architecture > described in RFC3411 and RFC3412; it is part of the > generateRequestMsg(), processIncomingMsg(), generateResponseMsg() ASIs > between the message-processing subsystem and the security subsystem. > It is important to identify which virtual database should be used for > the security credentials when processing an SNMP message. > > USM is the first concrete specification of how and when to utilize > authoritative credentials, and the SNMPv3 message format is the first > concrete specification of a message format which includes a > securityEngineID. RFC3412 section 7 is devoted to SNMPv3-message > processing (v3MP), and describes how the v3MP and potentially-multiple > security models share the knowledge of which engine is authoritative. > Another message processing model would be expected to pass the > authoritative engine between subsystems. > > Different add-on message processing models and different add-on > security models may impact which engine is authoritative, and no > assumptions should be made that future usage will necessarily be > consistent with the v3MP/USM usage. The use of authoritative is rather > complex, and I recommend that it NOT be used to distinguish the > functional roles of the entities. I recommend it only be used when > discussing a specific security model's approach to authoritative. > > General note on ASIs: > > Note that RFC3411 and RFC3412 describe conceptual application service > interfaces (ASIs), which are present only to make it easier to develop > add-on modules, such as new security models. The ASIs of RFC3411 and > RFC3412 identify the conceptual information that theoretically is > necessary to share between architectural subsystems (and models of > those subsystems). When a security model uses an authoritative engine, > it shares the identity of the authoritative engine with the messaging > processing subsystem in the architecture via the securityEngineID > parameter of the relevant ASI. > > The SNMPv3 design team recommended that the conceptual information > used within a subsystem's model SHOULD NOT be shared with other > subsystems, unless necessary, in order to prevent creating > dependencies between models of different subsystems, i.e. for "data > hiding" reasons. The avoidance of inter-subsystem dependencies was > very deliberately done to allow different models to advance in the > standards track independently of each other. > > David Harrington > dbharrington@comcast.net > > > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > > Sent: Thursday, November 25, 2004 8:15 AM > > To: Joseph Salowey; isms@ietf.org > > Subject: Re: Fwd: [Isms] EUSM key localization details > > > > I wish you did not use the terms SNMP agent and SNMP manager; > > I am never quite sure if that is what you mean, perhaps > > because manager-manager communication has been an integral > > part of network management for me for ages. > > > > I think SNMPv3 got it right in principle with authoritative > > and non-authoratitive engines, but might have found better > > words, easier to say, spell and type:-( > > > > I prefer client and server or in my own private jottings use > > autheng and nautheng. > > > > Tom Petch > > NW Networks > > ----- Original Message ----- > > From: "Joseph Salowey" > > To: "'Blumenthal, Uri'" ; > > Sent: Monday, November 15, 2004 7:20 PM > > Subject: RE: Fwd: [Isms] EUSM key localization details > > > > > > > Hi Uri, > > > > > > We should use existing EAP methods that generate keys, we > > don't really > > want > > > to create special methods for SNMP. > > > > > > There are basically three parts to the proposal. > > > > > > 1. Authenticated Key setup between SNMP manager and key server > > > > > > This protocol should authenticate the user and the key server, > > establish a > > > strong key, and be flexible in mechanism. We suggest using EAP in > > RADIUS. > > > The EAP framwework is useful because it integrates with AAA > servers > > for > > > authentication. The EAP methods used should not be SNMP specific. > > > > > > 2. Communication of keys from key server to SNMP agent > > > > > > This requires secure transmission of the correct localized > > SNMPv3 keys > > from > > > key server to agent. If the key server is co-located with the > agent > > then > > > this is a local API matter. If the key server is remote from the > > agent then > > > you can gain the benefit that one key setup procedure can be used > to > > set up > > > a key that can be the basis for security for many agents. > > We suggest > > using > > > some extensions to RADIUS for this key transport. It would also > be > > useful > > > to communicate other parameters such as VACM information to > > the agent > > in > > > this protocol as well. RADIUS is useful since many entities > > containing > > > agents are RADIUS clients as well. > > > > > > 3. EUSM enhancement to SNMPv3 between agent and manager > > > > > > This is enhancements to SNMPv3 to support key material that is > > established > > > external to SNMP processing. The main goal here was to keep > changes > > to > > > SNMPv3 as minimal as possible. > > > > > > Joe > > > > > > isms-bounces@lists.ietf.org wrote: > > > > Yes, AAA must receive the snmpEngineID in order to compute > > > > localized key, and AAA should verify authorization. Re. > > > > newtributes - a new EAP method is being defined anyway, right? > > > > > > > > -----Original Message----- > > > > From: isms-bounces@lists.ietf.org > > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Joseph Salowey > > > > Sent: Monday, November 15, 2004 11:50 AM > > > > To: 'Randy Presuhn'; isms@ietf.org > > > > Subject: RE: Fwd: [Isms] EUSM key localization details > > > > > > > > > > > > > > > > isms-bounces@lists.ietf.org wrote: > > > >> Hi - > > > >> > > > >>> From: "Kaushik Narayan" > > > >>> To: "Wes Hardaker" > > > >>> Cc: > > > >>> Sent: Saturday, November 06, 2004 10:33 AM > > > >>> Subject: Re: Fwd: [Isms] EUSM key localization details ... > > > >>> This would mean that agents do-not need to acquire keys to > serve > > an > > > >>> SNMPv3 engine ID discovery request and SNMP Managers > > can discovery > > > >>> engine IDs and bootstrap the AAA server. > > > >> ... > > > >> > > > >> Which brings us back to my question at the start of this > thread: > > > >> how does the AAA server know *which* of the SNMP engine > > IDs to use? > > > >> The information described in the proposal as flowing in > > > >> the RADIUS Key_Request (Key (App ID), Calling-Station-ID, > > > >> User-Name) is not sufficient to map to a single engine ID, > since > > > >> there may be multiple SNMP engines in a single system. > > > >> > > > > > > > > [Joe] Yes I think we need an attribute to contain the > > SNMP Engine ID > > > > making the request. I'm not sure if we can use existing > > attributes > > > > to convey this information, we may need to create a new one. > The > > > > AAA server still should verify that the engine ID is > > authorized to > > > > the RADIUS client making the request. > > > > > > > >> Randy > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> Isms mailing list > > > >> Isms@lists.ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 29 13:17:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16395; Mon, 29 Nov 2004 13:17:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqAq-0007zo-Bf; Mon, 29 Nov 2004 13:22:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYq4O-0002aM-6L; Mon, 29 Nov 2004 13:16:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYq33-0002JD-57 for isms@megatron.ietf.org; Mon, 29 Nov 2004 13:14:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16246 for ; Mon, 29 Nov 2004 13:14:50 -0500 (EST) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYq7z-0007wI-Uu for isms@ietf.org; Mon, 29 Nov 2004 13:20:00 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 54D7711D82A; Mon, 29 Nov 2004 10:14:44 -0800 (PST) To: Robert Story Subject: Re: [Isms] Evaluation process? References: <20041126140755.0485f3b6@dev.localdomain> From: Wes Hardaker Organization: Sparta Date: Mon, 29 Nov 2004 10:14:43 -0800 In-Reply-To: <20041126140755.0485f3b6@dev.localdomain> (Robert Story's message of "Fri, 26 Nov 2004 14:07:55 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >>>>> On Fri, 26 Nov 2004 14:07:55 -0500, Robert Story said: Robert> As the November deadline for the evaluation team is rapidly Robert> approaching, I was wondering how the evaluation team was Robert> doing. Is it appropriate to ask, or is the evaluation process Robert> done behind closed doors? Funny, I was going to ask the same question but wait till Nov 1! So, an update to the WG would certainly be nice. If a decision is reached, I know that the plans are to write up a draft to summarize it, but a quick summary earlier on the list would be helpful. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 29 13:34:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17733; Mon, 29 Nov 2004 13:34:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqRS-0008Le-2N; Mon, 29 Nov 2004 13:40:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqHu-0004OG-Ok; Mon, 29 Nov 2004 13:30:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqA5-0003Ne-Dz for isms@megatron.ietf.org; Mon, 29 Nov 2004 13:22:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16624 for ; Mon, 29 Nov 2004 13:22:06 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqF2-00084A-Ad for isms@ietf.org; Mon, 29 Nov 2004 13:27:16 -0500 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id iATIM0uq029005 for ; Mon, 29 Nov 2004 13:22:01 -0500 (EST) Message-Id: <200411291822.iATIM0uq029005@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Evaluation process? In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 29 Nov 2004 13:22:00 -0500 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 >Funny, I was going to ask the same question but wait till Nov 1! I sure hope you mean December 1 :-) >So, an update to the WG would certainly be nice. If a decision is >reached, I know that the plans are to write up a draft to summarize >it, but a quick summary earlier on the list would be helpful. The process has started, but not gotten very far; I was on another trip after IETF, and was off most of last week, and I suspect many of the evaluation team members were as will (I have a bunch of email to reply to about this). I was thinking of pushing back the deadline (since I doubt we're going to meet it) for at least a couple of weeks, if no one objects (I haven't yet consulted Juergen on this, so this isn't definite). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 29 13:54:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19124; Mon, 29 Nov 2004 13:54:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqjt-0000GZ-I5; Mon, 29 Nov 2004 13:59:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqeG-0001r2-Lh; Mon, 29 Nov 2004 13:53:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqVI-0006GK-8S for isms@megatron.ietf.org; Mon, 29 Nov 2004 13:44:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18222 for ; Mon, 29 Nov 2004 13:44:03 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqaC-0008Un-IY for isms@ietf.org; Mon, 29 Nov 2004 13:49:11 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA04689; Mon, 29 Nov 2004 10:43:16 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iATIhGD16763; Mon, 29 Nov 2004 10:43:16 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 10:43:13 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Isms] Evaluation process? Date: Mon, 29 Nov 2004 10:43:12 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDA23@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Evaluation process? Thread-Index: AcTWQwH2dwweJITnTgW4pRkoWfMzigAAC4Ag From: "Fleischman, Eric" To: "Ken Hornstein" , X-OriginalArrivalTime: 29 Nov 2004 18:43:13.0282 (UTC) FILETIME=[48077E20:01C4D643] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable What criteria (and requirements) are the proposals be evaluated against? -----Original Message----- From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]=20 Sent: Monday, November 29, 2004 10:22 AM To: isms@ietf.org Subject: Re: [Isms] Evaluation process?=20 >Funny, I was going to ask the same question but wait till Nov 1! I sure hope you mean December 1 :-) >So, an update to the WG would certainly be nice. If a decision is=20 >reached, I know that the plans are to write up a draft to summarize it, >but a quick summary earlier on the list would be helpful. The process has started, but not gotten very far; I was on another trip after IETF, and was off most of last week, and I suspect many of the evaluation team members were as will (I have a bunch of email to reply to about this). I was thinking of pushing back the deadline (since I doubt we're going to meet it) for at least a couple of weeks, if no one objects (I haven't yet consulted Juergen on this, so this isn't definite). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 29 15:13:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26541; Mon, 29 Nov 2004 15:13:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYryx-00020t-0t; Mon, 29 Nov 2004 15:18:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrlo-0008GK-15; Mon, 29 Nov 2004 15:05:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrj2-0005jW-4p for isms@megatron.ietf.org; Mon, 29 Nov 2004 15:02:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25102 for ; Mon, 29 Nov 2004 15:02:18 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrnz-0001o1-8K for isms@ietf.org; Mon, 29 Nov 2004 15:07:28 -0500 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id iATK2DU5001512 for ; Mon, 29 Nov 2004 15:02:13 -0500 (EST) Message-Id: <200411292002.iATK2DU5001512@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Evaluation process? In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDA23@xch-nw-09.nw.nos.boeing.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 29 Nov 2004 15:02:13 -0500 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 >What criteria (and requirements) are the proposals be evaluated against? The requirements have been proposed on the mailing list (see the archives for more detail). As for the criteria ... "we're working on it". A I-D detailing these things should be forthcoming. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 29 15:16:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26994; Mon, 29 Nov 2004 15:16:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYs1d-00024I-47; Mon, 29 Nov 2004 15:21:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrlz-0008Ui-Id; Mon, 29 Nov 2004 15:05:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrlF-0007iK-Ap for isms@megatron.ietf.org; Mon, 29 Nov 2004 15:04:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25295 for ; Mon, 29 Nov 2004 15:04:35 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrqC-0001pu-Bl for isms@ietf.org; Mon, 29 Nov 2004 15:09:45 -0500 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CYrl7-0004kO-CZ for isms@ietf.org; Mon, 29 Nov 2004 15:04:29 -0500 Date: Mon, 29 Nov 2004 15:04:29 -0500 From: Robert Story Subject: Re: [Isms] Evaluation process? Message-ID: <20041129150429.0b9a63b2@dev.localdomain> In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDA23@xch-nw-09.nw.nos.boeing.com> References: <5B58696DB20B9140AD20E0685C573A6404FDDA23@xch-nw-09.nw.nos.boeing.com> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit On Mon, 29 Nov 2004 10:43:12 -0800 Fleischman, wrote: FE> What criteria (and requirements) are the proposals be evaluated against? I was wondering about that too. On the one hand, I can see the benefits of a 'behind-closed-doors' evaluation, in that the evaluators wouldn't have to deal with constantly defending their position, as they would if the whole process took place on the mailing lists. On the other hand, I'd hate to see an recommendation made based on a misunderstanding of one of the proposals. Hopefully at least the draft authors are involved, answering questions, and that communication will be made available (or at least summarized) with the recommendation. On Mon, 29 Nov 2004 13:22:00 -0500 Ken wrote: KH> The process has started, but not gotten very far KH> KH> I was thinking of pushing back the deadline (since I doubt we're going to KH> meet it) for at least a couple of weeks, if no one objects I'd rather have a slightly late but more informed evaluation over an on-time but rushed one... -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 29 17:22:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19980; Mon, 29 Nov 2004 17:22:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYtze-0000mM-91; Mon, 29 Nov 2004 17:27:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYtfR-0006th-Ux; Mon, 29 Nov 2004 17:06:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYsJG-0002zo-F2 for isms@megatron.ietf.org; Mon, 29 Nov 2004 15:39:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00377 for ; Mon, 29 Nov 2004 15:39:44 -0500 (EST) Received: from adsl-64-165-72-146.dsl.scrm01.pacbell.net ([64.165.72.146] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYsOD-0002xl-RT for isms@ietf.org; Mon, 29 Nov 2004 15:44:55 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 73F3511D85E; Mon, 29 Nov 2004 12:39:35 -0800 (PST) To: Robert Story Subject: Re: [Isms] Evaluation process? References: <5B58696DB20B9140AD20E0685C573A6404FDDA23@xch-nw-09.nw.nos.boeing.com> <20041129150429.0b9a63b2@dev.localdomain> From: Wes Hardaker Organization: Sparta Date: Mon, 29 Nov 2004 12:39:35 -0800 In-Reply-To: <20041129150429.0b9a63b2@dev.localdomain> (Robert Story's message of "Mon, 29 Nov 2004 15:04:29 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 >>>>> On Mon, 29 Nov 2004 15:04:29 -0500, Robert Story said: Robert> I was wondering about that too. On the one hand, I can see the Robert> benefits of a 'behind-closed-doors' evaluation, in that the Robert> evaluators wouldn't have to deal with constantly defending Robert> their position, as they would if the whole process took place Robert> on the mailing lists. Sigh... The IETF has done many different ways of evaluating different proposals in the past. Generally they've all had problems of some sort or another in every case. In many of them in disastrous ways. The worst thing about a closed-doors or limited-number-of-people mechanism is that the industry could just give up if they came up with a solution no one wanted ;-) Robert> Hopefully at least the draft authors are involved, answering Robert> questions, and that communication will be made available (or Robert> at least summarized) with the recommendation. The draft authors were requested (on the list a while ago) to select one person per draft as a point of contact for questions. KH> I was thinking of pushing back the deadline (since I doubt we're KH> going to meet it) for at least a couple of weeks, if no one KH> objects Robert> I'd rather have a slightly late but more informed evaluation Robert> over an on-time but rushed one... The ADs mandated a quick decision in order for the WG to exist. If a decision isn't made by March the WG is to be shutdown. Unfortunately, that may mean a less than ideal analysis process. The flip side is that we can't rathole. Choose your poison. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Nov 29 20:44:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07658; Mon, 29 Nov 2004 20:44:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYx8w-0005Yr-7B; Mon, 29 Nov 2004 20:49:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYx1Y-0002Yw-Ah; Mon, 29 Nov 2004 20:41:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYwxv-0001lk-6v for isms@megatron.ietf.org; Mon, 29 Nov 2004 20:38:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07331 for ; Mon, 29 Nov 2004 20:38:01 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYx2v-0005Qz-5L for isms@ietf.org; Mon, 29 Nov 2004 20:43:14 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA10555; Mon, 29 Nov 2004 17:37:24 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iAU1bNi21213; Mon, 29 Nov 2004 17:37:23 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 17:37:23 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Isms] Evaluation process? Date: Mon, 29 Nov 2004 17:37:23 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDA29@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Evaluation process? Thread-Index: AcTWYgk6vSAFTfw4QJC8QLTMeuA9dAAGIcQg From: "Fleischman, Eric" To: "Wes Hardaker" , "Robert Story" X-OriginalArrivalTime: 30 Nov 2004 01:37:23.0600 (UTC) FILETIME=[23F91900:01C4D67D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable I do have a very parochial reason for asking about the ISMS criteria (and requirements) by which the proposals will be judged.=20 I first brought up the issue of SNMPv3 USM security inadequacies in the SNMP mail list two years ago when I discovered how terribly USM played in our environment. Partially due to my urging, Wes Hardaker and David Perkins started the many BOFs that became the ISMS WG. If the ISMS results won't produce an (SNMPv3) USM-like variant (or adjunct) that cleanly works with PKI, then my efforts in arguing for the formation of this WG would have been wasted. Consequently, I care very much about the criteria by which the submissions are being judged. I know that not every entity is deploying corporate-wide PKI infrastructures, but I strongly believe that a prime requirement for ISMS is that the selected protocol MUST be able to integrate with the major existing corporate key management systems. These infrastructures include PKI, Kerberos, RADIUS, and possibly a few others. I also believe that the protocol MUST resolve the existing security problems with SNMPv3 USM which are: 1) no provisions for two-factored authentication 2) SNMP symmetric keys may be assembled from passwords 3) Key updates do not provide for Perfect Forward Security 4) Inherent Symmetric Key distribution problems 5) Lack of viable session keys --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 30 10:43:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29667; Tue, 30 Nov 2004 10:43:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAFF-0006iB-S2; Tue, 30 Nov 2004 10:48:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZA8T-0008Qm-6i; Tue, 30 Nov 2004 10:41:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9zv-0007Eq-Ls for isms@megatron.ietf.org; Tue, 30 Nov 2004 10:32:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28677 for ; Tue, 30 Nov 2004 10:32:57 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZA53-0006TN-O8 for isms@ietf.org; Tue, 30 Nov 2004 10:38:18 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 858941BAC99; Tue, 30 Nov 2004 16:32:23 +0100 (CET) Date: Tue, 30 Nov 2004 16:32:24 +0100 From: Juergen Quittek To: Ken Hornstein , isms@ietf.org Subject: Re: [Isms] Evaluation process? Message-ID: <2147483647.1101832344@[10.1.1.171]> In-Reply-To: <200411291822.iATIM0uq029005@ginger.cmf.nrl.navy.mil> References: <200411291822.iATIM0uq029005@ginger.cmf.nrl.navy.mil> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit --On 29.11.2004 13:22 h -0500 Ken Hornstein wrote: >> Funny, I was going to ask the same question but wait till Nov 1! > > I sure hope you mean December 1 :-) > >> So, an update to the WG would certainly be nice. If a decision is >> reached, I know that the plans are to write up a draft to summarize >> it, but a quick summary earlier on the list would be helpful. > > The process has started, but not gotten very far; I was on another trip > after IETF, and was off most of last week, and I suspect many of the > evaluation team members were as will (I have a bunch of email to reply to > about this). > > I was thinking of pushing back the deadline (since I doubt we're going to > meet it) for at least a couple of weeks, if no one objects (I haven't yet > consulted Juergen on this, so this isn't definite). I think we are still fine if we have a recommendation from the evaluation team before Christmas. This will be late but still in time to agree or disagree on the recommendation on the mailing list and, in case of agreement, to discuss a new charter before the next meeting in March. Juergen > --Ken > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Nov 30 11:15:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02609; Tue, 30 Nov 2004 11:15:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAkV-0007cB-PG; Tue, 30 Nov 2004 11:21:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAOw-0004mX-Tg; Tue, 30 Nov 2004 10:58:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAAM-0000h4-Ix for isms@megatron.ietf.org; Tue, 30 Nov 2004 10:43:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29706 for ; Tue, 30 Nov 2004 10:43:44 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAFV-0006hb-1D for isms@ietf.org; Tue, 30 Nov 2004 10:49:05 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8021F1BAC99; Tue, 30 Nov 2004 16:43:13 +0100 (CET) Date: Tue, 30 Nov 2004 16:43:14 +0100 From: Juergen Quittek To: Robert Story Subject: Re: [Isms] Evaluation process? Message-ID: <2147483647.1101832994@[10.1.1.171]> In-Reply-To: <20041129150429.0b9a63b2@dev.localdomain> References: <5B58696DB20B9140AD20E0685C573A6404FDDA23@xch-nw-09.nw.nos.boeing.com> <20041129150429.0b9a63b2@dev.localdomain> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Robert, --On 29.11.2004 15:04 h -0500 Robert Story wrote: > On Mon, 29 Nov 2004 10:43:12 -0800 Fleischman, wrote: > FE> What criteria (and requirements) are the proposals be evaluated against? > > I was wondering about that too. On the one hand, I can see the benefits of a > 'behind-closed-doors' evaluation, in that the evaluators wouldn't have to deal > with constantly defending their position, as they would if the whole process > took place on the mailing lists. The evaluators will have to defend their recommendation anyway. And I never heard of a comparable process where after the recommendation (or decision) nobody complained heavily about it. Since these complaints do not have a tendency to stop soon, the IESG gave us a short deadline for the overall process. > On the other hand, I'd hate to see an recommendation made based on a > misunderstanding of one of the proposals. Everybody does. > Hopefully at least the draft authors are involved, answering questions, and > that communication will be made available (or at least summarized) with the > recommendation. Since the decision will step on somebody's toes anyway, the evaluators should be careful with stating progress before their recommendation is final. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > On Mon, 29 Nov 2004 13:22:00 -0500 Ken wrote: > KH> The process has started, but not gotten very far > KH> > KH> I was thinking of pushing back the deadline (since I doubt we're going to > KH> meet it) for at least a couple of weeks, if no one objects > > I'd rather have a slightly late but more informed evaluation over an on-time > but rushed one... > > -- > Robert Story; NET-SNMP Junkie > Support: > > You are lost in a twisty maze of little standards, all different. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms