From jmh@joelhalpern.com Tue Oct 8 19:26:52 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D479421F9FB5; Tue, 8 Oct 2013 19:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY18vgZ5mrWC; Tue, 8 Oct 2013 19:26:48 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A40FA11E810A; Tue, 8 Oct 2013 19:26:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 522BE482B74; Tue, 8 Oct 2013 19:26:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7FDFF482B71; Tue, 8 Oct 2013 19:26:38 -0700 (PDT) Message-ID: <5254BEE2.4020504@joelhalpern.com> Date: Tue, 08 Oct 2013 22:26:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" References: <20131008184514.32189.48777.idtracker@ietfa.amsl.com> In-Reply-To: <20131008184514.32189.48777.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131008184514.32189.48777.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 02:26:53 -0000 Please help the nomcom. Yours, Joel -------- Original Message -------- Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Date: Tue, 08 Oct 2013 11:45:14 -0700 From: NomCom Chair Reply-To: nomcom-chair-2013@ietf.org To: IETF Announcement List CC: ietf@ietf.org UPDATE: nominations are too sparse in several of the IESG areas: APP, OAM, RAI, and TSV. If you know one or more of those areas, exercise your social network and submit nominations. We'll be very grateful! Is there someone you work with at IETF who has leadership potential and a growing track record? Please read this Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. If you're nominated, even if you support the present incumbent, being reviewed by Nomcom is great IETF experience. The questionnaire offers a chance to think about IETF and about your area. Whether or not your candidacy progresses this time, you'll have gained some valuable insights, and you'll have contributed greatly. This process only works because many IETFers take part; please join in. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! From hartmans@mit.edu Fri Oct 11 07:48:44 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC11D21E81B2; Fri, 11 Oct 2013 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.577 X-Spam-Level: X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeVakfZamSwK; Fri, 11 Oct 2013 07:48:39 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D688A21F9B4B; Fri, 11 Oct 2013 07:48:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 23EAB204E1; Fri, 11 Oct 2013 10:47:09 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LtmncORN0QO; Fri, 11 Oct 2013 10:47:08 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 11 Oct 2013 10:47:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8731A82B26; Fri, 11 Oct 2013 10:48:34 -0400 (EDT) From: Sam Hartman To: Ben Campbell References: <5224A352.6050007@cisco.com> <94891A49-8E45-44AF-B971-8A21DEFFB464@nostrum.com> Date: Fri, 11 Oct 2013 10:48:34 -0400 In-Reply-To: <94891A49-8E45-44AF-B971-8A21DEFFB464@nostrum.com> (Ben Campbell's message of "Tue, 24 Sep 2013 17:46:40 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , ietf@ietf.org, karp@ietf.org Subject: Re: [karp] Gen-ART LC Review of draft-ietf-karp-ops-model-07 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 14:48:45 -0000 >>>>> "Ben" == Ben Campbell writes: Ben> Hi, thanks for the response. Comments inline. I've removed Ben> sections that do not appear to need further comment. Ben> On Sep 17, 2013, at 1:29 PM, Sam Hartman wrote: >> genart> -- This abstract claims that this draft is a discussion of genart> issues. From that per spective, I don't think the use of genart> 2119 language is appropriate. There are some specific areas genart> (mentioned below) where 2119 language is used in imprecis genart> ways, and may do harm to the reader's understanding. There genart> are other uses that may be more reasonable. But I think the genart> draft would be better off dispensing with 2119 language genart> altogether. Ben> If you think 2119 language is appropriate, then it might be Ben> helpful to update the abstract and intro to make it more clear Ben> that the draft offers normative guidance, and make it clear Ben> when and to whom it applies. For example, section 3 says Ben> "Implementations of this model MUST..." It's not clear to me Ben> what "this model" means when the abstract and intro make it Ben> sound like this draft is early work towards eventually Ben> developing such a model. Having re-read the abstract and your comments I have a better understanding of what you mean. I've updated the abstract. I think this should help a lot. Sorry that I didn't get the version published last time; will upload today. >> genart> This seems like a place where descriptive language would be genart> better than 2119 lan guage. In particular, "and so on" genart> leaves things too open ended and imprecise. Al so, the use genart> of 2119 language in an example seems a bit off. >> >> So, the requirement is stated in the first clause using 2119 >> language: >> >> Operational Requirements: implementations of this model MUST >> support configuration of keys at the most general scope for the >> underlying protocol; >> >> The sentence goes on to apply that requirement to some common >> cases: protocols supporting per-peer keys MUST permit >> configuration of per-peer keys, protocols supporting >> per-interface keys MUST support configuration of per-interface >> keys, and so on. >> >> You might prefer different style rules; you might prefer that the >> restatements of the general requirement to specific situations >> not use 2119 language. I think the right approach for that is to >> try and build community consensus on those style rules and not to >> apply those rules until such a consensus is achieved. I do agree >> that care should be used when using 2119 in a restatement, but in >> this instance believe it is OK. >> >> I've removed the 2119 language from the example, although I think >> it was harmless. Ben> Ok. Ben> My concern was that it is open ended. The words "and so on" Ben> tells me that there may be more normative requirements that the Ben> reader is left to infer. That could make it hard to know if an Ben> implementation fully complies. Ah, how about replacing "and so on," with "and so on for any additional scopes?" My hope is to make it clear that the additional requiresments are related to any configuration scopes the protocol has. genart> -- section 4, 2nd to last paragraph: >> genart> Seems like other disadvantages are worth mentioning. For genart> example, the potential impact of a compromised CA. >> >> I spent a few minutes trying to come up with an argument whether >> CA compromise was better or worse than other systems compromise >> profile, particularly focusing on central management system >> compromise in the preshared key case. I think it's difficult to >> come up with an argument about whether that's actually a >> disadvantage of CAs in this case and I think getting consensus >> would be non-trivial. I also think that managing CA compromise >> can either be handled on the cost axis (secure offline CA) or the >> complexity axis (push out new CA certs and end-entity certs on >> compromise). So, I think the current text is accurate. If there >> are specific disadvantages that can easily be verified, I'm open >> to revisions. >> Ben> The previous paragraph listed an advantage that the fact that a Ben> server only has it's on key material limits the scope. The idea Ben> of a compromised CA having a potentially very large scope of Ben> damage is pretty well known, and it's a very real concern given Ben> the news of late. How that compares to the compromise of a Ben> central management system depends on whether the CA is a "third Ben> party" (or as in the web browser case, many third parties) vs Ben> the operator itself. (I guess the central management system Ben> could also be a third party, but that may be less typical.) Ah, I don't think a third-party CA would make sense for KARP. Which is why I find evaluating the tradeoff to be hard: I expect the CA and central management systems would control the same machines. genart> -- 4.1: >> genart> I understand why one might choose not to include a genart> real-world example here, but is there something that can be genart> referenced? >> >> Real wmorld example of what? Ben> Sorry, that was for section 4.1.2: "This hypothetical example Ben> is overly simplistic; real-world attacks exploiting key Ben> separation weaknesses tend to be complicated..." Agreed. For others following the conversation, I'd appreciate a reference. I'm finding good e-mail discussions, class-notes, etc, but nothing that I can cite in an RFC. I'd love to have a reference here. From internet-drafts@ietf.org Fri Oct 11 08:08:11 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFF311E8204; Fri, 11 Oct 2013 08:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNWemhWiIAXs; Fri, 11 Oct 2013 08:08:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2855211E818A; Fri, 11 Oct 2013 08:08:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131011150809.4882.64583.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 08:08:09 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-ops-model-09.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:08:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing Pro= tocols Working Group of the IETF. Title : Operations Model for Router Keying Author(s) : Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-ops-model-09.txt Pages : 25 Date : 2013-10-11 Abstract: The IETF is engaged in an effort to analyze security of routing protocol authentication according to design guidelines discussed in RFC 6518. Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-ops-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-ops-model-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-ops-model-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Oct 19 22:28:53 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870CC11E816F; Sat, 19 Oct 2013 22:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28ccVceljIEn; Sat, 19 Oct 2013 22:28:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F016B11E8173; Sat, 19 Oct 2013 22:28:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131020052849.22779.81829.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 22:28:49 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-isis-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 05:28:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing Pro= tocols Working Group of the IETF. Title : KARP IS-IS security analysis Author(s) : Uma Chunduri Albert Tian Wenhu Lu Filename : draft-ietf-karp-isis-analysis-01.txt Pages : 12 Date : 2013-10-19 Abstract: This document analyzes the threats applicable for Intermediate system to Intermediate system (IS-IS) routing protocol and security gaps according to the KARP Design Guide. This document also provides specific requirements to address the gaps with both manual and auto key management protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-isis-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-isis-analysis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-isis-analysis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From uma.chunduri@ericsson.com Sat Oct 19 23:09:30 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C035B11E815A for ; Sat, 19 Oct 2013 23:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf-Jj8-XgTnr for ; Sat, 19 Oct 2013 23:09:25 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6EF21F9FC6 for ; Sat, 19 Oct 2013 23:09:24 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-5e-526373934179 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B1.46.09414.39373625; Sun, 20 Oct 2013 08:09:23 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 02:09:23 -0400 From: Uma Chunduri To: "karp@ietf.org" Thread-Topic: New Version Notification for draft-chunduri-karp-kmp-router-fingerprints-04.txt Thread-Index: AQHOzVoTOQ6Bl6FXkEaO+iXe0vZ+CZn9Gsxw Date: Sun, 20 Oct 2013 06:09:22 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F081421@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.53.142.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyuXRPlO7k4uQgg9Un9C32flvD6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD9bdjEVNAtUnP30m6mB8SJPFyMnh4SAicTi81tZIWwxiQv3 1rN1MXJxCAkcZZR493MiC4SznFGi+etkJpAqNgE9iY9Tf7J3MXJwiAgoSxz4mgESFhaIk+j+ +ZURxBYRiJe4Nus3E4RtJHFl0l6wOIuAqsTbrcfAbF4BX4l11/6ygNiMQIu/n1oDVs8sIC5x 68l8JoiDBCSW7DnPDGGLSrx8/I8VZK2EgILEozkVEOV6EjemTmGDsLUlli18zQwxXlDi5Mwn LBMYhWchmToLScssJC2zkLQsYGRZxchRWpxalptuZLCJERjGxyTYdHcw7nlpeYhRmoNFSZz3 y1vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M/XZ55w191G5E/VWOupAuzSp7coV0wbPn earC/KIPdnDlhvyZ825V50mFJ8f+yQZ/nKnfsPBS9uoDXgIPUuVZeKeF3BabN0vvf0rHbd/d yX/3K9dkF5aLlIXLpT/hmr1g7pneQ0ImC6dximx+uXTBx2UyF+P471dOrBSZFHfIUN3MJ+is uWmoEktxRqKhFnNRcSIAyIetEDECAAA= Subject: [karp] FW: New Version Notification for draft-chunduri-karp-kmp-router-fingerprints-04.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 06:09:30 -0000 =20 No major changes in the content. Comments always welcome. --=20 Uma C.=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Saturday, October 19, 2013 11:03 PM To: Ari Ker=E4nen; Uma Chunduri; Albert Tian; Tero Kivinen Subject: New Version Notification for draft-chunduri-karp-kmp-router-finger= prints-04.txt A new version of I-D, draft-chunduri-karp-kmp-router-fingerprints-04.txt has been successfully submitted by Uma Chunduri and posted to the IETF repo= sitory. Filename: draft-chunduri-karp-kmp-router-fingerprints Revision: 04 Title: KARP KMP: Simplified Peer Authentication Creation date: 2013-10-20 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-chunduri-karp-km= p-router-fingerprints-04.txt Status: http://datatracker.ietf.org/doc/draft-chunduri-karp-kmp-ro= uter-fingerprints Htmlized: http://tools.ietf.org/html/draft-chunduri-karp-kmp-router-= fingerprints-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-chunduri-karp-kmp= -router-fingerprints-04 Abstract: This document describes the usage of Router Fingerprint Authentication (RFA) with public keys as a potential peer authentication method with KARP pair wise and group Key Management Protocols (KMPs). The advantage of RFA is, it neither requires out- of-band, mutually agreeable symmetric keys nor a full PKI based system (trust anchor or CA certificates) for mutual authentication of peers with KARP KMP deployments. Usage of Router Fingerprints give a significant operational improvement from symmetric key based systems and yet provide a secure authentication technique. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From jmh@joelhalpern.com Sun Oct 20 02:50:40 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C061A11E8396 for ; Sun, 20 Oct 2013 02:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE6YLUBb9Oil for ; Sun, 20 Oct 2013 02:50:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id CAE0511E8392 for ; Sun, 20 Oct 2013 02:50:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AF2701C9F95 for ; Sun, 20 Oct 2013 02:50:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 30EF11C0811 for ; Sun, 20 Oct 2013 02:50:31 -0700 (PDT) Message-ID: <5263A766.3000704@joelhalpern.com> Date: Sun, 20 Oct 2013 05:50:30 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Agenda items X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 09:50:41 -0000 We have a 90 minute KARP slot, from 1420 - 1550 on Tuesday. Please send any agenda item requests to Brian and me. Thank you, Joel From internet-drafts@ietf.org Mon Oct 21 15:52:37 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3ACD11E87CB; Mon, 21 Oct 2013 15:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCMk1oKFa2dX; Mon, 21 Oct 2013 15:52:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5791B11E8798; Mon, 21 Oct 2013 15:52:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021225237.32508.11558.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:52:37 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-crypto-key-table-09.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:52:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing Pro= tocols Working Group of the IETF. Title : Database of Long-Lived Symmetric Cryptographic Keys Author(s) : Russell Housley Tim Polk Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-crypto-key-table-09.txt Pages : 13 Date : 2013-10-21 Abstract: This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database. In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-crypto-key-table-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-crypto-key-table-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@painless-security.com Mon Oct 21 15:58:28 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6E511E87B0; Mon, 21 Oct 2013 15:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LPSTE+sVZoh; Mon, 21 Oct 2013 15:58:22 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6E94E11E8297; Mon, 21 Oct 2013 15:58:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 2A0F420470; Mon, 21 Oct 2013 18:56:26 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIEnI24kbcef; Mon, 21 Oct 2013 18:56:25 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 21 Oct 2013 18:56:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 15B6F82A4F; Mon, 21 Oct 2013 18:58:16 -0400 (EDT) From: Sam Hartman To: karp@ietf.org,iesg@ietf.org Date: Mon, 21 Oct 2013 18:58:16 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 21 Oct 2013 16:18:35 -0700 Subject: [karp] Update to draft-ietf-karp-crypto-key-table-09 under IESG review X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:58:28 -0000 I believe that Jari and Stephen can clear based on this draft. Adrian, this does not completely address your issues, as I didn't have time to update section 8.2. Review the next one not this one. Pete, I sent you mail months ago describing why I don't think that this is the right place to specify normalization etc. I'd like to better understand what I'm missing and why my model is incorrect. WG: Russ proposed that we use US-ASCII for our strings; that would address Pete's concern. I didn't read Russ's message until a few minutes ago (I was behind on mail) and I'd like to get a bit of discussion before making that change to make sure it's correct. WG: Note that this document includes a significant change to the scope--reducing it to routing protocols rather than security protocols. Please review this draft extra carefully. --Sam