From wesley.george@twcable.com Wed Apr 3 08:21:50 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 58C2721F8F35 for ; Wed, 3 Apr 2013 08:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 oe3epJ2pu0mu for ; Wed, 3 Apr 2013 08:21:49 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7A71521F8F41 for ; Wed, 3 Apr 2013 08:21:47 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,402,1363147200"; d="scan'208";a="51302005" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Apr 2013 11:21:17 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 3 Apr 2013 11:21:36 -0400 From: "George, Wes" To: "draft-ietf-karp-ops-model@tools.ietf.org" Date: Wed, 3 Apr 2013 11:21:35 -0400 Thread-Topic: [OPSEC] FW: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational Thread-Index: AQHOLxXw3vWrcjE1GEWl9qEmYdf7sZjCpHeQgAHiHVA= Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923042D13FDBA@PRVPEXVS15.corp.twcable.com> References: <67832B1175062E48926BF3CB27C49B240C8C7837@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240C8C7837@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 03 Apr 2013 08:27:38 -0700 Cc: "karp@ietf.org" Subject: Re: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational 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, 03 Apr 2013 15:21:50 -0000 I've reviewed this draft before at Sam's request, so I don't have a lot of = comments, but here are a few items I see in the most recent version in WGLC= . 3.2 key expiration -- Might be useful to have a pointer to 6.2 where handli= ng expiration faults is discussed in more detail. Also, would it be appropr= iate to discuss a config knob to more finely control expiration handling? I= 'm thinking of something that would allow a fail-open or fail-safe conditio= n, where expiration generates a fairly insistent warning but instead of imm= ediately tearing down that session, the implementation will maintain the se= ssion as long as it stays up, but if it goes down for some other reason (lo= st connectivity, etc.) it will not be permitted to re-establish until the e= xpired key is addressed. I'm sure there are some security risks to this, bu= t it might be a useful tradeoff for folks still getting the hang of managin= g key expiration. 5. Grouping peers - need to be able to ungroup a peer or peers without impa= cting routing - one of the problems with things like BGP Peer groups using = a common MD5 password today is that if you need to change the password, you= affect the entire peer group at once. The ability to override a group conf= ig with a peer-specific config as an extension of key rollover provides a l= ot of flexibility, such that it may be useful to make that an explicit requ= irement. This is discussed some in Section 7, but may need some companion t= ext here. 6.1 - not sure I'd assume that proper procedures are in place to be followe= d. The overlap between "Router people" and "security people" is often limit= ed, so I'm of the mind that some amount of specifics in terms of rules of t= humb are useful, or at least discussing what if anything might be different= in handling this provisioning step. see also draft-ietf-sidr-rtr-keying's discussion of provisioning a router. = Discussion on some of that in my review of that document. Thread here: http= ://www.ietf.org/mail-archive/web/sidr/current/msg05659.html Thanks, Wes George > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf > Of Gunter Van de Velde (gvandeve) > Sent: Tuesday, April 02, 2013 5:11 AM > To: opsec@ietf.org > Cc: Joel Halpern > Subject: [OPSEC] FW: [karp] WG LC: draft-ietf-karp-ops-model-05 to > Informational > > Dear OPSEC WG, > > Please take some time to comment upon draft-ietf-karp-ops-model-05. > > Make take your comments direct to the authors and copy the KARP WG. > > The KARP working group is designing improvements to the cryptographic > authentication of IETF routing protocols. These improvements include > improvements to how integrity functions are handled within each protocol > as well as designing an automated key management solution. > > Kind Regards, > G/ (OPSEC Co-chair) > > > From: Brian Weis > > Subject: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational > > Date: March 26, 2013 5:00:19 PM PDT > > To: "karp@ietf.org" > > > > This begins a two week WG last call to determine if folks will support > the chairs to submit > > > > to our AD for publication as an Informational RFC. > > > > Please send comments of support, or raising issues or concerns, to the > WG email list by 5pm PDT on 9-April-2013. > > > > Thank you, > > Joel M. Halpern > > and Brian Weis > > co-chairs > > _______________________________________________ > > karp mailing list > > karp@ietf.org > > https://www.ietf.org/mailman/listinfo/karp > > -- > Brian Weis > Security Engineering, SRG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From hartmans@mit.edu Thu Apr 4 15:08:16 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 5F3B121F8526 for ; Thu, 4 Apr 2013 15:08:16 -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 1BLhO+73Bkxb for ; Thu, 4 Apr 2013 15:08:15 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 92EF421F93C2 for ; Thu, 4 Apr 2013 15:08:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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 id A35A820218; Thu, 4 Apr 2013 18:06:58 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A72BE4497; Thu, 4 Apr 2013 18:08:12 -0400 (EDT) From: Sam Hartman To: "George\, Wes" References: <67832B1175062E48926BF3CB27C49B240C8C7837@xmb-aln-x12.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD5923042D13FDBA@PRVPEXVS15.corp.twcable.com> Date: Thu, 04 Apr 2013 18:08:12 -0400 In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923042D13FDBA@PRVPEXVS15.corp.twcable.com> (Wes George's message of "Wed, 3 Apr 2013 11:21:35 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "draft-ietf-karp-ops-model@tools.ietf.org" , "karp@ietf.org" Subject: Re: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational 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: Thu, 04 Apr 2013 22:08:16 -0000 Hi. With regard to your proposed key expiration and peer ungrouping text, I'd like to offer my support for the ideas but ask for additional support from the WG. Also, any opinions on what strength language we want there? MAY/SHOULD/MUST/MUST (BUT We KNOW YOU WON't)? I'm tending toward SHOULD personally. With regard to 6.1. People are doing something with administrative passwords. It may be good or bad, but their security already depends on it. Does opsec have some advice in this area we can reference? From internet-drafts@ietf.org Mon Apr 8 10:21:09 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 DEE1121F9756; Mon, 8 Apr 2013 10:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, 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 icOukb0JmUX2; Mon, 8 Apr 2013 10:21:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D767821F9750; Mon, 8 Apr 2013 10:21:06 -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.43.p3 Message-ID: <20130408172106.22970.65690.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 10:21:06 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-07.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: Mon, 08 Apr 2013 17:21:09 -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 : Analysis of BGP, LDP, PCEP and MSDP Issues According to = KARP Design Guide Author(s) : Mahesh Jethanandani Keyur Patel Lianshu Zheng Filename : draft-ietf-karp-routing-tcp-analysis-07.txt Pages : 17 Date : 2013-04-08 Abstract: This document analyzes TCP based routing protocols, Border Gateway Protocol (BGP), Label Distribution Protocol (LDP), Path Computation Element Communication Protocol (PCEP), and Multicast Source Distribution Protocol (MSDP) according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines (RFC6518). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-routing-tcp-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-routing-tcp-analysis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-routing-tcp-analysis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Tue Apr 9 07:15:12 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 736B421F913E; Tue, 9 Apr 2013 07:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, 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 ll6BW80bXw1g; Tue, 9 Apr 2013 07:15:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8456021F856E; Tue, 9 Apr 2013 07:15:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130409141511.4475.26541.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 07:15:11 -0700 Cc: karp mailing list , karp chair , RFC Editor Subject: [karp] Document Action: 'Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide' to Informational RFC (draft-ietf-karp-routing-tcp-analysis-07.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: Tue, 09 Apr 2013 14:15:12 -0000 The IESG has approved the following document: - 'Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide' (draft-ietf-karp-routing-tcp-analysis-07.txt) as Informational RFC This document is the product of the Keying and Authentication for Routing Protocols Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-karp-routing-tcp-analysis/ Technical Summary This document analyzes TCP based routing protocols, Border Gateway Protocol (BGP) [RFC4271], Label Distribution Protocol (LDP) [RFC5036], Path Computation Element Protocol (PCEP) [RFC5440], and Multicast Source Distribution Protocol (MSDP) [RFC3618] according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines [RFC6518]. Working Group Summary The working group was happy with this document. Joe Touch expressed concerns about the descriptions of TCP-MD5 and TCP-AO. All the specific concerns he raised have been addressed, but his comments suggest that he may have additional unspecified concerns. Document Quality This document has been reviewed by the Working Group and by the chairs. It does a good job laying out both the common issues across the protocols it analyses, and the protocol specific issues. The level of detail is appropriate to the working group goals as laid out in the charter and the guidelines document. Personnel Joel Halpern is the document shepherd. Stewart Bryant is the responsible Area Director. RFC Editor Note The rather terse and "non-standard" IANA section should be interpreted as "This document makes no IANA requests, and the RFC Editor may consider deleting this section on publication of this document as a RFC." Please move reference RFC6863 to the normative section. From iesg-secretary@ietf.org Tue Apr 9 07:15:12 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 EC59C21F913E for ; Tue, 9 Apr 2013 07:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, 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 oSEeCx8j8gPi; Tue, 9 Apr 2013 07:15:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAB321F8E63; Tue, 9 Apr 2013 07:15:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-karp-routing-tcp-analysis X-IETF-Draft-revision: 07 Message-ID: <20130409141511.4475.23650.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 07:15:11 -0700 Cc: karp mailing list , karp chair , RFC Editor Subject: [karp] Document Action: 'Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide' to Informational RFC (draft-ietf-karp-routing-tcp-analysis-07.txt) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org 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: Tue, 09 Apr 2013 14:15:13 -0000 The IESG has approved the following document: - 'Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide' (draft-ietf-karp-routing-tcp-analysis-07.txt) as Informational RFC This document is the product of the Keying and Authentication for Routing Protocols Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-karp-routing-tcp-analysis/ Technical Summary This document analyzes TCP based routing protocols, Border Gateway Protocol (BGP) [RFC4271], Label Distribution Protocol (LDP) [RFC5036], Path Computation Element Protocol (PCEP) [RFC5440], and Multicast Source Distribution Protocol (MSDP) [RFC3618] according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines [RFC6518]. Working Group Summary The working group was happy with this document. Joe Touch expressed concerns about the descriptions of TCP-MD5 and TCP-AO. All the specific concerns he raised have been addressed, but his comments suggest that he may have additional unspecified concerns. Document Quality This document has been reviewed by the Working Group and by the chairs. It does a good job laying out both the common issues across the protocols it analyses, and the protocol specific issues. The level of detail is appropriate to the working group goals as laid out in the charter and the guidelines document. Personnel Joel Halpern is the document shepherd. Stewart Bryant is the responsible Area Director. RFC Editor Note The rather terse and "non-standard" IANA section should be interpreted as "This document makes no IANA requests, and the RFC Editor may consider deleting this section on publication of this document as a RFC." Please move reference RFC6863 to the normative section. From hartmans@mit.edu Wed Apr 10 05:44:26 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 737DC21F9610 for ; Wed, 10 Apr 2013 05:44:26 -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 tYwECNobDkCl for ; Wed, 10 Apr 2013 05:44: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 01CDA21F9615 for ; Wed, 10 Apr 2013 05:44:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6FCD9205CC; Wed, 10 Apr 2013 08:42:52 -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 PU8rJcDLA8C8; Wed, 10 Apr 2013 08:42:52 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.200]) (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; Wed, 10 Apr 2013 08:42:52 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 60F284499; Wed, 10 Apr 2013 08:44:17 -0400 (EDT) From: Sam Hartman To: Brian Weis References: Date: Wed, 10 Apr 2013 08:44:17 -0400 In-Reply-To: (Brian Weis's message of "Tue, 26 Mar 2013 17:00:19 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "karp@ietf.org" Subject: Re: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational 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, 10 Apr 2013 12:44:27 -0000 Hi. I didn't see any last call comments besides Wes's comments. I'd also like to get some support for Wes's comments before folding them in. As I've said I personally support but would prefer to see if we can shake up more than one person saying "yes" at this stage. chairs, would it make sense for me to try and prepare a draft next week that hopefully can be sent on? From bew@cisco.com Wed Apr 10 10:10: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 3727A21F8E7B for ; Wed, 10 Apr 2013 10:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 i-RCebiYlVUd for ; Wed, 10 Apr 2013 10:10:43 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 64A6C21F8ECC for ; Wed, 10 Apr 2013 10:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1177; q=dns/txt; s=iport; t=1365613843; x=1366823443; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=GdrJxoWHbifsWFjm3NlEVUXncb4GctoNSzAgprKx2gU=; b=PF2zcUuAA7ehpl4bxvTO7ZD/9SQVqCZTp83Hn/I2MqhkuLyrqohFMAPK zBCZsEg1NI8oObfKR2/WxIYdoVnOZ2KEljvVqo6D9J4sm7iP5Yj5ZRgXh MCNPxPLMsXUEJtZcwCLgz/ctl5eYo5RbavSZMNv7H5hP42q+rdaHIVMJB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANmbZVGrRDoI/2dsb2JhbABQDoJ4wW6BDxZ0gh8BAQEDATo6BQULC0ZXBhOIDgW/PI5jMweCYGEDiQKKM4NLkQ6CTF8c X-IronPort-AV: E=Sophos;i="4.87,449,1363132800"; d="scan'208";a="78296092" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 10 Apr 2013 17:10:43 +0000 Received: from stealth-10-32-244-210.cisco.com (stealth-10-32-244-210.cisco.com [10.32.244.210]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3AHAY4N016189; Wed, 10 Apr 2013 17:10:42 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Weis In-Reply-To: Date: Wed, 10 Apr 2013 10:08:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <064CEDAF-F56A-44FD-9D1D-D7D47FCCC6A3@cisco.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1499) Cc: "karp@ietf.org" Subject: Re: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational 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, 10 Apr 2013 17:10:44 -0000 As chair, I'd like to see more declarations of support before = progressing the document. I'll extend the end of last call until 4/16 in = order to give others the chance to comment. Sam, why don't you hold off = with a new draft until then. Folks, the KARP work will be of little value if the operators can't = deploy it. This document provides needed advice to operators on best = practices for handling credentials and keys. Advice on use of the KARP = key table specification is a significant part of the document. We do = need to show consensus that it is the right advice. Please read and = comment, or at least provide an indication of approval or disapproval. Thanks, Brian On Apr 10, 2013, at 5:44 AM, Sam Hartman wrote: > Hi. I didn't see any last call comments besides Wes's comments. I'd > also like to get some support for Wes's comments before folding them = in. > As I've said I personally support but would prefer to see if we can > shake up more than one person saying "yes" at this stage. >=20 > chairs, would it make sense for me to try and prepare a draft next = week > that hopefully can be sent on? From william.atwood@concordia.ca Wed Apr 10 13:04: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 C29B621F936E for ; Wed, 10 Apr 2013 13:04:52 -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 agMMFs1cN9GV for ; Wed, 10 Apr 2013 13:04:52 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id E0FFA21F936D for ; Wed, 10 Apr 2013 13:04:51 -0700 (PDT) Received: from [127.0.0.1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id r3AK4n0J014773; Wed, 10 Apr 2013 16:04:49 -0400 Message-ID: <5165C5E7.4060306@concordia.ca> Date: Wed, 10 Apr 2013 16:04:55 -0400 From: William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sam Hartman , KARP Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2013/04/10 16:04:50 EDT Subject: Re: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational 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, 10 Apr 2013 20:04:52 -0000 I support draft-ietf-karp-ops-model-05 as Informational. I assume that the corrections that I suggested (off-line) to Sam and Dacheng will be incorporated into a final version. Wes's issue of key expiration makes sense to me, so I support it. Wes' issue of grouping/ungrouping peers makes sense to me, so I support it. We have touched on one aspect of this issue (the scope of keys) in draft-atwood-karp-akam-rp. I have read the comment on Section 6.1 and the email that is cited. I agree that, for the kind of document that ops-model is intended to be (i.e., targeted at a member of a routing working group who knows little about security), no assumption should be made about "proper security procedures being in place". It is the fact that we know that they are _not_ in place that is driving the entire KARP effort, after all. I therefore support inclusion of more text here. Bill On 10/04/2013 8:44 AM, Sam Hartman wrote: > Hi. I didn't see any last call comments besides Wes's comments. I'd > also like to get some support for Wes's comments before folding them in. > As I've said I personally support but would prefer to see if we can > shake up more than one person saying "yes" at this stage. > > chairs, would it make sense for me to try and prepare a draft next week > that hopefully can be sent on? > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From melinda.shore@gmail.com Wed Apr 10 15:22: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 83C1921F890F for ; Wed, 10 Apr 2013 15:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=-1.492, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, RDNS_DYNAMIC=0.1] 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 ZJ2NnI2WEIKp for ; Wed, 10 Apr 2013 15:22:53 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0176F21F89A5 for ; Wed, 10 Apr 2013 15:22:52 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id a22so436087qcs.12 for ; Wed, 10 Apr 2013 15:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ipuVCAJaD791gxV6RUOiArpsizNV4Fyb/h3LnEgV6s4=; b=s6oz6kNfkfwGbyPiCs2vSbiWSxSq6uVZzsWbPmNdKEHNel+tuPAcsYr1C7smPRHSsP JGj+p3I0lbNE3oA875NkBIDLbiUtTtO375oM2awyQPMmuIzWkpMOQjGlf0hDHpRrPyyZ ctfLjEJJToRlGhFKPcrHL8ViYeP0bNcoCInRSnNqIvkrBfEcQO5JGXjT62YA0RKymzUz TIkM98yPWVNXJWGL5idjzDULTjjl6DszuHwyRSj4tQ8kJjv7+PoQ1kda9ohbjr7g8rYx Gk+xLTZm8QnZ5TmyYBC6JzqqJEIYnFDVTKZeTMKn0hR67u9Cq0s8mOqdXswPv841qI+P /39w== X-Received: by 10.229.114.215 with SMTP id f23mr1523532qcq.111.1365632565909; Wed, 10 Apr 2013 15:22:45 -0700 (PDT) Received: from [107.16.91.90] (dhcp107-16-91-90.hil-gaighhf.dca.wayport.net. [107.16.91.90]) by mx.google.com with ESMTPS id k8sm2759277qej.2.2013.04.10.15.22.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 15:22:45 -0700 (PDT) Message-ID: <5165E633.3080603@gmail.com> Date: Wed, 10 Apr 2013 14:22:43 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: karp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational 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, 10 Apr 2013 22:22:53 -0000 On 4/10/2013 4:44 AM, Sam Hartman wrote: > Hi. I didn't see any last call comments besides Wes's comments. I'd > also like to get some support for Wes's comments before folding them in. > As I've said I personally support but would prefer to see if we can > shake up more than one person saying "yes" at this stage. Here's a "yes." I'm actually pretty good with section 6.1 - in my experience the people managing and configuring routers do have an appreciation for the sensitivity of router management keys/passwords (this is not a particularly subtle issue or one that requires specialist knowledge). I'm not really in love with section 3.1 (routers validating cryptographic parameters) but I can live with it. I think the document is in good shape and ready to move forward. Melinda From hartmans@mit.edu Wed Apr 10 16:42:26 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 BCBFF21F89FB for ; Wed, 10 Apr 2013 16:42:26 -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 VK+7Jquvlisx for ; Wed, 10 Apr 2013 16:42:26 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 371FA21F8555 for ; Wed, 10 Apr 2013 16:42:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 07970205A5; Wed, 10 Apr 2013 19:40:57 -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 cOsgIRmeo5OW; Wed, 10 Apr 2013 19:40:56 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.200]) (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; Wed, 10 Apr 2013 19:40:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 56ABD4499; Wed, 10 Apr 2013 19:42:24 -0400 (EDT) From: Sam Hartman To: William Atwood References: <5165C5E7.4060306@concordia.ca> Date: Wed, 10 Apr 2013 19:42:24 -0400 In-Reply-To: <5165C5E7.4060306@concordia.ca> (William Atwood's message of "Wed, 10 Apr 2013 16:04:55 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , KARP Working Group Subject: Re: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational 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, 10 Apr 2013 23:42:26 -0000 >>>>> "William" == William Atwood writes: William> I support draft-ietf-karp-ops-model-05 as Informational. I William> assume that the corrections that I suggested (off-line) to William> Sam and Dacheng will be incorporated into a final version. Yes, your comments and Wes's comments are what I have queued. From iesg-secretary@ietf.org Mon Apr 15 11:06:51 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 9A67521F9609; Mon, 15 Apr 2013 11:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.797 X-Spam-Level: X-Spam-Status: No, score=-101.797 tagged_above=-999 required=5 tests=[AWL=0.803, 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 AmaWmAkk3Ryn; Mon, 15 Apr 2013 11:06:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0667821F95F5; Mon, 15 Apr 2013 11:06:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130415180650.23507.74022.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 11:06:50 -0700 Cc: karp@ietf.org Subject: [karp] Last Call: (Database of Long-Lived Symmetric Cryptographic Keys) to Proposed Standard X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 15 Apr 2013 18:06:51 -0000 The IESG has received a request from the Keying and Authentication for Routing Protocols WG (karp) to consider the following document: - 'Database of Long-Lived Symmetric Cryptographic Keys' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different security protocols. 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 security protocols that wish to use the database. In many typical scenarios, the security 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Apr 15 11:06:51 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 EE4F921F95F9 for ; Mon, 15 Apr 2013 11:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.797 X-Spam-Level: X-Spam-Status: No, score=-101.797 tagged_above=-999 required=5 tests=[AWL=0.803, 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 U5z9HiRKyH3o; Mon, 15 Apr 2013 11:06:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2721621F95FC; Mon, 15 Apr 2013 11:06:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-karp-crypto-key-table X-IETF-Draft-revision: 07 Message-ID: <20130415180651.23507.9180.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 11:06:51 -0700 Cc: karp@ietf.org Subject: [karp] Last Call: (Database of Long-Lived Symmetric Cryptographic Keys) to Proposed Standard X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org 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, 15 Apr 2013 18:06:52 -0000 The IESG has received a request from the Keying and Authentication for Routing Protocols WG (karp) to consider the following document: - 'Database of Long-Lived Symmetric Cryptographic Keys' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different security protocols. 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 security protocols that wish to use the database. In many typical scenarios, the security 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/ballot/ No IPR declarations have been submitted directly on this I-D. From uma.chunduri@ericsson.com Mon Apr 15 14:11:21 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 A9AF321F9122 for ; Mon, 15 Apr 2013 14:11:21 -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 jtUtlLZnWrij for ; Mon, 15 Apr 2013 14:11:21 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 011B521F877B for ; Mon, 15 Apr 2013 14:11:20 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-1d-516c6cf814bb Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 48.24.02411.8FC6C615; Mon, 15 Apr 2013 23:11:20 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 17:11:19 -0400 From: Uma Chunduri To: "draft-ietf-karp-ops-model@tools.ietf.org" Thread-Topic: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational Thread-Index: AQHOOh3GVOMbw+XA10WKLAVvTHY5Rg== Date: Mon, 15 Apr 2013 21:11:19 +0000 Message-ID: <1B502206DFA0C544B7A604691520086305F61947@eusaamb105.ericsson.se> References: <67832B1175062E48926BF3CB27C49B240C8C7837@xmb-aln-x12.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD5923042D13FDBA@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923042D13FDBA@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXSPt+6PnJxAg30bpC0O3L/HbLH32xpG ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj4u6nzAUtIhU/94k2MJ7n72Lk5JAQMJFY ee4XK4QtJnHh3no2EFtI4CijxNZe8y5GLiB7OaPE3q5rYAk2AT2Jj1N/sncxcnCICERLnJsb DRJmFlCW6G7pYAGxhQXCJC5//MMMYosIhEs0zT3HCFGuJ3HrajhImEVAVeLjnctg5bwCvhI7 DpxkgVj1l1Fi5+ImsF5OgVCJ64vvMYHYjEC3fT+1hglil7jErSfzmSBuFpBYsuc8M4QtKvHy 8T+oX5Qlvs95xAJRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJG llWMHKXFqWW56UaGmxiBEXJMgs1xB+OCT5aHGKU5WJTEeUNdLwQICaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYGRbILJQLvTchpSipK3yZUfzBHTv/zzFnRk/Z6Hup0V5v/r1p3x/ZlkkYb12 ptGWG2fPf2zU2PH+rT5DrfW25/3s6+3rFC62CFg9r2yxYMl/++goe7d74QSOpZMWHG53MNhy dNHTvD1+Hbu697E0bFx8gH1ppsC9jXY6Cv0Oi6qMxI/s/XEyJESJpTgj0VCLuag4EQAUrfgs XgIAAA== Cc: "karp@ietf.org" Subject: Re: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational 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, 15 Apr 2013 21:11:21 -0000 Dear Authors, I happened to read this document again after a long time and it's changed = quite a bit and in the current form it's certainly relevant for Routing op= erations folk.=20 You touched upon scope of keys to, configuration using key tables, various = key types being used (KARP scope) and handling faults. All are very useful. First I would share my opinion on the suggestions asked for: 3.2 key expiration -- (my comments for new suggested text) Though it's fair from operations perspective, obviously not good for securi= ty perspective. Probably situation with key roll over for RP's could improv= e with Key management protocols usage (with in built soft key rollover time= s etc..). In that spirit you can at best use a "MAY" 5. Grouping peers -=20 Yes, useful and it's reasonable. 6.1 -=20 Very important aspect and not aware of any opsec document which touches thi= s aspect. Other not so significant comments I have: ----------------------------------------- 1. Section 1 - Page 3 "This document also gives recommendations for how management and operations.." s/operations/operational 2. Section 3.2 - Currently text mainly focus on manual deployments. - Section 3.3 talks different aspect with KMPs not the rollover - Hence, this section may need to consider both manual keys and keys b= eing populated by the KMP;=20 where KMP (peer2peer or group) ensures keys are properly replenishe= d before the old keys expiry. 3. Section 4 (last 3 paragraphs) - It's better if the scope of the keys talked about differentiates for= RPs and KMPs in separate sections. I am indicating this because, certificates and other form of authenti= cation methods are not directly applicable to RPs, with in KARP scope. 4. Section 4.2 and 4.3 - These are not directly applicable to RPs but critical for KMPs. If you can restructure section 4, it benefits immensely for the routi= ng developers and operator community. 5. Section 6.2 "Faults may interact with operational practice in at least two ways. First, security solutions may introduce faults. For example if certificates expire in a PKI, previous adjacencies may no longer form. Operational practice will require a way of repairing these errors. This may end up being very similar to repairing other faults that can partition a network." Need to indicate this as KMP related issue rather than RP issue as far a= s KARP is concerned. -- Uma C.= From david.black@emc.com Thu Apr 25 08:22:26 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 B5E5F21F93B1; Thu, 25 Apr 2013 08:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.847 X-Spam-Level: X-Spam-Status: No, score=-99.847 tagged_above=-999 required=5 tests=[AWL=2.752, 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 eybJpJaj9I7w; Thu, 25 Apr 2013 08:22:16 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3D46121F92C0; Thu, 25 Apr 2013 08:22:10 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3PFLt1U020302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 11:21:56 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 25 Apr 2013 11:21:42 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3PFLcj8012731; Thu, 25 Apr 2013 11:21:38 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Thu, 25 Apr 2013 11:21:37 -0400 From: "Black, David" To: Russ Housley , "tim.polk@nist.gov" , "hartmans@painless-security.com" , "zhangdacheng@huawei.com" , "gen-art@ietf.org" Date: Thu, 25 Apr 2013 11:21:36 -0400 Thread-Topic: Gen-ART review of draft-ietf-karp-crypto-key-table-07 Thread-Index: Ac5ByJPFxMQV0ntvRsGIbN7yaluElA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293F3BD27@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Thu, 25 Apr 2013 08:53:05 -0700 Cc: "Black, David" , "ietf@ietf.org" , "karp@ietf.org" Subject: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-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: Thu, 25 Apr 2013 15:22:26 -0000 Document: draft-ietf-karp-crypto-key-table-07 Reviewer: David L. Black Review Date: April 25, 2013 IETF LC End Date: April 29, 2013 Summary: This draft is on the right track, but has open issues described in the review. This draft describes a conceptual key database for use by protocols. It's definitely useful and valuable work, as key management is often an afterthought in protocol design, even when security functionality is actively worked on in the design process. The draft text is in good shape and reads cleanly, but the draft is short on precision in specifying a number of the fields for the database, and the IANA registries; most of the open issues are requests for the level of precision needed for interoperability and reuse of database implementation across different protocol implementations. Major issues:=20 (Section 2) [1] LocalKeyName and PeerKeyName are strings. What character set? If Unicode (e.g., UTF-8?), add text on Unicode considerations (e.g., normalization). Finding a Unicode expert will help in getting this done quickly. I have similar concerns for other strings, and in particular, IANA should be told what a "string" is for any registry field that contains one. [2] I'm not sure that I understand what a KDF really is from its high level description in this draft. At the least, I'm surprised that the importance of non-invertibility of a KDF is not mentioned - beyond that, a functional description of inputs and outputs would help, including a strong recommendation to inject unpredictable nonce material. This could be handled by referencing material on what a KDF is that exists elsewhere. (Section 4) [3] It's important that this section cover all the fields involved in the database lookups in Section 3 whose format may be protocol-specific (the Direction and various time fields aren't). Protocol should be covered by the IANA registry, peers and key names are covered here, but interface appears to be missing - item (9) covers presence vs. absence of interface information, but not its format. --- Lots of issues with the IANA Considerations (Section 8) (Section 8.1.1) [5] No field format information for the fields in a registry entry. IANA should be told what formats to expect/use. [6] "Protocol Specific Values" is not the same as "ProtocolSpecificInfo" in section 2; the same name should be used, but whitespace differences are ok. [7] Should some sort of formats for Peers and Interfaces be included in registering a Protocol? If not, the lookups in section 3 may be implementation-dependent (strings that work w/one implementation may not work w/other implementations of the same protocol). The specification reference may suffice based on the requirements in section 4 for what has to be in each referenced specification. (Sections 8.2 and 8.3) [8] No registry entry content descriptions. Need to supply information on what to register and the formats of the elements of a registry entry. [9] I suggest Expert Review for these registries, not just=20 First Come First Served, so that someone with a security "clue" can check that the proposed registrations are reasonable. Minor issues: [A] Overall - I would like to see a paragraph added on how this database conceptually relates to the IPsec Peer Authorization Database (PAD) - see RFC 4301, section 4.4.3. [B] (Section 2) Where is key size recorded? Is that an implicit attribute of Key? [C] (Section 3) Where does key selection occur? I would suggest that the database return all possible keys and let the protocol figure out what to use. This is particularly important for inbound traffic for obvious reason= s. Nits/editorial comments: I suggest dividing section 3 into - 3.1 Outgoing Traffic - 3.2 Incoming Traffic idnits 2.12.16 found a truly trivial nit - =3D=3D Line 76 has weird spacing: '...strains where...' Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From hartmans@painless-security.com Thu Apr 25 09:47:26 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 2144A21F9638; Thu, 25 Apr 2013 09:47:26 -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 7Cy5XcuK+CL6; Thu, 25 Apr 2013 09:47:25 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 46EA421F94B1; Thu, 25 Apr 2013 09:47:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8D2722021D; Thu, 25 Apr 2013 12:45: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 2RIwvD-7_Bfx; Thu, 25 Apr 2013 12:45:25 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.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; Thu, 25 Apr 2013 12:45:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8FB744499; Thu, 25 Apr 2013 12:47:22 -0400 (EDT) From: Sam Hartman To: "Black\, David" References: <8D3D17ACE214DC429325B2B98F3AE71293F3BD27@MX15A.corp.emc.com> Date: Thu, 25 Apr 2013 12:47:22 -0400 In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293F3BD27@MX15A.corp.emc.com> (David Black's message of "Thu, 25 Apr 2013 11:21:36 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ietf@ietf.org" , "tim.polk@nist.gov" , "gen-art@ietf.org" , "karp@ietf.org" Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-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: Thu, 25 Apr 2013 16:47:26 -0000 Here are some quick initial responses to your comments. Thanks much for the review and I'll follow up with more detail in a while. >>>>> "Black," == Black, David writes: Black,> Major issues: Black,> (Section 2) Black,> [1] LocalKeyName and PeerKeyName are strings. What Black,> character set? If Unicode (e.g., UTF-8?), add text on Black,> Unicode considerations (e.g., normalization). Finding a Black,> Unicode expert will help in getting this done quickly. I Black,> have similar concerns for other strings, and in particular, Black,> IANA should be told what a "string" is for any registry Black,> field that contains one. They are strings that can be compared using binary comparison. I agree we need to state that in the draft. Character set, to the extent it is specified will be specified by the individual protocol. In practice the protocol will say that it's an integer represented as an ASCII string. We needed to add the entire complexity of making these fields be strings not integers because of some non-IETF protocols that use key names. I'm reasonably confident I can sell Pete on the concept of a binary identifier for this field from an i18n standpoint. But issues, of length, format, etc are all specified by the protocol spec. Black,> [2] I'm not sure that I understand what a KDF really is from Black,> its high level description in this draft. At the least, I'm Black,> surprised that the importance of non-invertibility of a KDF Black,> is not mentioned - beyond that, a functional description of Black,> inputs and outputs would help, including a strong Black,> recommendation to inject unpredictable nonce material. This Black,> could be handled by referencing material on what a KDF is Black,> that exists elsewhere. I'm open to text either proposed on the IETF list from one of the other authors. Some protocols have a KDF input some do not. If they do, it will be drawn from a set of allowable valuable for that protocol. Black,> (Section 4) Black,> [3] It's important that this section cover all the fields Black,> involved in the database lookups in Section 3 whose format Black,> may be protocol-specific (the Direction and various time Black,> fields aren't). Protocol should be covered by the IANA Black,> registry, peers and key names are covered here, but Black,> interface appears to be missing - item (9) covers presence Black,> vs. absence of interface information, but not its format. The interface is implementation-specific not protocol specific. We mandate that you must be able to tie things to interface. However the format of an interface is quite specific to the routing platform in questino. I don't think there's a way that an IETF document can go into useful detail on that. SNMP and Netconf have models of how interfaces are represented. If we ever put together a Netconf schema for this database, we'd specify the interface there. Black,> --- Lots of issues with the IANA Considerations (Section 8) Black,> (Section 8.1.1) Black,> [5] No field format information for the fields in a registry Black,> entry. IANA should be told what formats to expect/use. Thanks, agreed. Black,> [6] "Protocol Specific Values" is not the same as Black,> "ProtocolSpecificInfo" in section 2; the same name should be Black,> used, but whitespace differences are ok. Good catch. Black,> [7] Should some sort of formats for Peers and Interfaces be Black,> included in registering a Protocol? If not, the lookups in Black,> section 3 may be implementation-dependent (strings that work Black,> w/one implementation may not work w/other implementations of Black,> the same protocol). The specification reference may suffice Black,> based on the requirements in section 4 for what has to be in Black,> each referenced specification. When you register a protocol you need to point to a specification that gives details on this sort of thing. Black,> (Sections 8.2 and 8.3) Black,> [8] No registry entry content descriptions. Need to supply Black,> information on what to register and the formats of the Black,> elements of a registry entry. Thanks. Black,> [9] I suggest Expert Review for these registries, not just Black,> First Come First Served, so that someone with a security Black,> "clue" can check that the proposed registrations are Black,> reasonable. As an individual, I support FCFS, because I think getting expert approval for some of the uses that have been proposed for these registries will be challenging. From david.black@emc.com Thu Apr 25 11:50:01 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 A70AE21F9647; Thu, 25 Apr 2013 11:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.24 X-Spam-Level: X-Spam-Status: No, score=-100.24 tagged_above=-999 required=5 tests=[AWL=2.359, 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 Wqiw+LVwUHSc; Thu, 25 Apr 2013 11:50:00 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 460C221F9644; Thu, 25 Apr 2013 11:49:59 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3PInX2v020434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 14:49:33 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 25 Apr 2013 14:49:21 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r3PInKnE019433; Thu, 25 Apr 2013 14:49:20 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Thu, 25 Apr 2013 14:49:19 -0400 From: "Black, David" To: Sam Hartman Date: Thu, 25 Apr 2013 14:49:17 -0400 Thread-Topic: Gen-ART review of draft-ietf-karp-crypto-key-table-07 Thread-Index: Ac5B1KJBGTDzkf65QPacxtWgnCr6KgADLoOg Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293F3BDB0@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71293F3BD27@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "ietf@ietf.org" , "tim.polk@nist.gov" , "gen-art@ietf.org" , "Black, David" , "karp@ietf.org" Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-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: Thu, 25 Apr 2013 18:50:01 -0000 Thanks for the quick response - most of your message looks reasonable to me= . I have a few additional comments. [1] Character set for key names, etc. > They are strings that can be compared using binary comparison. > I agree we need to state that in the draft. That's certainly a reasonable goal, and there are plenty of examples of protocols that do that. OTOH, when the character set is Unicode, generatin= g strings for which that binary comparison for equality works as expected has a number of subtleties when the strings are input by humans. Pete Resnick and yours truly are among the people familiar with the "dragons" that lurk here (and the precis WG is grappling with). > We needed to add the entire complexity of making these fields be strings > not integers because of some non-IETF protocols that use key names. >=20 > I'm reasonably confident I can sell Pete on the concept of a binary > identifier for this field from an i18n standpoint. I have no problem with the field being a binary identifier, but I think implementers should be put on notice that binary comparison of human input Unicode strings doesn't work as expected unless some things are done to make it work (this used to be known as string preparation). A warning to that effect, perhaps citing a reference for details on what can go awry, accompanied by making the protocol spec responsible for getting this right ought to suffice. [3] Protocol responsibility to specify interface format > We > mandate that you must be able to tie things to interface. However the > format of an interface is quite specific to the routing platform in > question. Ok, I suggest explaining that as part of a statement that a protocol cannot in general be expected to specify interface formats that apply across all implementations due to implementation diversity. [7] Additional format information in registry > Black,> [7] Should some sort of formats for Peers and Interfaces be > Black,> included in registering a Protocol? If not, the lookups in > Black,> section 3 may be implementation-dependent (strings that work > Black,> w/one implementation may not work w/other implementations of > Black,> the same protocol). The specification reference may suffice > Black,> based on the requirements in section 4 for what has to be in > Black,> each referenced specification. >=20 > When you register a protocol you need to point to a specification that > gives details on this sort of thing. That makes sense, and section 4's requirements on the specifications=20 cover this area, but I thought I'd ask. [9] Registry policy > As an individual, I support FCFS, because I think getting expert > approval for some of the uses that have been proposed for these > registries will be challenging. The two registries involved are for KDFs and cryptographic algorithm identi= fiers. This feels like something that the security area ought to weigh in on, as i= t looks like it includes the "vanity crypto" discussion tarpit ;-). At a min= imum, I would think that there ought to be some means of prohibiting registration of a crypto algorithm like ROT13 (http://en.wikipedia.org/wiki/ROT13). Thanks, --David > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Thursday, April 25, 2013 12:47 PM > To: Black, David > Cc: Russ Housley; tim.polk@nist.gov; zhangdacheng@huawei.com; gen- > art@ietf.org; karp@ietf.org; ietf@ietf.org; > Subject: Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07 >=20 > Here are some quick initial responses to your comments. >=20 > Thanks much for the review and I'll follow up with more detail in a > while. >=20 > >>>>> "Black," =3D=3D Black, David writes: >=20 >=20 > Black,> Major issues: >=20 > Black,> (Section 2) >=20 > Black,> [1] LocalKeyName and PeerKeyName are strings. What > Black,> character set? If Unicode (e.g., UTF-8?), add text on > Black,> Unicode considerations (e.g., normalization). Finding a > Black,> Unicode expert will help in getting this done quickly. I > Black,> have similar concerns for other strings, and in particular, > Black,> IANA should be told what a "string" is for any registry > Black,> field that contains one. >=20 > They are strings that can be compared using binary comparison. > I agree we need to state that in the draft. > Character set, to the extent it is specified will be specified by the > individual protocol. > In practice the protocol will say that it's an integer represented as > an ASCII string. >=20 > We needed to add the entire complexity of making these fields be strings > not integers because of some non-IETF protocols that use key names. >=20 > I'm reasonably confident I can sell Pete on the concept of a binary > identifier for this field from an i18n standpoint. >=20 > But issues, of length, format, etc are all specified by the protocol > spec. >=20 > Black,> [2] I'm not sure that I understand what a KDF really is from > Black,> its high level description in this draft. At the least, I'm > Black,> surprised that the importance of non-invertibility of a KDF > Black,> is not mentioned - beyond that, a functional description of > Black,> inputs and outputs would help, including a strong > Black,> recommendation to inject unpredictable nonce material. This > Black,> could be handled by referencing material on what a KDF is > Black,> that exists elsewhere. >=20 > I'm open to text either proposed on the IETF list from one of the other > authors. > Some protocols have a KDF input some do not. > If they do, it will be drawn from a set of allowable valuable for that > protocol. >=20 > Black,> (Section 4) >=20 > Black,> [3] It's important that this section cover all the fields > Black,> involved in the database lookups in Section 3 whose format > Black,> may be protocol-specific (the Direction and various time > Black,> fields aren't). Protocol should be covered by the IANA > Black,> registry, peers and key names are covered here, but > Black,> interface appears to be missing - item (9) covers presence > Black,> vs. absence of interface information, but not its format. >=20 > The interface is implementation-specific not protocol specific. We > mandate that you must be able to tie things to interface. However the > format of an interface is quite specific to the routing platform in > questino. I don't think there's a way that an IETF document can go into > useful detail on that. SNMP and Netconf have models of how interfaces > are represented. If we ever put together a Netconf schema for this > database, we'd specify the interface there. >=20 > Black,> --- Lots of issues with the IANA Considerations (Section 8) >=20 > Black,> (Section 8.1.1) >=20 > Black,> [5] No field format information for the fields in a registry > Black,> entry. IANA should be told what formats to expect/use. >=20 > Thanks, agreed. >=20 >=20 > Black,> [6] "Protocol Specific Values" is not the same as > Black,> "ProtocolSpecificInfo" in section 2; the same name should be > Black,> used, but whitespace differences are ok. > Good catch. >=20 > Black,> [7] Should some sort of formats for Peers and Interfaces be > Black,> included in registering a Protocol? If not, the lookups in > Black,> section 3 may be implementation-dependent (strings that work > Black,> w/one implementation may not work w/other implementations of > Black,> the same protocol). The specification reference may suffice > Black,> based on the requirements in section 4 for what has to be in > Black,> each referenced specification. >=20 > When you register a protocol you need to point to a specification that > gives details on this sort of thing. >=20 > Black,> (Sections 8.2 and 8.3) >=20 > Black,> [8] No registry entry content descriptions. Need to supply > Black,> information on what to register and the formats of the > Black,> elements of a registry entry. >=20 > Thanks. >=20 > Black,> [9] I suggest Expert Review for these registries, not just > Black,> First Come First Served, so that someone with a security > Black,> "clue" can check that the proposed registrations are > Black,> reasonable. >=20 > As an individual, I support FCFS, because I think getting expert > approval for some of the uses that have been proposed for these > registries will be challenging. >=20 >=20 From hartmans@mit.edu Thu Apr 25 12:04:18 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 5ABDA21F8D2E; Thu, 25 Apr 2013 12:04:18 -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 1pFVlPU-ahta; Thu, 25 Apr 2013 12:04:17 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id CA9E821F8BC0; Thu, 25 Apr 2013 12:04:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 90DEE2021D; Thu, 25 Apr 2013 15:02:19 -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 yitGTgSfVmK3; Thu, 25 Apr 2013 15:02:18 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.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; Thu, 25 Apr 2013 15:02:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B935E4499; Thu, 25 Apr 2013 15:04:15 -0400 (EDT) From: Sam Hartman To: "Black\, David" References: <8D3D17ACE214DC429325B2B98F3AE71293F3BD27@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293F3BDB0@MX15A.corp.emc.com> Date: Thu, 25 Apr 2013 15:04:15 -0400 In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293F3BDB0@MX15A.corp.emc.com> (David Black's message of "Thu, 25 Apr 2013 14:49:17 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ietf@ietf.org" , "tim.polk@nist.gov" , "gen-art@ietf.org" , Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-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: Thu, 25 Apr 2013 19:04:18 -0000 >>>>> "Black," == Black, David writes: I've been there too. I've had a number of recent discussinos with Pete about what the IESG is and is not happy with . I'll write something up and I'm sure he and the rest of the IESG will let us know if we got it wrong:-) From johnsonhammond1@hushmail.com Sat Apr 27 14:08:05 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 A863B21F9946 for ; Sat, 27 Apr 2013 14:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 hFkUJdFvpBcw for ; Sat, 27 Apr 2013 14:08:05 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3E821F9940 for ; Sat, 27 Apr 2013 14:08:05 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 40E6C30FC3 for ; Sat, 27 Apr 2013 17:45:27 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:45:27 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 03666E6736; Sat, 27 Apr 2013 17:45:26 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:45:26 -0400 To: karp@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174527.03666E6736@smtp.hushmail.com> Subject: [karp] Biggest Fake Conference in Computer Science 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: Sat, 27 Apr 2013 21:08:05 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From Ted.Lemon@nominum.com Mon Apr 29 07:37:45 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 742D221F9E4C; Mon, 29 Apr 2013 07:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 nH7-+zp8Gqi1; Mon, 29 Apr 2013 07:37:44 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 66C6521F9E4B; Mon, 29 Apr 2013 07:37:44 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUX6FuHVrwVi3MoijUi9NKPyAb/1Bzlfv@postini.com; Mon, 29 Apr 2013 07:37:44 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0DE851B813F; Mon, 29 Apr 2013 07:37:44 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 017B2190061; Mon, 29 Apr 2013 07:37:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 07:37:44 -0700 From: Ted Lemon To: "Black, David" Thread-Topic: Gen-ART review of draft-ietf-karp-crypto-key-table-07 Thread-Index: Ac5ByJPFxMQV0ntvRsGIbN7yaluElADGrB/i//p5/YCABgMJAA== Date: Mon, 29 Apr 2013 14:37:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751666F9@mbx-01.win.nominum.com> References: <8D3D17ACE214DC429325B2B98F3AE71293F3BD27@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293F3BDB0@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293F3BDB0@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "gen-art@ietf.org" , Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-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: Mon, 29 Apr 2013 14:37:45 -0000 On Apr 25, 2013, at 2:49 PM, "Black, David" wrote: > I have no problem with the field being a binary identifier, but I think > implementers should be put on notice that binary comparison of human inpu= t > Unicode strings doesn't work as expected unless some things are done to > make it work (this used to be known as string preparation). +1.