From hartmans@mit.edu Thu Aug 1 04:18:06 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 6D6C711E810F for ; Thu, 1 Aug 2013 04:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 TyogEHv88tzH for ; Thu, 1 Aug 2013 04:18:00 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E821F9C01 for ; Thu, 1 Aug 2013 04:17:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8CEC52023F for ; Thu, 1 Aug 2013 07:17:14 -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 yJS8BKnBgd2W for ; Thu, 1 Aug 2013 07:17:14 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-4332.meeting.ietf.org [130.129.67.50]) (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 for ; Thu, 1 Aug 2013 07:17:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 86BB680433; Wed, 31 Jul 2013 08:18:21 -0400 (EDT) From: Sam Hartman To: karp@ietf.org Date: Wed, 31 Jul 2013 08:18:21 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [karp] Question: splitting RAPD discussion from policy framework discussion in draft-atwood-karp-aapm-rp 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, 01 Aug 2013 11:18:06 -0000 Hi. During the presentation of our draft, I asked Steve Kent whether he thought it would be valuable to split the discussion of the conseptual database similar to aspects of the IPsec PAD and SPD from the broader policy framework. He said yes. I said it would be valuable to get feedback from others about whether this split is useful. The chairs asked me to ask on the list. 7 From kent@bbn.com Thu Aug 1 04:51: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 DE84921E80C0 for ; Thu, 1 Aug 2013 04:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.377 X-Spam-Level: X-Spam-Status: No, score=-106.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 JPbjtGYFONni for ; Thu, 1 Aug 2013 04:51:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A118921E80B5 for ; Thu, 1 Aug 2013 04:51:04 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47516 helo=dhcp-13ac.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V4rPG-0009nI-CG for karp@ietf.org; Thu, 01 Aug 2013 07:50:58 -0400 Message-ID: <51FA4BA1.7020508@bbn.com> Date: Thu, 01 Aug 2013 07:50:57 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: karp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [karp] Question: splitting RAPD discussion from policy framework discussion in draft-atwood-karp-aapm-rp 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, 01 Aug 2013 11:51:10 -0000 I asked that we consider this split because I support adoption of the discussion of the SPD/PAD-like mechanisms, but do not support the broader, rather high level policy framework text. So, count me as one vote for the split. Steve > Hi. During the presentation of our draft, I asked Steve Kent whether he > thought it would be valuable to split the discussion of the conseptual > database similar to aspects of the IPsec PAD and SPD from the broader > policy framework. He said yes. I said it would be valuable to get > feedback from others about whether this split is useful. The chairs > asked me to ask on the list. > 7 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From housley@vigilsec.com Thu Aug 1 05:14:29 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 0FA1E21E80F7 for ; Thu, 1 Aug 2013 05:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 0lGe39Zc8KUb for ; Thu, 1 Aug 2013 05:14:22 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id CA7DB21F994B for ; Thu, 1 Aug 2013 05:14:00 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 3DBD2F2407E; Thu, 1 Aug 2013 08:14:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id kYaxb2-NS+1Z; Thu, 1 Aug 2013 08:13:57 -0400 (EDT) Received: from dhcp-540a.meeting.ietf.org (dhcp-540a.meeting.ietf.org [130.129.84.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7CBACF24038; Thu, 1 Aug 2013 08:13:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Thu, 1 Aug 2013 08:13:54 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7F6E286F-A089-4AB3-9490-5DFDF2A69278@vigilsec.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1085) Cc: karp@ietf.org Subject: Re: [karp] Question: splitting RAPD discussion from policy framework discussion in draft-atwood-karp-aapm-rp 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, 01 Aug 2013 12:14:29 -0000 I agree that it would be valuable to tackle the "broader policy framework." Russ On Jul 31, 2013, at 8:18 AM, Sam Hartman wrote: > Hi. During the presentation of our draft, I asked Steve Kent whether he > thought it would be valuable to split the discussion of the conseptual > database similar to aspects of the IPsec PAD and SPD from the broader > policy framework. He said yes. I said it would be valuable to get > feedback from others about whether this split is useful. The chairs > asked me to ask on the list. From hartmans@mit.edu Thu Aug 1 05:51:59 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 5655B21E80AF for ; Thu, 1 Aug 2013 05:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 xlYLc7r5iCFx for ; Thu, 1 Aug 2013 05:51:53 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 88F0D21F9EFB for ; Thu, 1 Aug 2013 05:51:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9F2A62021A; Thu, 1 Aug 2013 08:50:55 -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 NhhMxBCXfHqM; Thu, 1 Aug 2013 08:50:55 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-4332.meeting.ietf.org [130.129.67.50]) (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, 1 Aug 2013 08:50:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2FDA680D75; Thu, 1 Aug 2013 08:51:33 -0400 (EDT) From: Sam Hartman To: Russ Housley References: <7F6E286F-A089-4AB3-9490-5DFDF2A69278@vigilsec.com> Date: Thu, 01 Aug 2013 08:51:33 -0400 In-Reply-To: <7F6E286F-A089-4AB3-9490-5DFDF2A69278@vigilsec.com> (Russ Housley's message of "Thu, 1 Aug 2013 08:13:54 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Question: splitting RAPD discussion from policy framework discussion in draft-atwood-karp-aapm-rp 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, 01 Aug 2013 12:51:59 -0000 >>>>> "Russ" == Russ Housley writes: Russ> I agree that it would be valuable to tackle the "broader Russ> policy framework." Russ Do you think it would be helpful to split them into a separate document? From housley@vigilsec.com Thu Aug 1 05:55: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 22B4421E80F8 for ; Thu, 1 Aug 2013 05:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.702 X-Spam-Level: X-Spam-Status: No, score=-102.702 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 GauVlXbKhwL3 for ; Thu, 1 Aug 2013 05:55:12 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 632CF21F9E22 for ; Thu, 1 Aug 2013 05:53:42 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 6AD36F24038; Thu, 1 Aug 2013 08:54:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id BZEXX7uQ2GTN; Thu, 1 Aug 2013 08:53:34 -0400 (EDT) Received: from dhcp-540a.meeting.ietf.org (dhcp-540a.meeting.ietf.org [130.129.84.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CD989F2401B; Thu, 1 Aug 2013 08:54:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Thu, 1 Aug 2013 08:53:38 -0400 Content-Transfer-Encoding: 7bit Message-Id: <523BEE6E-0C37-498C-8C42-6F5D3E26092F@vigilsec.com> References: <7F6E286F-A089-4AB3-9490-5DFDF2A69278@vigilsec.com> To: Sam Hartman X-Mailer: Apple Mail (2.1085) Cc: karp@ietf.org Subject: Re: [karp] Question: splitting RAPD discussion from policy framework discussion in draft-atwood-karp-aapm-rp 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, 01 Aug 2013 12:55:21 -0000 Sam: > Russ> I agree that it would be valuable to tackle the "broader > Russ> policy framework." Russ > > Do you think it would be helpful to split them into a separate document? Yes please. Russ From uma.chunduri@ericsson.com Thu Aug 1 12:05:35 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 260E111E8138 for ; Thu, 1 Aug 2013 12:05:33 -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 DdGyY8gzMrFZ for ; Thu, 1 Aug 2013 12:05:26 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4474811E8137 for ; Thu, 1 Aug 2013 12:05:24 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-2b-51fab173db04 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1A.86.31362.371BAF15; Thu, 1 Aug 2013 21:05:23 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Thu, 1 Aug 2013 15:05:23 -0400 From: Uma Chunduri To: Stephen Kent , "karp@ietf.org" Thread-Topic: [karp] Question: splitting RAPD discussion from policy framework discussion in draft-atwood-karp-aapm-rp Thread-Index: AQHOjq2bprwB0oEKjEORNDbnpKFp3JmAr+2A Date: Thu, 1 Aug 2013 19:05:22 +0000 Message-ID: <1B502206DFA0C544B7A604691520086317445FEC@eusaamb105.ericsson.se> References: <51FA4BA1.7020508@bbn.com> In-Reply-To: <51FA4BA1.7020508@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.53.73.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyuXRPrG7xxl+BBss/KVns/baG0WLjbEYH Jo+p50M9liz5yRTAFMVlk5Kak1mWWqRvl8CV0bllNkvBWvGKH2s/sDUwfhLqYuTkkBAwkVj4 YxobhC0mceHeeiCbi0NI4CijRPOK+cwgCSGBZYwSvy8Lg9hsAnoSH6f+ZAexRQQcJDpurWAB sYUFyiXm3NvOCBGvkLh17jOUbSSxfP1+sBoWARWJBR3NYHFeAV+JhbuWsUPMd5C4da0BLM4p oC7Ruu4wWJwR6KDvp9YwgdjMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWxFida7/5kh6nUk Fuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaO0OLUsN93IcBMj MBKOSbA57mBc8MnyEKM0B4uSOO8GvTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhj7F2WU C1hXr/koVnfHyeh69wx+0Wevj83R839jNVlZRuZD5cHFvgaquySSj/dP/tJxVP6JpEL24k0/ C1MXZ7td5Lwh9tHBWPGb8s78f68+fmxhSJJuU3rj6XnFc/Iy/anZ14yTfwXusVkprPhYb2+v TpK5tQI3/zHPRxER8s3md9bVPchf9FSJpTgj0VCLuag4EQB2KZWdUgIAAA== Subject: Re: [karp] Question: splitting RAPD discussion from policy framework discussion in draft-atwood-karp-aapm-rp 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, 01 Aug 2013 19:05:35 -0000 Great and headed response Steve. >> support adoption of the discussion of the SPD/PAD-like mechanisms Conceptually this is critical for IKEv2 integration of RPs and KARP discuss= ions focused=20 less on this.=20 Though http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/?in= clude_text=3D1=20 is important for RP integration with IKEv2 but it's not sufficient unless y= ou solve the=20 RP policy is given to IKE. At best crypto-tables can be seen as SAD (for so= me RPs). FWIW, this is one of the main reasons Gatekeeper was introduced=20 http://datatracker.ietf.org/doc/draft-chunduri-karp-using-ikev2-with-tcp-ao= / and presented in earlier IETF meetings. This essentially is the repository = of=20 the pair wise RP policy to be presented for IKEv2. With out this an IKEv2 r= esponder can't=20 get a comprehensive view of what SA it should negotiate, for which traffic = selectors and for which RP. >> but do not support the broader, rather high level policy framework text. +10 Also I feel, should not mix RKMP (KMP for pair wise RPs) and MRKMP (KMP for= group keying RPs)=20 and attempt to create a high level policy frame work. I believe, this can s= everely complicate things=20 rather than helping in actual implementation and usage. This is what I propose: 1. Policy framework for pair-wise RPs which use RFC 5996 [IKEv2] - It's been in the discussion for quite a while in KARP and=20 the draft I mentioned above 2. Policy framework for group keying RPs which use variant of IKEv2=20 (any draft close to publication which can get us there??) 3. We should try to use PAD as is (most of it) to leverage existing IKEv2 c= ode base --=20 Uma C.=20 -----Original Message----- From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Ste= phen Kent Sent: Thursday, August 01, 2013 4:51 AM To: karp@ietf.org Subject: Re: [karp] Question: splitting RAPD discussion from policy framewo= rk discussion in draft-atwood-karp-aapm-rp I asked that we consider this split because I support adoption of the discu= ssion of the SPD/PAD-like mechanisms, but do not support the broader, rathe= r high level policy framework text. So, count me as one vote for the split. Steve > Hi. During the presentation of our draft, I asked Steve Kent whether=20 > he thought it would be valuable to split the discussion of the=20 > conseptual database similar to aspects of the IPsec PAD and SPD from=20 > the broader policy framework. He said yes. I said it would be=20 > valuable to get feedback from others about whether this split is=20 > useful. The chairs asked me to ask on the list. > 7 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From david.black@emc.com Fri Aug 9 08:19:36 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 9A0BC11E8196; Fri, 9 Aug 2013 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 rxH3MI7Ew7wF; Fri, 9 Aug 2013 08:19:28 -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 86E9021F9EFC; Fri, 9 Aug 2013 08:11:18 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r79ElVGn030222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 10:47:31 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 9 Aug 2013 10:47:07 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r79El6Ae021361; Fri, 9 Aug 2013 10:47:06 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Fri, 9 Aug 2013 10:47:05 -0400 From: "Black, David" To: "housley@vigilsec.com" , "tim.polk@nist.gov" , "Sam Hartman (hartmans@painless-security.com)" , "Dacheng Zhang (zhangdacheng@huawei.com)" , "General Area Review Team (gen-art@ietf.org)" Date: Fri, 9 Aug 2013 10:47:05 -0400 Thread-Topic: Gen-ART review of draft-ietf-karp-crypto-key-table-08 Thread-Index: Ac6VD0rmlAaf+56PTd+LLDqqvEOcAQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@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 Cc: "Black, David" , "karp@ietf.org" , "ietf@ietf.org" Subject: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:19:37 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-karp-crypto-key-table-08 Reviewer: David L. Black Review Date: August 9, 2013 IETF LC End Date: April 29, 2013 IETF Telechat Date: August 15, 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. The draft authors have addressed most of the issues and concerns from the GenART review of the -07 version of this draft, but three issues remain. I am particularly concerned with the first issue about whether FCFS is appropriate for these security-related registries, and believe that topic deserves IESG discussion. The three issues are ([9], [A] and [C] are the issue identifiers used on the original Gen-ART review of the -07 version of this draft): Major issue: [9] I suggest Expert Review for the new IANA 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. [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 reasons. Nits/editorial comments: First paragraph in 8.1.2 should be at end of 8.1.1. idnits 2.12.17 found two nits - the latter one (2119 reference/boilerplate) needs attention: ** There are 2 instances of too long lines in the document, the longest o= ne being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords.=20 RFC 2119 keyword, line 194: '...tion of key material. The KDF MAY use= ...' RFC 2119 keyword, line 196: '... or received but MUST NOT depend on ot= ...' 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 jari.arkko@piuha.net Tue Aug 13 12:06:59 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 8297121E819B; Tue, 13 Aug 2013 12:06:59 -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 VCSG0zwi-Gpp; Tue, 13 Aug 2013 12:06:54 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6321E8182; Tue, 13 Aug 2013 12:06:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5474D2CC48; Tue, 13 Aug 2013 22:06:52 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNMQpgcndOya; Tue, 13 Aug 2013 22:06:51 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 56AE62CC5B; Tue, 13 Aug 2013 22:06:46 +0300 (EEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jari Arkko In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> Date: Wed, 14 Aug 2013 03:06:45 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5D641C7D-768F-4FB0-8DFC-D2C247E0F63A@piuha.net> References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1508) Cc: "Sam Hartman \(hartmans@painless-security.com\)" , "ietf@ietf.org" , "tim.polk@nist.gov" , "General Area Review Team \(gen-art@ietf.org\)" , "karp@ietf.org" Subject: Re: [karp] [Gen-art] Gen-ART review of draft-ietf-karp-crypto-key-table-08 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, 13 Aug 2013 19:06:59 -0000 Thank you for your review, David. The Gen-ART reviews are important = feedback for me to understand where I should look more closely.=20 In this case your review caused me to read the draft in detail, and I = now have similar question as you did. I have raised a Discuss in my IESG = ballot so that we can talk about those issues with the authors. In = particular, it would be useful to discuss whether FCFS or some other = assignment policy is most appropriate for the algorithm ID and KDF = registries. I too thought Expert Review would have been a more natural = fit. But I do not mind another policy, as long as we have a good reason = for picking it. Secondly, I too was wondering what the relationship of = this database is to the PAD. Jari From hartmans@mit.edu Wed Aug 14 08:18:47 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 8231B21E80C7 for ; Wed, 14 Aug 2013 08:18:47 -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 gREiVd1pYHN4 for ; Wed, 14 Aug 2013 08:18:41 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9E51C21E80C8 for ; Wed, 14 Aug 2013 08:18:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A59802028D; Wed, 14 Aug 2013 11:17:30 -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 8ODw6paCNJ3i; Wed, 14 Aug 2013 11:17:30 -0400 (EDT) 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; Wed, 14 Aug 2013 11:17:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3C2938051A; Wed, 14 Aug 2013 11:18:39 -0400 (EDT) From: Sam Hartman To: Radia Perlman References: Date: Wed, 14 Aug 2013 11:18:39 -0400 In-Reply-To: (Radia Perlman's message of "Tue, 13 Aug 2013 22:02:38 -0700") 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@ietf.org Subject: Re: [karp] secdir review of draft-ietf-karp-ops-model-07 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:18:47 -0000 >>>>> "Radia" == Radia Perlman writes: Radia> I think the document would be much improved with an Radia> introduction about what is different for "routing protocol Radia> security" rather than, say, an endnode authenticating to an Radia> access point, or nodes forming a peer relationship in an Radia> overlay network. So, for instance, "normal security issues" Radia> (i.e., outside the scope of KARP) might assume the network is Radia> up, so that it's possible to get CRLs, or be available to be Radia> managed, whereas perhaps KARP is targetting cases which Radia> depend on less infrastructure. It would be nice if this Radia> document were to have an introduction that talks about things Radia> like that. I think that one of the previous KARP documents (the overview or design guide) includes a good review of that material. I know I've seen a good write up of this in the KARP context before. KARP folks can you help jog my memory so I can add a reference? From mjethanandani@gmail.com Wed Aug 14 08:30: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 47DBD21F9B5C for ; Wed, 14 Aug 2013 08:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 g0FxUmS6DJ9Z for ; Wed, 14 Aug 2013 08:30:08 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id CE85C11E814C for ; Wed, 14 Aug 2013 08:29:50 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id jt11so2587571pbb.38 for ; Wed, 14 Aug 2013 08:29:50 -0700 (PDT) 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 :message-id:references:to; bh=gvdlsULykA5tKPNgSehpzIBYXWoLLaBUgQqVYea0IUw=; b=FncRsek4ux9LzK5vBb0J8uy/nYOch+NAG7PiGvcvT/B67jPKNmw/QJMedZaYGSebAA p3A9gG2C7Wv7Y0IKSKhdqLyF6vvHRUKKAiso/LMbK6lQNinNafwe4ExHMCTu97B/6xyA i+JT/ry/TS0/n17Ifoqc+YvjBiAJL7aP1IkKCMpLroXKwKWzFgNzSJK8r1tDmSHZiQ1t +YoN7uk7oV0j9XXCJz9GFkC5oDhj/ss9dx0Arq9ywXNXhKNz3c/ENSfcRYfEk9Smgy6C QhN9Ergu2KJVVPMtjNgujQJx8kDh/EfHKLBwz5JiEqN2qGZNtjFLxT8L3nEyqChcwEj5 UBHQ== X-Received: by 10.67.10.11 with SMTP id dw11mr2536011pad.161.1376494190380; Wed, 14 Aug 2013 08:29:50 -0700 (PDT) Received: from [192.168.1.125] (c-107-3-160-68.hsd1.ca.comcast.net. [107.3.160.68]) by mx.google.com with ESMTPSA id sx7sm50946568pbc.41.2013.08.14.08.29.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 08:29:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-4-902511736 From: Mahesh Jethanandani In-Reply-To: Date: Wed, 14 Aug 2013 08:29:46 -0700 Message-Id: <2EFA58D3-EFA1-422D-99B3-19ADFAC8AE4B@gmail.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1085) Cc: Radia Perlman , karp@ietf.org Subject: Re: [karp] secdir review of draft-ietf-karp-ops-model-07 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:30:09 -0000 --Apple-Mail-4-902511736 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sam, I think you are referring to RFC 4948 and RFC 6518. On Aug 14, 2013, at 8:18 AM, Sam Hartman wrote: >>>>>> "Radia" == Radia Perlman writes: > > Radia> I think the document would be much improved with an > Radia> introduction about what is different for "routing protocol > Radia> security" rather than, say, an endnode authenticating to an > Radia> access point, or nodes forming a peer relationship in an > Radia> overlay network. So, for instance, "normal security issues" > Radia> (i.e., outside the scope of KARP) might assume the network is > Radia> up, so that it's possible to get CRLs, or be available to be > Radia> managed, whereas perhaps KARP is targetting cases which > Radia> depend on less infrastructure. It would be nice if this > Radia> document were to have an introduction that talks about things > Radia> like that. > > I think that one of the previous KARP documents (the overview or design > guide) includes a good review of that material. I know I've seen a > good write up of this in the KARP context before. > KARP folks can you help jog my memory so I can add a reference? > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail-4-902511736 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
"Radia" =3D=3D Radia Perlman = <radiaperlman@gmail.com> = writes:

   Radia>    I think the = document would be much improved with an
   Radia> = introduction about what is different for "routing protocol
=    Radia> security" rather than, say, an endnode = authenticating to an
   Radia> access point, or = nodes forming a peer relationship in an
   Radia> = overlay network.  So, for instance, "normal security issues"
=    Radia> (i.e., outside the scope of KARP) might = assume the network is
   Radia> up, so that it's = possible to get CRLs, or be available to be
=    Radia> managed, whereas perhaps KARP is targetting = cases which
   Radia> depend on less = infrastructure.  It would be nice if this
=    Radia> document were to have an introduction that = talks about things
   Radia> like that.

I = think that one of the previous KARP documents  (the overview or = design
guide) includes  a good review of that material.  I = know I've seen a
good write up of this in the KARP context = before.
KARP folks can you help jog my memory so I can add a = reference?
_______________________________________________
karp = mailing list
karp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/karp

Mahesh = Jethanandani
<= div>


= --Apple-Mail-4-902511736-- From bew@cisco.com Wed Aug 14 10:28:40 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F1E21F9A78 for ; Wed, 14 Aug 2013 10:28:40 -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 GuFex8h9cJXP for ; Wed, 14 Aug 2013 10:28:35 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0767521F9BA0 for ; Wed, 14 Aug 2013 10:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1724; q=dns/txt; s=iport; t=1376501315; x=1377710915; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RmHpF//EjcAn81gOzmrvnR6hiPpUD42bIt7DrO+9NuU=; b=ak6+riMbYYlvw85xlOay9xCHridV573ZHxLAuVLj0P/nr/qH7Z7DK7Gz 6Z7yrf3KAyLJIeMqFYK8buauc5KR+V6nyTqQptByYp2YrBIoAGAezCrv2 ZcEBuZ0F78TX3B65yR/72IxTNdavXq0SWpPrjMD5HzGwlLlGFpC3vNp1I w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFALW9C1KrRDoG/2dsb2JhbABSCQ6CeKwak1CBJBZ0giUBAQQ6OAcQC0YhNgYTh34DDrAcDYhejVWBNYETMweDG3cDiS2MToFpjCuFJ4JdXhw X-IronPort-AV: E=Sophos;i="4.89,878,1367971200"; d="scan'208";a="86597329" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 14 Aug 2013 17:28:30 +0000 Received: from stealth-10-32-244-212.cisco.com (stealth-10-32-244-212.cisco.com [10.32.244.212]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7EHSSSg008235; Wed, 14 Aug 2013 17:28:28 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Weis In-Reply-To: Date: Wed, 14 Aug 2013 10:28:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01BFCE05-25D6-4DFD-B6DD-C424266AD1B8@cisco.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1503) Cc: Radia Perlman , karp@ietf.org Subject: Re: [karp] secdir review of draft-ietf-karp-ops-model-07 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:28:40 -0000 On Aug 14, 2013, at 8:18 AM, Sam Hartman wrote: >>>>>> "Radia" =3D=3D Radia Perlman writes: >=20 > Radia> I think the document would be much improved with an > Radia> introduction about what is different for "routing protocol > Radia> security" rather than, say, an endnode authenticating to an > Radia> access point, or nodes forming a peer relationship in an > Radia> overlay network. So, for instance, "normal security issues" > Radia> (i.e., outside the scope of KARP) might assume the network = is > Radia> up, so that it's possible to get CRLs, or be available to be > Radia> managed, whereas perhaps KARP is targetting cases which > Radia> depend on less infrastructure. It would be nice if this > Radia> document were to have an introduction that talks about = things > Radia> like that. >=20 > I think that one of the previous KARP documents (the overview or = design > guide) includes a good review of that material. I know I've seen a > good write up of this in the KARP context before. > KARP folks can you help jog my memory so I can add a reference? This is a valuable point. But I can't find that good write-up in an RFC = or I-D. Actually, Section 4.4 (The role of Central Servers) of this = document has the best description conveying the point that minimal = infrastructure is desirable.=20 The best I find is RFC 6862, Section 1.1 Terminology, under Identity = Authentication: "Certificates can be used in ways that require no = additional supporting systems external to the routers themselves." That = does not fully convey the thought that but could be referenced. Brian= From hartmans@mit.edu Wed Aug 14 12:31:58 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 CDF3221E808C; Wed, 14 Aug 2013 12:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 8VZudT0fEjn7; Wed, 14 Aug 2013 12:31:53 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id DFCE921F99D0; Wed, 14 Aug 2013 12:31:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9212A20280; Wed, 14 Aug 2013 15:30:41 -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 TLmALA9OwzD7; Wed, 14 Aug 2013 15:30:41 -0400 (EDT) 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; Wed, 14 Aug 2013 15:30:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3D9D48051A; Wed, 14 Aug 2013 15:31:50 -0400 (EDT) From: Sam Hartman To: "Black\, David" References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> Date: Wed, 14 Aug 2013 15:31:50 -0400 In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> (David Black's message of "Fri, 9 Aug 2013 10:47:05 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ietf@ietf.org" , "tim.polk@nist.gov" , "General Area Review Team \(gen-art@ietf.org\)" , "karp@ietf.org" Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 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, 14 Aug 2013 19:31:59 -0000 >>>>> "Black," == Black, David writes: Black,> [A] Overall - I would like to see a paragraph added on how Black,> this database conceptually relates to the IPsec Peer Black,> Authorization Database (PAD) - see RFC 4301, section 4.4.3. It doesn't. not even a little bit. It's not IPsec; it's not about what key management peers to interact with. It's conceptually similar to the Security Association Database (SAD). In a discussion with Jari I agreed to propose text for a paragraph describing how this interacts with IPsec. If this conceptual database is used to manage to keys for a security protocol that uses IPsec [RFC4301] security services, then the interactions between this conceptual database and the IPsec databases needs to be described by the protocol specification. Typically such a protocol would insert entries into the Security Association Database (SAD) when rows are inserted into the key table and remove SAD entries when key table rows are removed. The protocol specification needs to describe how the SAD entries are constructed along with any other IPsec database entries that are needed, including a description of how these entries are ordered along with other IPsec database entries. The question of whether it is desirable to use this conceptual database to manage protocols that use IPsec security services is open and has not been evaluated. Black,> [C] (Section 3) Where does key selection occur? I would Black,> suggest that the database return all possible keys and let Black,> the protocol figure out what to use. This is particularly Black,> important for inbound traffic for obvious reasons. I think we've discussed key selection in the WG and come to a different conclusion. The key table selects the key. We expect peer, key ID, protocol and interface to identify a unique key for an inbound packet. So, I think the concern you raise is not a problem. While there was not a specific thread discussing key selection or this issue, there were multiple reviewers who provided comments on key selection over the development of the document, and making a major change at this point without a technical problem seems undesirable. If I'm missing something and the inbound packet issue is a problem then we need to discuss it. From hartmans@mit.edu Wed Aug 14 12:19: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 43AE911E81F0; Wed, 14 Aug 2013 12:19: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 ZCuz8wprUAt7; Wed, 14 Aug 2013 12:19: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 D417411E81D3; Wed, 14 Aug 2013 12:19:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5681420288; Wed, 14 Aug 2013 15:17:58 -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 Ad05Q-xHOkXP; Wed, 14 Aug 2013 15:17:57 -0400 (EDT) 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; Wed, 14 Aug 2013 15:17:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0E4688051A; Wed, 14 Aug 2013 15:19:06 -0400 (EDT) From: Sam Hartman Newsgroups: To: "Black\, David" References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> Date: Wed, 14 Aug 2013 15:19:06 -0400 In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> (David Black's message of "Fri, 9 Aug 2013 10:47:05 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 15 Aug 2013 09:24:45 -0700 Cc: "ietf@ietf.org" , "tim.polk@nist.gov" , "General Area Review Team \(gen-art@ietf.org\)" , "karp@ietf.org" Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 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, 14 Aug 2013 19:19:21 -0000 David, as we mentioned in the IESG thread, we seem to have dropped the response to your comments about IANA actions. WG: >From the genart review: [9] I suggest Expert Review for the new IANA registries, not just First Come First Served, so that someone with a security "clue" can check that the proposed registrations are reasonable. Stephen has filed a related DISCUSS position. He's confused why we need a registry for KDFs or algorithms. He argues that the protocols should already have such a registry. He argues that it would be non-sensical to register a value in this registry but not the protocol registry. In a somewhat related discussion, multiple people have asked what the scope of this document is. Are we defining something for routing protocols? Any security protocol in the world? Something in-between? IU'm going to make two responses: 1) I think FCFS is not harmful for these registries. David's main concern is that bad security will get registered. I'll point out that these registries are not about what security you can use with a routing protocol, but about what security you can configure from a management standpoint. Registering rot13 or similarly questionable security here wouldn't mean I could use it with a routing protocol, only that I could ask a system to do so. If ROT13 was not actually in the security-specific registries for the protocols in question there'd be no way to send a rot13-transformed message. I think people wanting to use bad security in routing protocols will focus on specifying how to use the security for the protocols, and that's the appropriate place to do any gateway review. Yeah, I guess with FCFS it's possible someone could register here and then later realize they cannot get their md4 security approved in the actual protocol registry document. That might be confusing but doesn't seem very harmful. Also, some routing protocols are protected by cleartext passwords sent over the network. We want to be able to manage that, so we will be registering plaintext password in these registries. I don't think anyone will come up with anything worse than that. Finally, I think a lot of us have begun to question the value in security review for codepoint assignment. Some security WGs care a lot; some don't seem to care much at all. 2) Why I prefer FCFS or at least would object strongly to expert review. If we're going to say we want expert review I want us to give expert instructions at least good enough that I believe I could answer the question of what registrations to approve if I were appointed the expert. I don't think we could come to consensus on those instructions very easily. In particular, I think it would be challenging for us to describe what security protocols the protocol registry applies to and which ones it does not. I'm totally fine publishing this document knowing it will be used for routing protocols but not knowing what beyond routing protocols it will be used for. If we do that FCFS makes a lot of sense. So, my recommendation is that we keep our current registration policy. From kent@bbn.com Thu Aug 15 13:05: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 1DD4121F994C; Thu, 15 Aug 2013 13:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 MR3E+1z9E4C4; Thu, 15 Aug 2013 13:04:57 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A2AF421F9798; Thu, 15 Aug 2013 13:04:57 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53876) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VA3my-0007db-3Y; Thu, 15 Aug 2013 16:04:56 -0400 Message-ID: <520D3467.1080107@bbn.com> Date: Thu, 15 Aug 2013 16:04:55 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sam Hartman References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "tim.polk@nist.gov" , "Black, David" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "karp@ietf.org" Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 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, 15 Aug 2013 20:05:06 -0000 David, I agree with Sam here. The key table is analogous to the SPD in 4301, but not the PAD. Another doc being developed in the KARP WG does have a "Routing Authentication Policy Database" (RAPD) that incorporates aspects of the PAD from 4301, as well as some SPD fields. Steve From uma.chunduri@ericsson.com Thu Aug 15 16:06:28 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCD211E8219; Thu, 15 Aug 2013 16:06:28 -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 ozKzQkLAR7SH; Thu, 15 Aug 2013 16:06:21 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C6DB711E8138; Thu, 15 Aug 2013 16:06:20 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-5e-520d5eeb6002 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1F.0F.09414.BEE5D025; Fri, 16 Aug 2013 01:06:19 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Thu, 15 Aug 2013 19:06:18 -0400 From: Uma Chunduri To: Stephen Kent , Sam Hartman Thread-Topic: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 Thread-Index: Ac6VD0rmlAaf+56PTd+LLDqqvEOcAQEFcz9OADvJOYAAAi6WMA== Date: Thu, 15 Aug 2013 23:06:18 +0000 Message-ID: <1B502206DFA0C544B7A60469152008631747F84B@eusaamb105.ericsson.se> References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> <520D3467.1080107@bbn.com> In-Reply-To: <520D3467.1080107@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.53.74.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPlO7rON4gg3t3JS22Hl7LbnH11WcW izlfV7NZPNs4n8Vi77c1jBYbZzNafFr1mMmB3WPq+VCPI0dms3gsWfKTyaPpzFFmj2sn/7IG sEZx2aSk5mSWpRbp2yVwZUxbGFpwl7Hi7/ZGpgbGZYxdjJwcEgImEs1PG9khbDGJC/fWs3Ux cnEICRxllNiz5iQ7hLOcUeLVu2msIFVsAnoSH6f+BOsQEXCR2PdsNSNIEbPATUaJI5u+MoEk hAU8JRa2rQYaxQFU5CXxq5cFwnSS+NKQB1LBIqAqsW/OQ2aQMK+Ar8Sas1CrGhgl/k7YD3Yc p4C6xJRNZ8DWMgId9/3UGrDpzALiEreezGeCOFpAYsme88wQtqjEy8f/WCFsBYkdi36xQNTr SCzY/YkNwtaWWLbwNVg9r4CgxMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw33chg EyMw3o5JsOnuYNzz0vIQozQHi5I47yq9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGE2+ f+c7ynouv2y1oUl5ydP9O38+PmgYniD7KYVrudOOTU3TLrYcZph+7dmSRUqcVVb1Nb9+cbZI XH9pyMsn6tXzl+9Khb3KnF/l96VTGH5tc534Wsmr34bVsp2xdc+N+jBujisXb+r1hNyzaj+z dfnuFdkeLWFGXdFBXCK7XPOun2Nnzjt0XImlOCPRUIu5qDgRACJAkDGFAgAA Cc: "tim.polk@nist.gov" , "Black, David" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "karp@ietf.org" Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 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, 15 Aug 2013 23:06:28 -0000 =20 >> The key table is analogous to the SPD in 4301, but not the PAD. Close to SAD not SPD for some RPs as it have negotiation result including k= eys.=20 But not definitely analogous to the PAD. -- Uma C.= From david.black@emc.com Fri Aug 16 10:01:07 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 D239421F9AEF; Fri, 16 Aug 2013 10:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 SDlzf6VHIBZc; Fri, 16 Aug 2013 10:01:02 -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 088F521F9A2A; Fri, 16 Aug 2013 10:01:00 -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 r7GH0YWt004445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 13:00:36 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 16 Aug 2013 13:00:14 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7GH0Dvp023435; Fri, 16 Aug 2013 13:00:13 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Fri, 16 Aug 2013 13:00:12 -0400 From: "Black, David" To: Sam Hartman Date: Fri, 16 Aug 2013 13:00:11 -0400 Thread-Topic: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 Thread-Index: Ac6ZIxPCrHP82d6uQRm+ncYL1wquCwBezKGg Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129C489288@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@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" , "General Area Review Team \(gen-art@ietf.org\)" , "Black, David" , "karp@ietf.org" Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 17:01:08 -0000 Sam, Thanks for picking this up. Unlike my other two concerns with this draft, I think we have a longer discussion ahead of us on this one. Your summary of my concern is on the mark: > David's main concern is that bad security will get registered. I understand the response to be two-fold: 1) It doesn't matter; the controlling registry for crypto algorithm usage is the protocol-specific registry, not the key table database registry. 2) The guidance for the Expert Reviewer will be very difficult to write. I'm not convinced by either of these, sorry. I'm concerned that the two-registry subtlety in 1) will be lost on implementers, especially because (as mentioned in the IESG thread), this key table database is likely to see use beyond routing protocols. Among other things, it's being proposed as a general mechanism for keying RSVP, not just RSVP-TE (I'm one of the co-chairs of the tsvwg WG that's responsible for RSVP). That key table databases registry is also likely to be a place that designers of new protocols look to figure out what to use for security. As for cleartext passwords: > Also, some routing protocols are protected by cleartext passwords sent > over the network. We want to be able to manage that, so we will be > registering plaintext password in these registries. > I don't think anyone will come up with anything worse than that. I read the first sentence in Section 2 of this draft as excluding cleartext passwords: The database is characterized as a table, where each row represents a single long-lived symmetric cryptographic key. If someone wants to argue that a cleartext password is a "long-lived symmetric cryptographic key", I'll go break out the popcorn and watch w/amusement :-). Seriously, if the intention is to include cleartext passwords, then I think some more rewriting is in order, and I would suggest checking directly with the Security ADs before going there. As for 2), the fact that it will be difficult (with which I agree) doesn't imply that it isn't necessary or shouldn't be done. IMHO, we really should be setting a bar that says that this sort of IETF imprimatur of approval of a crypto algorithm actually means something. I appreciate that FCFS provides an easier path forward, however I'm reminded by analogy of something I learned from my grad school software engineering professor: I can make the code run arbitrarily fast ... ... if it doesn't have to be correct. I'm rather uncomfortable with this use of process expediency as a rationale for avoiding a technical concern. This may ultimately be an issue that the IESG needs to sort out, as the level of security for IETF protocols and concerns about "vanity crypto"=20 extend well beyond the karp WG, but discussion ought to start here. Thanks, --David > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietfc@mit.edu] > Sent: Wednesday, August 14, 2013 3:19 PM > To: Black, David > Cc: housley@vigilsec.com; tim.polk@nist.gov; Dacheng Zhang > (zhangdacheng@huawei.com); General Area Review Team (gen-art@ietf.org); > karp@ietf.org; ietf@ietf.org > Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 >=20 >=20 >=20 > David, as we mentioned in the IESG thread, we seem to have dropped the > response to your comments about IANA actions. >=20 > WG: > From the genart review: >=20 > [9] I suggest Expert Review for the new IANA registries, not just > First Come First Served, so that someone with a security "clue" can > check that the proposed registrations are reasonable. >=20 >=20 > Stephen has filed a related DISCUSS position. He's confused why we need > a registry for KDFs or algorithms. > He argues that the protocols should already have such a registry. He > argues that it would be non-sensical to register a value in this > registry but not the protocol registry. >=20 > In a somewhat related discussion, multiple people have asked what the > scope of this document is. Are we defining something for routing > protocols? Any security protocol in the world? Something in-between? >=20 >=20 > IU'm going to make two responses: >=20 > 1) > I think FCFS is not harmful for these registries. >=20 > David's main concern is that bad security will get registered. >=20 > I'll point out that these registries are not about what security you can > use with a routing protocol, but about what security you can configure > from a management standpoint. > Registering rot13 or similarly questionable security here wouldn't mean > I could use it with a routing protocol, only that I could ask a system > to do so. If ROT13 was not actually in the security-specific registries > for the protocols in question there'd be no way to send a > rot13-transformed message. >=20 > I think people wanting to use bad security in routing protocols will > focus on specifying how to use the security for the protocols, and > that's the appropriate place to do any gateway review. > Yeah, I guess with FCFS it's possible someone could register here and > then later realize they cannot get their md4 security approved in the > actual protocol registry document. >=20 > That might be confusing but doesn't seem very harmful. >=20 > Also, some routing protocols are protected by cleartext passwords sent > over the network. We want to be able to manage that, so we will be > registering plaintext password in these registries. > I don't think anyone will come up with anything worse than that. >=20 > Finally, I think a lot of us have begun to question the value in > security review for codepoint assignment. Some security WGs care a lot; > some don't seem to care much at all. >=20 > 2) Why I prefer FCFS or at least would object strongly to expert > review. >=20 > If we're going to say we want expert review I want us to give expert > instructions at least good enough that I believe I could answer the > question of what registrations to approve if I were appointed the > expert. >=20 > I don't think we could come to consensus on those instructions very > easily. > In particular, I think it would be challenging for us to describe what > security protocols the protocol registry applies to and which ones it > does not. >=20 > I'm totally fine publishing this document knowing it will be used for > routing protocols but not knowing what beyond routing protocols it will > be used for. > If we do that FCFS makes a lot of sense. >=20 > So, my recommendation is that we keep our current registration policy. From david.black@emc.com Fri Aug 16 10:50:04 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 269D821F92B9; Fri, 16 Aug 2013 10:50:04 -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=[AWL=0.000, 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 ExS4MwCrFlK8; Fri, 16 Aug 2013 10:49:58 -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 626BC21F844D; Fri, 16 Aug 2013 10:49:57 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7GGVjBB013274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 12:31:46 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 16 Aug 2013 12:31:23 -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 r7GGVMQ7020802; Fri, 16 Aug 2013 12:31:23 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Fri, 16 Aug 2013 12:31:22 -0400 From: "Black, David" To: Sam Hartman Date: Fri, 16 Aug 2013 12:31:20 -0400 Thread-Topic: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 Thread-Index: Ac6ZJNjZjowH+sHwRJSBvO6n+kH4QABddLkA Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129C489279@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@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" , "General Area Review Team \(gen-art@ietf.org\)" , "Black, David" , "karp@ietf.org" Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 17:50:04 -0000 Sam, Thanks for taking another look at this. I think we're in good shape on the IPsec relationship concern, but I think key selection responsibility could use some more attention. [A] The new text on the IPsec relationship looks good - I'd suggest also adding a sentence to state that keys for IPsec pre-shared-key authenticatio= n are not appropriate for this key database. [C] The key selection responsibility was not clear to me from the draft - the intent/design stated in your message is fine (and having one key be returned is simpler, and probably more robust than handing multiple keys to different protocol implementations and hoping that they do something consistent): > I think we've discussed key selection in the WG and come to a different > conclusion. The key table selects the key. We expect peer, key ID, > protocol and interface to identify a unique key for an inbound packet. My confusion stems from section 3 starting out by stating that the key database is consulted "to find the key to use on an outgoing message" followed by several sentences that indicate that the consultation may result in multiple keys. That leads to a suggestion and a question. Suggestion:=20 Add a new paragraph at the start of Section 3 to make the functional responsibility clear: Key selection is the responsibility of the key database functionality; in all cases, the protocol requests a key, and the database returns one key or an indication that there is no matching key. When multiple keys match a protocol's request, the key database selects one as described further in this section. Question: What happens, when despite all the measures described in Section 3, multiple keys match a protocol's request? How does one ensure that the key databases at both ends of the security association return the same key? Thanks, --David > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, August 14, 2013 3:32 PM > To: Black, David > Cc: housley@vigilsec.com; tim.polk@nist.gov; Dacheng Zhang > (zhangdacheng@huawei.com); General Area Review Team (gen-art@ietf.org); > karp@ietf.org; ietf@ietf.org > Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 >=20 > >>>>> "Black," =3D=3D Black, David writes: >=20 >=20 > Black,> [A] Overall - I would like to see a paragraph added on how > Black,> this database conceptually relates to the IPsec Peer > Black,> Authorization Database (PAD) - see RFC 4301, section 4.4.3. >=20 > It doesn't. > not even a little bit. > It's not IPsec; it's not about what key management peers to interact > with. >=20 > It's conceptually similar to the Security Association Database (SAD). > In a discussion with Jari I agreed to propose text for a paragraph > describing how this interacts with IPsec. >=20 > If this conceptual database is used to manage to keys for a security > protocol that uses IPsec [RFC4301] security services, then the > interactions between this conceptual database and the IPsec > databases needs to be described by the protocol specification. > Typically such a protocol would insert entries into the Security > Association Database (SAD) when rows are inserted into the key table > and remove SAD entries when key table rows are removed. The > protocol specification needs to describe how the SAD entries are > constructed along with any other IPsec database entries that are > needed, including a description of how these entries are ordered > along with other IPsec database entries. The question of whether it > is desirable to use this conceptual database to manage protocols > that use IPsec security services is open and has not been evaluated. >=20 > Black,> [C] (Section 3) Where does key selection occur? I would > Black,> suggest that the database return all possible keys and let > Black,> the protocol figure out what to use. This is particularly > Black,> important for inbound traffic for obvious reasons. >=20 > I think we've discussed key selection in the WG and come to a different > conclusion. The key table selects the key. We expect peer, key ID, > protocol and interface to identify a unique key for an inbound packet. >=20 > So, I think the concern you raise is not a problem. > While there was not a specific thread discussing key selection or this > issue, there were multiple reviewers who provided comments on key > selection over the development of the document, and making a major > change at this point without a technical problem seems undesirable. > If I'm missing something and the inbound packet issue is a problem then > we need to discuss it. From carter@qosient.com Fri Aug 16 10:57:28 2013 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4242421F9FCA; Fri, 16 Aug 2013 10:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-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 2PzfUL3FHnV7; Fri, 16 Aug 2013 10:57:23 -0700 (PDT) Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0BD21F9D5F; Fri, 16 Aug 2013 10:57:23 -0700 (PDT) Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 242F32BD37; Fri, 16 Aug 2013 13:57:18 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_69F64EE4-81C0-425F-8C9E-CD3C38D0CCEC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carter Bullard In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C489288@MX15A.corp.emc.com> Date: Fri, 16 Aug 2013 13:57:17 -0400 Message-Id: <41E3D887-7FAD-47BA-AEBB-FF65F14F3F88@qosient.com> References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE7129C489288@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1508) Cc: "tim.polk@nist.gov" , "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" , Sam Hartman , "karp@ietf.org" Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 17:57:28 -0000 --Apple-Mail=_69F64EE4-81C0-425F-8C9E-CD3C38D0CCEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hey David, Having been down this path a number of times, I would like to suggest that one shouldn't attempt to qualify any algorithm, technique, method or approach that may be submitted to the registration process. By suggesting that the registry somehow contains only " good " strategies, without any consideration regarding a specific implementation, you're making a claim that is unsupportable. Bad implementations of " good " strategies can be worst than plaintext passwords =85 really. Let the user decide what mechanisms they want to use, based on their criteria. Clear text passwords used over a triple AES encrypted channel is not "by definition" a bad strategy. Theoretically, it could be abstracted as a two-factor system, which has its advantages, regardless of the perceived " strength ". Why not ?? Carter On Aug 16, 2013, at 1:00 PM, "Black, David" wrote: > Sam, >=20 > Thanks for picking this up. Unlike my other two concerns with this = draft, > I think we have a longer discussion ahead of us on this one. >=20 > Your summary of my concern is on the mark: >=20 >> David's main concern is that bad security will get registered. >=20 > I understand the response to be two-fold: >=20 > 1) It doesn't matter; the controlling registry for crypto algorithm = usage > is the protocol-specific registry, not the key table database = registry. >=20 > 2) The guidance for the Expert Reviewer will be very difficult to = write. >=20 > I'm not convinced by either of these, sorry. >=20 > I'm concerned that the two-registry subtlety in 1) will be lost on > implementers, especially because (as mentioned in the IESG thread), = this > key table database is likely to see use beyond routing protocols. = Among > other things, it's being proposed as a general mechanism for keying = RSVP, > not just RSVP-TE (I'm one of the co-chairs of the tsvwg WG that's > responsible for RSVP). That key table databases registry is also = likely > to be a place that designers of new protocols look to figure out what = to > use for security. >=20 > As for cleartext passwords: >=20 >> Also, some routing protocols are protected by cleartext passwords = sent >> over the network. We want to be able to manage that, so we will be >> registering plaintext password in these registries. >> I don't think anyone will come up with anything worse than that. >=20 > I read the first sentence in Section 2 of this draft as excluding > cleartext passwords: >=20 > The database is characterized as a table, where each row represents > a single long-lived symmetric cryptographic key. >=20 > If someone wants to argue that a cleartext password is a "long-lived > symmetric cryptographic key", I'll go break out the popcorn and watch > w/amusement :-). >=20 > Seriously, if the intention is to include cleartext passwords, then I > think some more rewriting is in order, and I would suggest checking > directly with the Security ADs before going there. >=20 > As for 2), the fact that it will be difficult (with which I agree) > doesn't imply that it isn't necessary or shouldn't be done. IMHO, we > really should be setting a bar that says that this sort of IETF > imprimatur of approval of a crypto algorithm actually means something. >=20 > I appreciate that FCFS provides an easier path forward, however I'm > reminded by analogy of something I learned from my grad school > software engineering professor: >=20 > I can make the code run arbitrarily fast ... > ... if it doesn't have to be correct. >=20 > I'm rather uncomfortable with this use of process expediency as a > rationale for avoiding a technical concern. >=20 > This may ultimately be an issue that the IESG needs to sort out, as = the > level of security for IETF protocols and concerns about "vanity = crypto"=20 > extend well beyond the karp WG, but discussion ought to start here. >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Sam Hartman [mailto:hartmans-ietfc@mit.edu] >> Sent: Wednesday, August 14, 2013 3:19 PM >> To: Black, David >> Cc: housley@vigilsec.com; tim.polk@nist.gov; Dacheng Zhang >> (zhangdacheng@huawei.com); General Area Review Team = (gen-art@ietf.org); >> karp@ietf.org; ietf@ietf.org >> Subject: Re: [karp] IANA policy for = draft-ietf-karp-crypto-key-table-08 >>=20 >>=20 >>=20 >> David, as we mentioned in the IESG thread, we seem to have dropped = the >> response to your comments about IANA actions. >>=20 >> WG: >> =46rom the genart review: >>=20 >> [9] I suggest Expert Review for the new IANA registries, not just >> First Come First Served, so that someone with a security "clue" can >> check that the proposed registrations are reasonable. >>=20 >>=20 >> Stephen has filed a related DISCUSS position. He's confused why we = need >> a registry for KDFs or algorithms. >> He argues that the protocols should already have such a registry. He >> argues that it would be non-sensical to register a value in this >> registry but not the protocol registry. >>=20 >> In a somewhat related discussion, multiple people have asked what the >> scope of this document is. Are we defining something for routing >> protocols? Any security protocol in the world? Something = in-between? >>=20 >>=20 >> IU'm going to make two responses: >>=20 >> 1) >> I think FCFS is not harmful for these registries. >>=20 >> David's main concern is that bad security will get registered. >>=20 >> I'll point out that these registries are not about what security you = can >> use with a routing protocol, but about what security you can = configure >> from a management standpoint. >> Registering rot13 or similarly questionable security here wouldn't = mean >> I could use it with a routing protocol, only that I could ask a = system >> to do so. If ROT13 was not actually in the security-specific = registries >> for the protocols in question there'd be no way to send a >> rot13-transformed message. >>=20 >> I think people wanting to use bad security in routing protocols will >> focus on specifying how to use the security for the protocols, and >> that's the appropriate place to do any gateway review. >> Yeah, I guess with FCFS it's possible someone could register here and >> then later realize they cannot get their md4 security approved in the >> actual protocol registry document. >>=20 >> That might be confusing but doesn't seem very harmful. >>=20 >> Also, some routing protocols are protected by cleartext passwords = sent >> over the network. We want to be able to manage that, so we will be >> registering plaintext password in these registries. >> I don't think anyone will come up with anything worse than that. >>=20 >> Finally, I think a lot of us have begun to question the value in >> security review for codepoint assignment. Some security WGs care a = lot; >> some don't seem to care much at all. >>=20 >> 2) Why I prefer FCFS or at least would object strongly to expert >> review. >>=20 >> If we're going to say we want expert review I want us to give expert >> instructions at least good enough that I believe I could answer the >> question of what registrations to approve if I were appointed the >> expert. >>=20 >> I don't think we could come to consensus on those instructions very >> easily. >> In particular, I think it would be challenging for us to describe = what >> security protocols the protocol registry applies to and which ones it >> does not. >>=20 >> I'm totally fine publishing this document knowing it will be used for >> routing protocols but not knowing what beyond routing protocols it = will >> be used for. >> If we do that FCFS makes a lot of sense. >>=20 >> So, my recommendation is that we keep our current registration = policy. >=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp >=20 --Apple-Mail=_69F64EE4-81C0-425F-8C9E-CD3C38D0CCEC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXZzCCBXAw ggRYoAMCAQICAQ8wDQYJKoZIhvcNAQEFBQAwTTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRUNBMRYwFAYDVQQDEw1FQ0EgUm9vdCBDQSAyMB4XDTExMDYw MTEzNDMzM1oXDTE3MDUzMDEzNDMzM1owcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292 ZXJubWVudDEMMAoGA1UECxMDRUNBMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVz MRUwEwYDVQQDEwxPUkMgRUNBIFNXIDQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM p/zFNAJfjYagDX701xRpK6QjRa7rhtR2U/CIE1pTSAR1BINfsYNHt2+bi0SH4SwZ61Xw9hMqCMBP y05JJpeerEz0xpDbkqDz2NDqBm02rwdcRFqOWQn8Of3ALJKopAF6ZSkeF1j7KFCKQlIntAIyJ/c+ THyZJJD0Ns4SUrmQmBsm3q0kEl06lT7MHLPTv5LXkB+5PayhAJUWEXq/iUEhLDBstTaD1NGOleIM sv3i1X01amB9GywN2v/kKlfGuGQpFAWi0QabC4hMfUjM217bGQS0/v1VV11zBpRlEEzH0zJgQQDX WQy+V7vRbLav2bK3oWwvNTJGhb2CWHah7FrlAgMBAAGjggI2MIICMjASBgNVHRMBAf8ECDAGAQH/ AgEAMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUQpz0um9t6TDXOtZG9LI07p3STyYwHwYDVR0j BBgwFoAU7eSH0CfEUOaEOvfM9+s6SfxSTiEwMwYDVR0gBCwwKjAMBgpghkgBZQMCAQwBMAwGCmCG SAFlAwIBDAIwDAYKYIZIAWUDAgEMAzCBwAYDVR0fBIG4MIG1MCygKqAohiZodHRwOi8vY3JsLmRp c2EubWlsL2NybC9FQ0FST09UQ0EyLmNybDCBhKCBgaB/hn1sZGFwOi8vY3JsLmdkcy5kaXNhLm1p bC9jbiUzZEVDQSUyMFJvb3QlMjBDQSUyMDIlMmNvdSUzZEVDQSUyY28lM2RVLlMuJTIwR292ZXJu bWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTCB0wYIKwYBBQUH AQEEgcYwgcMwOgYIKwYBBQUHMAKGLmh0dHA6Ly9jcmwuZGlzYS5taWwvaXNzdWVkdG8vRUNBUk9P VENBMl9JVC5wN2MwgYQGCCsGAQUFBzAChnhsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZEVD QSUyMFJvb3QlMjBDQSUyMDIlMmNvdSUzZEVDQSUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2Ml M2RVUz9jcm9zc0NlcnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBAIP4M608 IEZJdXBySeHjlgiTtsQTq9xo6icy9Fa/zaJag+SoGitVohk26JAX44c+WsTdOmjnqCROFMwRDz3O Qa5QBLt5+PGbsZhL+s1L4XLh6+961ALZxMi88jiIcR71uBnZqm3WnImmf0ebnK4N8N8ZJbQfncbj ZlOOPo5NuVhEi22Mq8LHZd6UMl9xdSVAcHBV0F+sEBPY6S8OwptTz7+XusknKSkVPthJEEYnpHpk pcBVe9HY2M421E8MSYeXZxuKvEjNMMRk2pkH8lOWU1uKsNCjHQYvK7GJtptFpc5aKbOIgI/jSrSr qjcybZreD76lb1vZ8lcbHsnG+k22CCAwggVwMIIEWKADAgECAgEPMA0GCSqGSIb3DQEBBQUAME0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0VDQTEWMBQG A1UEAxMNRUNBIFJvb3QgQ0EgMjAeFw0xMTA2MDExMzQzMzNaFw0xNzA1MzAxMzQzMzNaMHAxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0VDQTEiMCAGA1UE CxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEVMBMGA1UEAxMMT1JDIEVDQSBTVyA0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzKf8xTQCX42GoA1+9NcUaSukI0Wu64bUdlPwiBNa U0gEdQSDX7GDR7dvm4tEh+EsGetV8PYTKgjAT8tOSSaXnqxM9MaQ25Kg89jQ6gZtNq8HXERajlkJ /Dn9wCySqKQBemUpHhdY+yhQikJSJ7QCMif3Pkx8mSSQ9DbOElK5kJgbJt6tJBJdOpU+zByz07+S 15AfuT2soQCVFhF6v4lBISwwbLU2g9TRjpXiDLL94tV9NWpgfRssDdr/5CpXxrhkKRQFotEGmwuI TH1IzNte2xkEtP79VVddcwaUZRBMx9MyYEEA11kMvle70Wy2r9myt6FsLzUyRoW9glh2oexa5QID AQABo4ICNjCCAjIwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYE FEKc9Lpvbekw1zrWRvSyNO6d0k8mMB8GA1UdIwQYMBaAFO3kh9AnxFDmhDr3zPfrOkn8Uk4hMDMG A1UdIAQsMCowDAYKYIZIAWUDAgEMATAMBgpghkgBZQMCAQwCMAwGCmCGSAFlAwIBDAMwgcAGA1Ud HwSBuDCBtTAsoCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRUNBUk9PVENBMi5jcmwwgYSg gYGgf4Z9bGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2RFQ0ElMjBSb290JTIwQ0ElMjAyJTJj b3UlM2RFQ0ElMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdDtiaW5hcnkwgdMGCCsGAQUFBwEBBIHGMIHDMDoGCCsGAQUFBzAChi5odHRwOi8v Y3JsLmRpc2EubWlsL2lzc3VlZHRvL0VDQVJPT1RDQTJfSVQucDdjMIGEBggrBgEFBQcwAoZ4bGRh cDovL2NybC5nZHMuZGlzYS5taWwvY24lM2RFQ0ElMjBSb290JTIwQ0ElMjAyJTJjb3UlM2RFQ0El MmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y3Jvc3NDZXJ0aWZpY2F0ZVBhaXI7Ymlu YXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQCD+DOtPCBGSXVwcknh45YIk7bEE6vcaOonMvRWv82iWoPk qBorVaIZNuiQF+OHPlrE3Tpo56gkThTMEQ89zkGuUAS7efjxm7GYS/rNS+Fy4evvetQC2cTIvPI4 iHEe9bgZ2apt1pyJpn9Hm5yuDfDfGSW0H53G42ZTjj6OTblYRIttjKvCx2XelDJfcXUlQHBwVdBf rBAT2OkvDsKbU8+/l7rJJykpFT7YSRBGJ6R6ZKXAVXvR2NjONtRPDEmHl2cbirxIzTDEZNqZB/JT llNbirDQox0GLyuxibabRaXOWimziICP40q0q6o3Mm2a3g++pW9b2fJXGx7JxvpNtgggMIIGOTCC BSGgAwIBAgICMX0wDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRUNBMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 aWVzMRUwEwYDVQQDEwxPUkMgRUNBIFNXIDQwHhcNMTMwNDIzMjA1MDI5WhcNMTYwNDIyMjA1MDI5 WjCBhjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRUNB MQwwCgYDVQQLEwNPUkMxFDASBgNVBAsTC1FvU2llbnQgTExDMSswKQYDVQQDEyJCdWxsYXJkLldp bGxpYW0uQy5PUkMxMDAwMDM3MTAxLklEMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA uVgzvMTViFK3KLdCW8Ah9TtLt57dyDCaw2yroulxbhKpJVXv5lpLt/h0WFgYdOKOohJn9zA8ngRO 9BRocofISpQmLV/dqJg1a0zrTRHAxbQvJIihZ1/hIcC9/+iA/4ZEKUwVdcd619V70w6+wsh3UIQj DLJsB7Zrs2bAsEjaJ+SoBCrvNiSCpV6D/32/bV2B/gnZ/5a09jasJEIYGbKVVp9f/SVh8XV5DSSu ppsb7ZCaKnNgwGLeIpwS3iRa6FqAMJK6K07F5EYeltjXb006U5rwk00dvoqvww3vV/D9sgjeuNYj va0uKxJ3E8t7p493CG4bzs7SW6aRaFOe5XPANwIDAQABo4ICxDCCAsAwHwYDVR0jBBgwFoAUQpz0 um9t6TDXOtZG9LI07p3STyYwHQYDVR0OBBYEFC7uy3C6OCsNX5V3mBpvbPf/B4keMIIBIwYIKwYB BQUHAQEEggEVMIIBETAeBggrBgEFBQcwAYYSaHR0cDovL2V2YS5vcmMuY29tMDIGCCsGAQUFBzAC hiZodHRwOi8vZWNhLm9yYy5jb20vY2FDZXJ0cy9FQ0EtU1c0LnA3YzCBugYIKwYBBQUHMAKGga1s ZGFwOi8vZWNhLWRzLm9yYy5jb20vY24lM2RPUkMlMjBFQ0ElMjBTVyUyMDQlMmNvdSUzZENlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyUyY291JTNkRUNBJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50 JTJjYyUzZFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5LGNyb3NzQ2VydGlmaWNhdGVQYWlyO2JpbmFy eTAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0RBBYwFIESY2FydGVyQHFvc2llbnQuY29tMBcGA1UdIAQQ MA4wDAYKYIZIAWUDAgEMATCB8QYDVR0fBIHpMIHmMCugKaAnhiVodHRwOi8vZWNhLm9yYy5jb20v Q1JMcy9PUkNFQ0FTVzQuY3JsMIG2oIGzoIGwhoGtbGRhcDovL2VjYS1kcy5vcmMuY29tOjM4OS9j biUzRE9SQyUyMEVDQSUyMFNXJTIwNCUyQyUyMG91JTNEQ2VydGlmaWNhdGlvbiUyMEF1dGhvcml0 aWVzJTJDJTIwb3UlM0RFQ0ElMkMlMjBvJTNEVS5TLiUyMEdvdmVybm1lbnQlMkMlMjBjJTNEVVM/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkwGwYDVR0JBBQwEjAQBggrBgEFBQcJBDEE EwJVUzANBgkqhkiG9w0BAQUFAAOCAQEAHi35mJzjiIIok76AITqnPNaWmW8J6CQnss/fVgXpcfAJ OqM0UX6OEzc638AmGpTL5f3yI0b0daetLCEvOK/4v4Tw9HHTpfHRa1g64JoEDyNgAG/oCH2HDviP ybd1C1/2OZB969gUoxvd0VdhKFI3ZF/mCCmdv+CBbvTCFpBXkeDkglC9IUHotxu6n+ZqKzZTVn3v 2T+2IwW6Pn++i6Gyak9QBQAKPJWovOlO5y4fS5yjOEshZWCdmkKQOj48oorv09gOfNpFFR9KtlTh tpal1Lf+7c+XHXMKdrnRvYzYLqdklL27qAze4AiW1/Fj0IRfQ17YiylEE4F2BZSCcOLq0TCCBj4w ggUmoAMCAQICAjF+MA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0VDQTEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3Jp dGllczEVMBMGA1UEAxMMT1JDIEVDQSBTVyA0MB4XDTEzMDQyMzIwNTE1MloXDTE2MDQyMjIwNTE1 MlowgYsxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0VD QTEMMAoGA1UECxMDT1JDMRQwEgYDVQQLEwtRb1NpZW50IExMQzEwMC4GA1UEAxMnQnVsbGFyZC5X aWxsaWFtLkMuT1JDMTAwMDAzNzEwMS5FbmNyeXB0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA0KufbZ9gPXn75bWXHqJsr49YLh0gkRXxWIUg5pUWkpnbqlxKmaXu97U2syVtCThHzzMr 9jb93pGVe9qgqsgeaPmI6UN0NHWlPlkfMZfib4PSmp9gFxDxaTCXGtxBJs1HGR/XHd7d34P17RKv ucgajz1KkZgp8GMRj2qL1SZAQcZCRt5O4XxVIbl+BL3mKdEtSk24NUtTT9WjwVSHHoonZzsTBbkz 7gBcgP+a7vE/1W9KBAnn0RGtPeqCHz9PUFHhjYGzloKxD8lI4Y+UFX6n5uW56b80LsqV+1mfl5Dy FwfBegaO69dwtUzcqJ95doauexSFe22y7yU3v+7TcYarRwIDAQABo4ICxDCCAsAwHwYDVR0jBBgw FoAUQpz0um9t6TDXOtZG9LI07p3STyYwHQYDVR0OBBYEFEmIoE5Wahgjz6mivsXWwtbvptwGMIIB IwYIKwYBBQUHAQEEggEVMIIBETAeBggrBgEFBQcwAYYSaHR0cDovL2V2YS5vcmMuY29tMDIGCCsG AQUFBzAChiZodHRwOi8vZWNhLm9yYy5jb20vY2FDZXJ0cy9FQ0EtU1c0LnA3YzCBugYIKwYBBQUH MAKGga1sZGFwOi8vZWNhLWRzLm9yYy5jb20vY24lM2RPUkMlMjBFQ0ElMjBTVyUyMDQlMmNvdSUz ZENlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyUyY291JTNkRUNBJTJjbyUzZFUuUy4lMjBHb3Zl cm5tZW50JTJjYyUzZFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5LGNyb3NzQ2VydGlmaWNhdGVQYWly O2JpbmFyeTAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0RBBYwFIESY2FydGVyQHFvc2llbnQuY29tMBcG A1UdIAQQMA4wDAYKYIZIAWUDAgEMATCB8QYDVR0fBIHpMIHmMCugKaAnhiVodHRwOi8vZWNhLm9y Yy5jb20vQ1JMcy9PUkNFQ0FTVzQuY3JsMIG2oIGzoIGwhoGtbGRhcDovL2VjYS1kcy5vcmMuY29t OjM4OS9jbiUzRE9SQyUyMEVDQSUyMFNXJTIwNCUyQyUyMG91JTNEQ2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzJTJDJTIwb3UlM0RFQ0ElMkMlMjBvJTNEVS5TLiUyMEdvdmVybm1lbnQlMkMlMjBj JTNEVVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkwGwYDVR0JBBQwEjAQBggrBgEF BQcJBDEEEwJVUzANBgkqhkiG9w0BAQUFAAOCAQEAi8sBhl4hOnT1puxe0CiOKgkFfMybOPqCPjfi /Rm+OVZFk2uCFnTqZBePzqDjkH/SDdv8hZyLySDEoLbJuH8NzW2pHWP7+anW46Bxfpkm4WGf33S7 VorBXhZvwd3kktNzHiX2hEPZs/V4PGhlHMekqcq6TvKxKYWBix5bq0mcaelycj2mC9UTUm3SBwJm rp83IgUrJgI6Ow+6SQduYQX/KSFxyTXnr6XZzWTo/c6HOH1oG1TlLnX32l7ZlosBdBkK8IhYoWbB DnDehnii9X2jpFLAH3aPQ379m/kzP2rkIq1DZnNMRwL6Cl4QxNmQZbGCThh8iq3NG4A5pQqd94lf aDGCAxAwggMMAgEBMHYwcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRUNBMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVzMRUwEwYDVQQD EwxPUkMgRUNBIFNXIDQCAjF9MAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgxNjE3NTcxOFowIwYJKoZIhvcNAQkEMRYEFHPRhVdOtog8 qVXtCA7JNt+SFYaQMIGFBgkrBgEEAYI3EAQxeDB2MHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9V LlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0VDQTEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRo b3JpdGllczEVMBMGA1UEAxMMT1JDIEVDQSBTVyA0AgIxfjCBhwYLKoZIhvcNAQkQAgsxeKB2MHAx CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0VDQTEiMCAG A1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEVMBMGA1UEAxMMT1JDIEVDQSBTVyA0AgIx fjANBgkqhkiG9w0BAQEFAASCAQCkJiMfCeHBvlXePgsPshFc2dRpua9hvRHCk3GVnY7IAVnRxxe5 YLbyjEspXRhYqnmdB8pkwZasRVlku7Tbt3IgX/vXcFzFLZjnJgTv1ZcCIHcU0PcK12kfP6h5fijz EhpqfrE43mOILWM8m+aUE/pSsU7WS0T2IDa5kGs6qyIeTQofj7vIdEJDRiYwqeUq0/gYwqeTfiG1 tQQoLxypgkbJICcezOLhTZ6ObvSSn9UpP5DiCDjffS7jEzmbllQoOoL2ktacWy3LNB1cMcsOvXid GT5S0dksz4MgfYiH/y26rCJ+Su2GZGTAJKUIyY6gO6Sq3IyCrh9e0XPCrR1Ohro0AAAAAAAA --Apple-Mail=_69F64EE4-81C0-425F-8C9E-CD3C38D0CCEC-- From hartmans@mit.edu Fri Aug 16 11:01:00 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 36FA021F8C65; Fri, 16 Aug 2013 11:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 Kpb-CSxpnfLn; Fri, 16 Aug 2013 11:00:54 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3955511E817A; Fri, 16 Aug 2013 11:00:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E7FA72029E; Fri, 16 Aug 2013 13:59:33 -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 JS0HoaQLAGBV; Fri, 16 Aug 2013 13:59:32 -0400 (EDT) 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; Fri, 16 Aug 2013 13:59:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3890B8052F; Fri, 16 Aug 2013 14:00:47 -0400 (EDT) From: Sam Hartman To: "Black\, David" References: <8D3D17ACE214DC429325B2B98F3AE7129C489289@MX15A.corp.emc.com> Date: Fri, 16 Aug 2013 14:00:47 -0400 In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C489289@MX15A.corp.emc.com> (David Black's message of "Fri, 16 Aug 2013 13:02:35 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ietf@ietf.org" , "tim.polk@nist.gov" , "General Area Review Team \(gen-art@ietf.org\)" , Sam Hartman , "karp@ietf.org" Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 18:01:00 -0000 >>>>> "Black," == Black, David writes: Black,> done. IMHO, we really should be setting a bar that says Black,> that this sort of IETF imprimatur of approval of a crypto Black,> algorithm actually means something. Something got manged there. I agree that publishing a standards-track document should endorce the algorithm in question. I'm somewhat uncomfortable with that sort of bar for IANA registries in general, although I have supported it from time to time. (My discomfort with this has grown significantly since my time as an AD). I do not support that sort of bar for this registry. I think we understand each other, but disagree. The question now is whether you can gain sufficient support to show rough consensus for a change in the document or to show that while there was rough consensus behind the document in the KARP WG, there's a lack of consensus on handling this issue between KARP and some other significant segment of the IETF like the security area. From hartmans@mit.edu Fri Aug 16 11:02:35 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 4BD5011E81FF; Fri, 16 Aug 2013 11:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 2g8uESl0QDlu; Fri, 16 Aug 2013 11:02:35 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 13E4011E8165; Fri, 16 Aug 2013 11:02:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5E8AA202AC; Fri, 16 Aug 2013 14:01: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 TQ7nmKCcgc0z; Fri, 16 Aug 2013 14:01:19 -0400 (EDT) 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; Fri, 16 Aug 2013 14:01:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C99958052F; Fri, 16 Aug 2013 14:02:33 -0400 (EDT) From: Sam Hartman To: "Black\, David" In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C489289@MX15A.corp.emc.com> (David Black's message of "Fri, 16 Aug 2013 13:02:35 -0400") References: <8D3D17ACE214DC429325B2B98F3AE7129C489289@MX15A.corp.emc.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Fri, 16 Aug 2013 14:02:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ietf@ietf.org" , "tim.polk@nist.gov" , "General Area Review Team \(gen-art@ietf.org\)" , Sam Hartman , "karp@ietf.org" Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 18:02:35 -0000 >>>>> "Black," == Black, David writes: Black,> done. IMHO, we really should be setting a bar that says Black,> that this sort of IETF imprimatur of approval of a crypto Black,> algorithm actually means something. Something got manged there. I agree that publishing a standards-track document should endorce the algorithm in question. I'm somewhat uncomfortable with that sort of bar for IANA registries in general, although I have supported it from time to time. (My discomfort with this has grown significantly since my time as an AD). I do not support that sort of bar for this registry. I think we understand each other, but disagree. The question now is whether you can gain sufficient support to show rough consensus for a change in the document or to show that while there was rough consensus behind the document in the KARP WG, there's a lack of consensus on handling this issue between KARP and some other significant segment of the IETF like the security area. From jmh@joelhalpern.com Mon Aug 19 01:05:33 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 67AC411E8211 for ; Mon, 19 Aug 2013 01:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 JltGLGdmvIJZ for ; Mon, 19 Aug 2013 01:05:27 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8F811E820C for ; Mon, 19 Aug 2013 01:05:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8C63D1C0C53 for ; Mon, 19 Aug 2013 01:05:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1ABA61C0928 for ; Mon, 19 Aug 2013 01:05:26 -0700 (PDT) Message-ID: <5211D1C5.6010802@joelhalpern.com> Date: Mon, 19 Aug 2013 04:05:25 -0400 From: Joel Halpern User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "karp@ietf.org" References: <51F6173E.70007@joelhalpern.com> In-Reply-To: <51F6173E.70007@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [karp] Call for WG adoption: draft-mahesh-karp-rkmp-04 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, 19 Aug 2013 08:05:33 -0000 Although there was a little discussion on this for the first few days, there has been minimal comment since, and insufficient supportive comments for adopting. Based on the chairs' guess that there is support, we are extending the call for adoption by another week. If you would like to see this document adopted by the working group, please speak up. Thank you, Joel (and Brian) On 7/29/13 3:18 AM, Joel M. Halpern wrote: > This draft has been discussed in the WG, and revised based on WG > feedback and discussions among the authors. > At this point, the question is whether it is ready for the WG to > formally take the draft on and take it forward. > > So this is a call for adoption of > http://datatracker.ietf.org/doc/draft-mahesh-karp-rkmp/ > by the KARP WG. > Please respond to the list with support or substantive objections within > 3 weeks (adding a week since we are in the IETF meeting. > > Yours, > Joel M. Halpern From david.black@emc.com Mon Aug 19 06:08:55 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 0FD8111E827A; Mon, 19 Aug 2013 06:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 tUwSZBWAfM4E; Mon, 19 Aug 2013 06:08:47 -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 A8A0511E826F; Mon, 19 Aug 2013 06:08:26 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7JD80FS005380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 09:08:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 19 Aug 2013 09:07:48 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7JD7l9m025893; Mon, 19 Aug 2013 09:07:47 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Mon, 19 Aug 2013 09:07:47 -0400 From: "Black, David" To: Sam Hartman Date: Mon, 19 Aug 2013 09:07:46 -0400 Thread-Topic: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 Thread-Index: Ac6aqrVVQtelCuouRdyi7Cd0ThxhZgCMHC6g Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129C4893A1@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7129C489289@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" , "General Area Review Team \(gen-art@ietf.org\)" , "Black, David" , "karp@ietf.org" Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 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, 19 Aug 2013 13:08:55 -0000 > I'm somewhat uncomfortable with that sort of bar for IANA registries in > general, although I have supported it from time to time. (My discomfort > with this has grown significantly since my time as an AD). I do not > support that sort of bar for this registry. >=20 > I think we understand each other, but disagree. I believe that is the case (we understand each other, but disagree). > The question now is whether you can gain sufficient support to show > rough consensus for a change in the document or to show that while there > was rough consensus behind the document in the KARP WG, there's a lack > of consensus on handling this issue between KARP and some other > significant segment of the IETF like the security area. I will simply point to RFC 3365 ("Strong Security Requirements for Internet Engineering Task Force Standard Protocols") and suggest that it is relevant to determining what the registration procedure should be based on how this registry is likely to be used and as an example of reasons for the IESG to not follow the rough consensus of a WG. I believe that a discussion of how the registry is likely to be used in practice would be productive, although I am concerned about statements that weak password mechanisms are intended to be in scope, even though the draft (as I read it) excludes them, starting with the draft's title. Thanks, --David > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Friday, August 16, 2013 2:03 PM > To: Black, David > Cc: Sam Hartman; housley@vigilsec.com; tim.polk@nist.gov; Dacheng Zhang > (zhangdacheng@huawei.com); General Area Review Team (gen-art@ietf.org); > karp@ietf.org; ietf@ietf.org > Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 >=20 > >>>>> "Black," =3D=3D Black, David writes: >=20 > Black,> done. IMHO, we really should be setting a bar that says > Black,> that this sort of IETF imprimatur of approval of a crypto > Black,> algorithm actually means something. >=20 >=20 >=20 > Something got manged there. > I agree that publishing a standards-track document should endorce the > algorithm in question. >=20 > I'm somewhat uncomfortable with that sort of bar for IANA registries in > general, although I have supported it from time to time. (My discomfort > with this has grown significantly since my time as an AD). I do not > support that sort of bar for this registry. >=20 > I think we understand each other, but disagree. >=20 > The question now is whether you can gain sufficient support to show > rough consensus for a change in the document or to show that while there > was rough consensus behind the document in the KARP WG, there's a lack > of consensus on handling this issue between KARP and some other > significant segment of the IETF like the security area. From bew@cisco.com Thu Aug 22 15:32:20 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 D271011E81C7 for ; Thu, 22 Aug 2013 15:32:20 -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 D-s823bpK0WC for ; Thu, 22 Aug 2013 15:32:16 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 75EC711E8153 for ; Thu, 22 Aug 2013 15:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=270; q=dns/txt; s=iport; t=1377210736; x=1378420336; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=IyQPskqMYzi8lZ79cjNSKCu58Tzuho74URaeu9Lwnh4=; b=N2z2ZNfxILz3ggowhpPFASvpHhVL6gOgtw7gB9JddV3OPvOKt+d25bda ij40DyR+pFYNHaynFwF6whz8Vbx83yk5SmrAp9qRAmisvqUeoVnPquN+f aTGmDsR2iYam7LWNlJPs5xa06i01+mO8Am04qA40OY7mwOboBJaiJBh7E E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4KAHmQFlKrRDoI/2dsb2JhbABagwc1gyWpA5VSFnSCZYF9EwmIBg2VSaEzlAh7A4kujjiGKoswgz8c X-IronPort-AV: E=Sophos;i="4.89,937,1367971200"; d="scan'208";a="89796127" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 22 Aug 2013 22:32:13 +0000 Received: from [10.154.165.24] ([10.154.165.24]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7MMWChT018575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 22 Aug 2013 22:32:12 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2A1CA37F-380D-4382-B9AF-61FFE4A8E294@cisco.com> Date: Thu, 22 Aug 2013 15:32:13 -0700 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [karp] IETF 87 KARP WG Minutes 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, 22 Aug 2013 22:32:20 -0000 Greetings, The KARP WG minutes have been posted. Many thanks to Josh Howlett for = providing them. Corrections may be sent to the list or to the chairs = . Joel & Brian From internet-drafts@ietf.org Fri Aug 30 12:34:03 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 79C6A11E810E; Fri, 30 Aug 2013 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, 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 bX98utx3HMvc; Fri, 30 Aug 2013 12:34:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C111F11E80FA; Fri, 30 Aug 2013 12:34:02 -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.70.p1 Message-ID: <20130830193402.9797.45730.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2013 12:34:02 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-ops-model-08.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: Fri, 30 Aug 2013 19:34:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing Pro= tocols Working Group of the IETF. Title : Operations Model for Router Keying Author(s) : Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-ops-model-08.txt Pages : 25 Date : 2013-08-30 Abstract: Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the success of routing protocol security efforts. This document discusses issues and begins to consider development of these models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-ops-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-ops-model-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-ops-model-08 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/