From william.atwood@concordia.ca Mon Dec 2 21:04:54 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5EB1AE033 for ; Mon, 2 Dec 2013 21:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJprRy_bsYRi for ; Mon, 2 Dec 2013 21:04:52 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4A51ADFA1 for ; Mon, 2 Dec 2013 21:04:51 -0800 (PST) Received: from [IPv6:::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 rB354mm6006589 for ; Tue, 3 Dec 2013 00:04:48 -0500 Message-ID: <529D667E.6040507@concordia.ca> Date: Tue, 03 Dec 2013 00:05:02 -0500 From: William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: KARP Working Group 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/12/03 00:04:48 EST Subject: [karp] Comments on draft-ietf-karp-crypto-key-table X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2013 05:04:54 -0000 In the spirit of the chairs' plea to read and comment on the WG documents, I have read the crypto-key-table document carefully. Herewith some comments, which hopefully will be useful to the authors, even this late in the cycle. I have also made a number of comments on formatting and grammatical issues directly to the authors. Note that I will use the abbreviation CKT to stand for the phrase "crypto key table". Technical comments I am perfectly at ease with the restriction of this document to the case of routing protocols, rather than general security protocols. KARP's mandate is restricted to routing protocols, so a solution specific to routing protocols is appropriate. Section 1, para 1, line 14. "should be used" -> "MUST be used" (Since this document is on the standards track, and since this uniformity of presentation is a key requirement for the CKT, I believe that we have to require MUST here.) Section 2, bullet "Interfaces", line 6. "is specified by the implementation" It is unclear what implementation is under discussion here. The protocol implementation, the operating system implementation, ??? Interface definitions are a characteristic that is (as is stated) independent of the specific protocol, but it is unclear what we should say that they _do_ depend on. See also the comment on Section 4, last paragraph. Section 2, bullet "Protocol", line 1. Upon reading the phrase "single security protocol" in this line, I first felt that this phrase should have been changed when the document scope was reduced from "security protocols" to "routing protocols". However, in some cases, it seems that the protocol named in this field might be "TCP-AO". In other cases, it is reasonable to assume that the protocol where the key will be used is some mode of IPsec. In still further cases, the protocol where the key is used is the Routing Protocol itself (for example, OSPFv2 with Authentication Trailer based security). Therefore, I raise the issue of should this phrase be "single security protocol" or "single Routing Protocol" or something entirely different? Section 2, various bullets. I have a concern about the use of phrases such as "the protocol defines" in Section 2. I believe that the correct phrasing is "the protocol specification defines". If the community agrees, a number of sentences in various bullets will have to be corrected. Section 4, para under the bullets, line 2. "shared among all protocols on an implementation" Should this be "shared among all protocols on a device"? See also the comment on Section 2, bullet "Interfaces". Bill -- 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 hartmans@mit.edu Thu Dec 5 06:40:12 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAE71AE029 for ; Thu, 5 Dec 2013 06:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJT68znAT_Jd for ; Thu, 5 Dec 2013 06:40:10 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB881AE036 for ; Thu, 5 Dec 2013 06:40:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 2B49C205C5; Thu, 5 Dec 2013 09:39:08 -0500 (EST) 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 zZ3anMqiNzIn; Thu, 5 Dec 2013 09:39:06 -0500 (EST) 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; Thu, 5 Dec 2013 09:39:06 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 777C58352D; Thu, 5 Dec 2013 09:40:02 -0500 (EST) From: Sam Hartman To: William Atwood References: <529D667E.6040507@concordia.ca> Date: Thu, 05 Dec 2013 09:40:02 -0500 In-Reply-To: <529D667E.6040507@concordia.ca> (William Atwood's message of "Tue, 03 Dec 2013 00:05:02 -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: KARP Working Group Subject: Re: [karp] Comments on draft-ietf-karp-crypto-key-table X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2013 14:40:13 -0000 >>>>> "William" == William Atwood writes: William> In the spirit of the chairs' plea to read and comment on William> the WG documents, I have read the crypto-key-table document William> carefully. Herewith some comments, which hopefully will be William> useful to the authors, even this late in the cycle. Unless directed otherwise by chairs, I will address comments that regard changes introduced during IESG evaluation. I will take the other comments as too late. I will address some of the formatting comments recieved separately, within the constraints that I have a small window of time available to get a draft out today and I really want that to happen. Many of the other issues will be handled by the RFC editor: they are quite good. Some are actually more technical than formatting. I do think a lot of these issues would be good to consider if we ever do crypto-key-tables BIS. William> Section 2, bullet "Interfaces", line 6. "is specified by William> the implementation" It is unclear what implementation is William> under discussion here. The protocol implementation, the William> operating system implementation, ??? Interface definitions William> are a characteristic that is (as is stated) independent of William> the specific protocol, but it is unclear what we should say William> that they _do_ depend on. See also the comment on Section William> 4, last paragraph. William> Section 2, various bullets. I have a concern about the use William> of phrases such as "the protocol defines" in Section 2. I William> believe that the correct phrasing is "the protocol William> specification defines". If the community agrees, a number William> of sentences in various bullets will have to be corrected. William> Section 4, para under the bullets, line 2. "shared among William> all protocols on an implementation" Should this be "shared William> among all protocols on a device"? See also the comment on William> Section 2, bullet "Interfaces". William> Bill William> -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 William> Distinguished Professor Emeritus fax: +1 (514) 848-2830 William> Department of Computer Science and Software Engineering William> Concordia University EV 3.185 William> email:william.atwood@concordia.ca 1455 de Maisonneuve William> Blvd. West http://users.encs.concordia.ca/~bill Montreal, William> Quebec Canada H3G 1M8 William> _______________________________________________ karp William> mailing list karp@ietf.org William> https://www.ietf.org/mailman/listinfo/karp From internet-drafts@ietf.org Thu Dec 5 17:38:26 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23881AE1EB; Thu, 5 Dec 2013 17:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sewUZKc3NOMK; Thu, 5 Dec 2013 17:38:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB611AE136; Thu, 5 Dec 2013 17:38:23 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206013823.330.82464.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 17:38:23 -0800 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-crypto-key-table-10.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Dec 2013 01:38:26 -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-10.txt Pages : 14 Date : 2013-12-05 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-crypto-key-table-10 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 mjethanandani@gmail.com Thu Dec 5 22:04:24 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1201AE2C8 for ; Thu, 5 Dec 2013 22:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lw9Ado9ciew for ; Thu, 5 Dec 2013 22:04:21 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id DB9041AE234 for ; Thu, 5 Dec 2013 22:04:20 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id f11so277358qae.20 for ; Thu, 05 Dec 2013 22:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qHsrDRuiM/63h7V3tGX6Hf7AJ8UdpU70QvodN10QuQk=; b=MwZcsYZNkputCTWvqlluNuulffDeDNL/pLIW5aS8MaMANcfKm26nNc7MQnogEhZb93 Gx+y0weWhhzqah9rOCckVsB9myQArX4sXrhRyS/LkMhBCBuFmvikHXIQ+SKrCa5nAGpH 2rO3SyoK2rs5J8RZ5YAPjAe0sTnYA+tRRWk3oV7/okaxGimrzmHOgSZS3w13ua9PnRMn MgcJIfGlgO/saJXOymJPpGX8ITXS/E594bfu0J6Ba6x+6zlXz6NOjj2KgkeqMYw2UZad 4dIGo26EA08EFKDnDMiWytIoEhDALJVx9ViejOLXnxIWgZH4Iu4Y4f/SD+5bhJ8Gl4WC 5/gg== X-Received: by 10.229.127.193 with SMTP id h1mr3073459qcs.14.1386309857118; Thu, 05 Dec 2013 22:04:17 -0800 (PST) Received: from [192.168.1.101] (108-247-126-202.lightspeed.sntcca.sbcglobal.net. [108.247.126.202]) by mx.google.com with ESMTPSA id a5sm145096350qae.2.2013.12.05.22.04.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 22:04:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: <5294FE1B.2080605@concordia.ca> Date: Thu, 5 Dec 2013 22:04:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <21395842-54C3-415F-B4AB-BF6F255D4A7C@gmail.com> References: <5294FE1B.2080605@concordia.ca> To: William Atwood X-Mailer: Apple Mail (2.1085) Cc: KARP Working Group Subject: Re: [karp] Comment on draft-mahesh-karp-rkmp X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 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, 06 Dec 2013 06:04:24 -0000 Bill, You are correct in assuming that the document is defining new extensions = to IKEv2 and new semantics for child SA.=20 Will rephrase the rest of the document to reflect that. On Nov 26, 2013, at 12:01 PM, William Atwood wrote: > I have been reading draft-mahesh-karp-rkmp, and I am puzzled by = several > issues. I discuss the first issue below. Once I understand what is > intended by the authors, I expect to raise the other issues. (The way > in which I will phrase these issues may depend on the answer to the > first issue.) >=20 > =46rom the name of the draft, I had always assumed that the document = was > talking about a "new" Key Management Protocol, called RKMP. However, > the key phrase in the first paragraph is "defines a mechanism to = secure > such pairwise Routing Protocol (RP) associations using IKEv2 = [RFC5996]". >=20 > After the introduction, the document discusses how the exchanges build > on the messages and exchange formats of IKEv2: where the semantics are > the same, and where the semantics differ. To my mind, given the > different semantics, the "new" protocol is _not_ IKEv2. However, the > following text continues to speak of "invoking IKEv2", which would = seem > to me to imply "invoking unmodified IKEv2". However, unmodified IKEv2 > has the wrong semantics for what happens to a child SA when the parent > IKEv2 SA is destroyed. >=20 > I suspect that what is really happening here is that > draft-mahesh-karp-rkmp is defining _extensions_ to IKEv2, and new > semantics for child SAs when those extensions are used. The material = in > Section 6 seems to support this view. >=20 > If this is so, then I suggest that Section 1 needs to be lightly > re-written to make it clear that the document is proposing extensions = to > IKEv2, and that references to "IKEv2" in the subsequent text are > references to the extended IKEv2. >=20 > Comments from the authors (and anyone else) will be appreciated. I = need > to understand what is actually intended here before I can comment > properly on the rest of the document. >=20 > Bill >=20 > --=20 > 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 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp Mahesh Jethanandani mjethanandani@gmail.com From bew@cisco.com Tue Dec 24 17:42:26 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4424C1AE193 for ; Tue, 24 Dec 2013 17:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-nXzsNxkwny for ; Tue, 24 Dec 2013 17:42:25 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0744C1AE194 for ; Tue, 24 Dec 2013 17:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=298; q=dns/txt; s=iport; t=1387935741; x=1389145341; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=LK1xili+Adj3muul3X3iuPlz62CWvXVpucyNRHJBsJ8=; b=X9mPvrFlW6BrqnwuTVDG1vVrPpSNCfVQNCXqaGz25j6eO9LVqj1f9zA8 r6aOvxT7mwJD5CqY9ME1uuVzXppPYqC23UCUloD93gxXE/CYIOU5c/iE1 ZtILwkNn/Vm2bV1m3SfvkXpFlBjce7oBWWrDiUu4c4bTDkjOX01JKgMrt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8KAMg2ulKrRDoG/2dsb2JhbABYgws4pUqDDpMYFnSCZoF9EwmHeg6hA6gSF5JHgRMEiUOOVJIUg04b X-IronPort-AV: E=Sophos;i="4.95,546,1384300800"; d="scan'208";a="98129871" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 25 Dec 2013 01:42:20 +0000 Received: from stealth-10-32-244-213.cisco.com (stealth-10-32-244-213.cisco.com [10.32.244.213]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBP1gEs9020286 for ; Wed, 25 Dec 2013 01:42:14 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1A30FD57-D593-4762-AE20-8E4B42168704@cisco.com> Date: Tue, 24 Dec 2013 17:42:16 -0800 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [karp] IETF 88 KARP WG Minutes X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 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, 25 Dec 2013 01:42:26 -0000 Greetings, The KARP WG minutes from the Vancouver meeting have been posted. Many = thanks to Tero Kivinen for providing them. Corrections may be sent to the list or to the chairs = . Joel & Brian=