From hartmans@mit.edu Mon Aug 1 07:21:19 2011 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 F081911E80DD for ; Mon, 1 Aug 2011 07:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.168 X-Spam-Level: X-Spam-Status: No, score=-104.168 tagged_above=-999 required=5 tests=[AWL=-1.903, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ThQLD4MtpEk for ; Mon, 1 Aug 2011 07:21:17 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3A69C11E80D8 for ; Mon, 1 Aug 2011 07:21:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 56DB2203B1; Mon, 1 Aug 2011 10:24:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 39A4F422B; Mon, 1 Aug 2011 10:21:14 -0400 (EDT) From: Sam Hartman To: Acee Lindem References: <287369F0-D8A2-44D3-9C17-BD1F32C64797@lindem.com> Date: Mon, 01 Aug 2011 10:21:14 -0400 In-Reply-To: <287369F0-D8A2-44D3-9C17-BD1F32C64797@lindem.com> (Acee Lindem's message of "Thu, 28 Jul 2011 19:12:06 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: karp@ietf.org Subject: Re: [karp] Mapping of OSPFv2 Key to "Database of Long-Lived Symmetric Cryptographic Keys" () - Resending with Tim's Email Address Corrected 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, 01 Aug 2011 14:21:19 -0000 I'm a bit confused. Virtual link packets are sent end-to-end, right? That is, I send the packet directly to the router that is the other side of the virtual link? If so, why would I need separate keys for separate virtual links between different endpoints? From acee.lindem@gmail.com Mon Aug 1 10:21:38 2011 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 8D13511E812C for ; Mon, 1 Aug 2011 10:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdsNGwim8WvY for ; Mon, 1 Aug 2011 10:21:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA9B911E8113 for ; Mon, 1 Aug 2011 10:21:37 -0700 (PDT) Received: by yxp4 with SMTP id 4so4104450yxp.31 for ; Mon, 01 Aug 2011 10:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3IzHSbsxOavM8QB00LaLgiX5FaIwuqzEEXoMLDrFGbw=; b=FWzgrarZs4uqgV4Q+bFrtCaE728kYVLCeGrcO3pQojCuGUXktHCVWxOfCQ/InSZKm5 Lnpb32HzkngzYA6LOmQC1n+ApsXpQHBtTkTgg4KD8VQJttG7h7wCa00d/Amw1xipa1J+ bnfZMjnPGGuOHit0cFpXk7Hef6bmzgKtnQrcQ= Received: by 10.146.30.26 with SMTP id d26mr3265993yad.25.1312219304392; Mon, 01 Aug 2011 10:21:44 -0700 (PDT) Received: from [192.168.1.106] (cpe-075-177-132-147.nc.res.rr.com [75.177.132.147]) by mx.google.com with ESMTPS id w1sm3879109yhi.23.2011.08.01.10.21.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 10:21:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Mon, 1 Aug 2011 13:21:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <287369F0-D8A2-44D3-9C17-BD1F32C64797@lindem.com> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: Acee Lindem , karp@ietf.org Subject: Re: [karp] Mapping of OSPFv2 Key to "Database of Long-Lived Symmetric Cryptographic Keys" () - Resending with Tim's Email Address Corrected 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, 01 Aug 2011 17:21:38 -0000 You are correct that it is the same pair of routers communicating. = However, you can have multiple virtual links through different transit = areas. Today, these can be the same or different keys/key chains.=20 I guess one could argue that they do not need to differ. However, we = allow different keys on different interfaces for unicast transmission = over non-virtual links given the key existing key database keys (or = should I call them indices to avoid confusion).=20 Acee=20 On Aug 1, 2011, at 10:21 AM, Sam Hartman wrote: >=20 > I'm a bit confused. > Virtual link packets are sent end-to-end, right? That is, I send the > packet directly to the router that is the other side of the virtual > link? >=20 > If so, why would I need separate keys for separate virtual links = between > different endpoints? From hartmans@mit.edu Mon Aug 1 10:36:26 2011 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 69C9411E8139 for ; Mon, 1 Aug 2011 10:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.079 X-Spam-Level: X-Spam-Status: No, score=-104.079 tagged_above=-999 required=5 tests=[AWL=-1.814, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlOqisxfSiUs for ; Mon, 1 Aug 2011 10:36:25 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 81BEB11E8137 for ; Mon, 1 Aug 2011 10:36:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A3DBC202B2; Mon, 1 Aug 2011 13:39:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 63984422B; Mon, 1 Aug 2011 13:36:27 -0400 (EDT) From: Sam Hartman To: Acee Lindem , housley@vigilsec.com, tim.polk@nist.gov References: <287369F0-D8A2-44D3-9C17-BD1F32C64797@lindem.com> Date: Mon, 01 Aug 2011 13:36:27 -0400 In-Reply-To: (Acee Lindem's message of "Mon, 1 Aug 2011 13:21:42 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Mapping of OSPFv2 Key to "Database of Long-Lived Symmetric Cryptographic Keys" () - Resending with Tim's Email Address Corrected 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, 01 Aug 2011 17:36:26 -0000 >>>>> "Acee" == Acee Lindem writes: Acee> You are correct that it is the same pair of routers Acee> communicating. However, you can have multiple virtual links Acee> through different transit areas. Today, these can be the same Acee> or different keys/key chains. I guess one could argue that Acee> they do not need to differ. However, we allow different keys Acee> on different interfaces for unicast transmission over Acee> non-virtual links given the key existing key database keys (or Acee> should I call them indices to avoid confusion). OK. so, we either need to accept these will be the same keys or we need to include some rather protocol-specific details in the key table. If you're using a per-peer keying strategy, then there's not a lot of reason to use different keys. If you're using a per-area keying strategy and using the same key across an area then I'm not sure how we should represent this in the crypto draft. Russ/Tim, do you have any thoughts? From hartmans@mit.edu Thu Aug 4 09:43:54 2011 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 7359A21F8AF7 for ; Thu, 4 Aug 2011 09:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.961 X-Spam-Level: X-Spam-Status: No, score=-103.961 tagged_above=-999 required=5 tests=[AWL=-1.696, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq5Kp9SPtgoo for ; Thu, 4 Aug 2011 09:43:54 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id EEEE321F8AF6 for ; Thu, 4 Aug 2011 09:43:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 31C02201C7 for ; Thu, 4 Aug 2011 12:46:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2EE934234; Thu, 4 Aug 2011 12:43:53 -0400 (EDT) From: Sam Hartman To: karp@ietf.org Date: Thu, 04 Aug 2011 12:43:53 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [karp] RSVP group keying draft on IESG agenda X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:43:54 -0000 I just noticed https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/ which I haven't seen discussed here. I haven't read the draft. I think this is close enough that it at least diserves a heads up on the karp mailing list. From jmh@joelhalpern.com Thu Aug 4 09:53:36 2011 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 CF98321F8BAC for ; Thu, 4 Aug 2011 09:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NZr2afJ+VxX for ; Thu, 4 Aug 2011 09:53:36 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 39BCD21F8BAB for ; Thu, 4 Aug 2011 09:53:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 8219B3245A99; Thu, 4 Aug 2011 09:53:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-185.clppva.btas.verizon.net [71.161.52.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 8AF673228963; Thu, 4 Aug 2011 09:53:48 -0700 (PDT) Message-ID: <4E3ACE98.60500@joelhalpern.com> Date: Thu, 04 Aug 2011 12:53:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsvwg-chairs@toosl.ietf.org, karp@ietf.org Subject: Re: [karp] RSVP group keying draft on IESG agenda X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:53:36 -0000 Thank you Sam. Yes, this deserves a heads up to KARP. Determining who should explicitly review what is a little more complex. Base RSVP is out of scope for KARP. It is in scope for TSVWG. On the other hand, RSVP-TE is in scope for both of us, and we are working on spinning up an RSVP-TE design team for the gap analysis work. Clearly, we will need to coordinate that work with TSVWG, and with this work item of theirs. yours, Joel On 8/4/2011 12:43 PM, Sam Hartman wrote: > > I just noticed > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/ > > which I haven't seen discussed here. > I haven't read the draft. > I think this is close enough that it at least diserves a heads up on the > karp mailing list. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From internet-drafts@ietf.org Thu Aug 4 17:38:03 2011 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 D2E8D11E809A; Thu, 4 Aug 2011 17:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LyIrxgj2Zqm; Thu, 4 Aug 2011 17:38:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774D511E807C; Thu, 4 Aug 2011 17:38:03 -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: 3.57 Message-ID: <20110805003803.8173.43787.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2011 17:38:03 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-design-guide-03.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, 05 Aug 2011 00:38:04 -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= Protocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (KARP) D= esign Guidelines Author(s) : Gregory M. Lebovitz Manav Bhatia Filename : draft-ietf-karp-design-guide-03.txt Pages : 28 Date : 2011-08-04 This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. = A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-design-guide-03.txt From bew@cisco.com Wed Aug 10 12:04:06 2011 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 4BEE211E807D for ; Wed, 10 Aug 2011 12:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-1.600, 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 o6Snh9RLliDd for ; Wed, 10 Aug 2011 12:04:05 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5F411E8078 for ; Wed, 10 Aug 2011 12:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=267; q=dns/txt; s=iport; t=1313003078; x=1314212678; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=KmSMX89JTgYSs0JJTFMmNOj+tNw7ACR7gzDDTMDeUvo=; b=ACTL5Yk2QrPhbpM7LUkE9G9gQpVjKc08It8kVSRrlEUbIJa9Uv7nv66m uejLRwqrEvQe6wCTucB0iq78XBcy/Mt0Xa8y2kQj/N9rRV59lXChuf08I OUjryv/oF+V+j21EGjgV4eaA5XKRHFzyyZiLDM2RDhJeXiQIZyvjV3CgI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEIABPWQk6rRDoH/2dsb2JhbABBmDWPAneBWQEnghAJGYdQnzOBIwGeWYVnXwSHXYsskQ0 X-IronPort-AV: E=Sophos;i="4.67,351,1309737600"; d="scan'208";a="11871329" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 10 Aug 2011 19:04:37 +0000 Received: from dhcp-128-107-108-28.cisco.com (dhcp-128-107-108-28.cisco.com [128.107.108.28]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7AJ4bKR020504 for ; Wed, 10 Aug 2011 19:04:37 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Aug 2011 12:04:37 -0700 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [karp] IETF81 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: Wed, 10 Aug 2011 19:04:06 -0000 Greetings, The KARP WG minutes have been posted. Many thanks to Richard Graveman = for providing them. Corrections may be sent to the list or to the chairs = . Brian & Joel From hartmans@mit.edu Wed Aug 10 14:28:34 2011 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 97F3711E807E for ; Wed, 10 Aug 2011 14:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.9 X-Spam-Level: X-Spam-Status: No, score=-103.9 tagged_above=-999 required=5 tests=[AWL=-1.635, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Rpnz-+V5c3od for ; Wed, 10 Aug 2011 14:28:34 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3191811E807D for ; Wed, 10 Aug 2011 14:28:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6947E2016B; Wed, 10 Aug 2011 17:31:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CF41242B6; Wed, 10 Aug 2011 17:28:44 -0400 (EDT) From: Sam Hartman To: Joel Halpern References: <4E30694F.4000202@joelhalpern.com> Date: Wed, 10 Aug 2011 17:28:44 -0400 In-Reply-To: <4E30694F.4000202@joelhalpern.com> (Joel Halpern's message of "Wed, 27 Jul 2011 15:38:55 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "karp@ietf.org" Subject: Re: [karp] Draft - PIM Gap Analysis - "extra license" X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:28:34 -0000 I certainly agree that the text regarding extra licenses as written should be removed. I do think that the availability of features within a market is properly an operational concern. For example if I proposed a solution to some CPE problem that involved having BGP software generally available in home/residential CPEs I think it would be entirely reasonable to point out that BGP implementations are not typically available in that market and doing so was a significant bar to operational deployment. It would not at all surprise me if there are operational implications of how vendors have chosen to implement various features that are 1) related to PIM security and 2) valid for us to discuss. I agree that the form of the current text is not appropriate for a WG document. From hartmans@mit.edu Mon Aug 15 10:25:33 2011 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 EDBBB21F8CAB; Mon, 15 Aug 2011 10:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.899 X-Spam-Level: X-Spam-Status: No, score=-103.899 tagged_above=-999 required=5 tests=[AWL=-1.634, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 t58oAqMT3bPq; Mon, 15 Aug 2011 10:25:32 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id F06C621F8C9E; Mon, 15 Aug 2011 10:25:31 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1BF3D2014E; Mon, 15 Aug 2011 13:28:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6355742B7; Mon, 15 Aug 2011 13:25:58 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org References: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2011 13:25:58 -0400 In-Reply-To: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> (The IESG's message of "Tue, 19 Jul 2011 07:57:39 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ospf@ietf.org, karp@ietf.org Subject: Re: [karp] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 17:25:33 -0000 Hi. I've reviewed the draft-ietf-ospf-auth-trailer-ospfv3-05 for consistency with draft-ietf-karp-ospf-analysis. KARP is chartered to figure out what improvements we need in routing protocol authenticationq. While draft-ietf-karp-ospf-analysis has not been approved by the WG, I think it's fairly close to our current thinking on what needs to be done to OSPF authentication. I believe we should either be consistent with that thinking or if during the discussion we discover that what we're doing in KARP is incorrect decide to update the KARP document. Based on this review I have a few recommendations for the OSPF v3 authentication trailers document. 1) The v3 authentication trailer takes a step back in the ability to rekey security associations both from OSPF v2, from IPsec for OSPF v3 and from draft-ietf-karp-crypto-tables. At the top of page 231 of RFC 2328, OSPF v2 security associations are defined with four lifetimes: KeyStartGenerate, KeyStartAccept, KeyStopGenerate and KeyStopAccept. Similarly, RFC 4301 defines a lifetime value for the SAs used by OSPFv3; in that case, whether an SA is an outbound or inbound SA controls whether it can be used for reception, generation or both at the current time. In the KARP crypto tables, lifetimes related to when packets can be sent are included: SAs are deleted from the crypto table to prevent reception. However the V3 auth trailer draft leaves this all up to implementation defined behavior. draft-ietf-karp-ospf-analysis indicates that we're going to remind people of the existing OSPF requirements for keylifetimes because they are necessary for key rollover. I believe that draft-ietf-ospf-auth-trailer-ospfv3-05 needs to be revised to require implementation behavior at least as flexible as draft-ietf-karp-crypto-tables. That is, associated with each security association is a time for when sending packets can start with a given SA and for when it must stop. Infinity and 0 should of course be supported for the appropriate times. 2) I notice terminology inconsistency between key identifier and security association identifier. This should probably be cleaned up, although it's not that big of a deal. 3) draft-ietf-ospf-analysis says that we are going to solve related protocol attacks. That is, we recognize that it's quite likely that some people will use the same preshared key both for OSPF authentication and for something else. We need to mix something into the key or hash or something that is unlikely to appear in any other use in order to make it cryptographically unlikely for the resulting OSPF authentication hash to be a hash useful in some other protocol or for the hash from some other protocol to be useful in OSPF. This draft does not do that. One possible way to solve this would be to prepend a constant in front of the key in the key preparation step or a constant in front of every packet that gets hashed. The constant should be the same for OSPFv3 and not used for any other purpose. From manav.bhatia@alcatel-lucent.com Wed Aug 24 07:38:39 2011 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 4BE0B21F8B52; Wed, 24 Aug 2011 07:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 AS0ulxgtOLwI; Wed, 24 Aug 2011 07:38:38 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 646C421F8B38; Wed, 24 Aug 2011 07:38:38 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7OEdiS3011695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Aug 2011 09:39:47 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7OEdgfA008082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 Aug 2011 20:09:43 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 24 Aug 2011 20:09:42 +0530 From: "Bhatia, Manav (Manav)" To: Sam Hartman , "ietf@ietf.org" Date: Wed, 24 Aug 2011 20:09:40 +0530 Thread-Topic: [karp] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard Thread-Index: AcxbcHckAhwFV117ToWRv88q2y5g9gG+iTTg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF9A5F02@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20110719145739.5942.53564.idtracker@ietfa.amsl.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-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [karp] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard 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, 24 Aug 2011 14:38:39 -0000 Hi, [clipped] >=20 > Based on this review I have a few recommendations for the=20 > OSPF v3 authentication trailers document. >=20 > 1) The v3 authentication trailer takes a step back in the=20 > ability to rekey security associations both from OSPF v2,=20 > from IPsec for OSPF v3 and from=20 [ ..] >=20 > I believe that draft-ietf-ospf-auth-trailer-ospfv3-05 needs=20 > to be revised to require implementation behavior at least as=20 > flexible as draft-ietf-karp-crypto-tables. That is,=20 > associated with each security association is a time for when=20 > sending packets can start with a given SA and for when it=20 > must stop. Infinity and 0 should of course be supported for=20 > the appropriate times. >=20 > 2) I notice terminology inconsistency between key identifier =20 > and security association identifier. This should probably be=20 > cleaned up, although it's not that big of a deal. http://tools.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-06.txt address= es the first two comments. >=20 >=20 > 3) draft-ietf-ospf-analysis says that we are going to solve=20 > related protocol attacks. That is, we recognize that it's=20 > quite likely that some people will use the same preshared key=20 > both for OSPF authentication and for something else. We need=20 > to mix something into the key or hash or something that is=20 > unlikely to appear in any other use in order to make it=20 > cryptographically unlikely for the resulting OSPF=20 > authentication hash to be a hash useful in some other=20 > protocol or for the hash from some other protocol to be=20 > useful in OSPF. This draft does not do that. One possible=20 > way to solve this would be to prepend a constant in front of=20 > the key in the key preparation step or a constant in front of=20 > every packet that gets hashed. The constant should be the=20 > same for OSPFv3 and not used for any other purpose. We had an offline discussion with Sam and others and we seem to have conver= ged at this text: We change the hex that's repeated in the Apad from 0x878FE1F3 to 0x878FE1F4= . This value will be unique for OSPFv3. Other protocols that use this mecha= nism must use a different value of Apad - you could think of this as "salti= ng" the Apad. OLD TEXT in Sec 4.4: Apad is a value which is the same length as the hash output or message dige= st. The first 16 octets contain the IPv6 source address followed by the he= xadecimal value 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets. NEW TEXT: Apad is a value which is the same length as the hash output or message dige= st. The first 16 octets contain the IPv6 source address followed by the he= xadecimal value 0x878FE1F4 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets. Cheers, Manav= From acee.lindem@ericsson.com Wed Aug 24 07:43:01 2011 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 7CB4E21F8B5D; Wed, 24 Aug 2011 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bVDuyFTPLHqF; Wed, 24 Aug 2011 07:43:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 89EC221F8B2D; Wed, 24 Aug 2011 07:43:00 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7OEi77H017867; Wed, 24 Aug 2011 09:44:08 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 24 Aug 2011 10:44:02 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Date: Wed, 24 Aug 2011 10:44:00 -0400 Thread-Topic: [OSPF] [karp] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard Thread-Index: AcxibEQOgTWOZ5r0QXe4QXW6KcTjhQ== Message-ID: <8D54DD3C-45C6-4C34-9CD3-DF6B6C758B4E@ericsson.com> References: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CFF9A5F02@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF9A5F02@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-120-882391960"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" , Sam Hartman , "ietf@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [OSPF] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard 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, 24 Aug 2011 14:43:01 -0000 --Apple-Mail-120-882391960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Manav,=20 On Aug 24, 2011, at 10:39 AM, Bhatia, Manav (Manav) wrote: > Hi, >=20 > [clipped] >=20 >>=20 >> Based on this review I have a few recommendations for the=20 >> OSPF v3 authentication trailers document. >>=20 >> 1) The v3 authentication trailer takes a step back in the=20 >> ability to rekey security associations both from OSPF v2,=20 >> from IPsec for OSPF v3 and from=20 >=20 > [ ..] >=20 >>=20 >> I believe that draft-ietf-ospf-auth-trailer-ospfv3-05 needs=20 >> to be revised to require implementation behavior at least as=20 >> flexible as draft-ietf-karp-crypto-tables. That is,=20 >> associated with each security association is a time for when=20 >> sending packets can start with a given SA and for when it=20 >> must stop. Infinity and 0 should of course be supported for=20 >> the appropriate times. >>=20 >> 2) I notice terminology inconsistency between key identifier =20 >> and security association identifier. This should probably be=20 >> cleaned up, although it's not that big of a deal. >=20 > http://tools.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-06.txt = addresses the first two comments. >=20 >>=20 >>=20 >> 3) draft-ietf-ospf-analysis says that we are going to solve=20 >> related protocol attacks. That is, we recognize that it's=20 >> quite likely that some people will use the same preshared key=20 >> both for OSPF authentication and for something else. We need=20 >> to mix something into the key or hash or something that is=20 >> unlikely to appear in any other use in order to make it=20 >> cryptographically unlikely for the resulting OSPF=20 >> authentication hash to be a hash useful in some other=20 >> protocol or for the hash from some other protocol to be=20 >> useful in OSPF. This draft does not do that. One possible=20 >> way to solve this would be to prepend a constant in front of=20 >> the key in the key preparation step or a constant in front of=20 >> every packet that gets hashed. The constant should be the=20 >> same for OSPFv3 and not used for any other purpose. >=20 > We had an offline discussion with Sam and others and we seem to have = converged at this text: >=20 > We change the hex that's repeated in the Apad from 0x878FE1F3 to = 0x878FE1F4. This value will be unique for OSPFv3. Other protocols that = use this mechanism must use a different value of Apad - you could think = of this as "salting" the Apad. Could we simply use the OSPFv3 protocol number, 89, in the Apad, e.g., = 0x898FE1F4, (or at least the first instance of Apad). Otherwise, we = probably need a registry for IANA Apads.=20 Thanks, Acee=20 >=20 > OLD TEXT in Sec 4.4: >=20 > Apad is a value which is the same length as the hash output or message = digest. The first 16 octets contain the IPv6 source address followed by = the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. > This implies that hash output is always a length of at least 16 = octets. >=20 > NEW TEXT: >=20 > Apad is a value which is the same length as the hash output or message = digest. The first 16 octets contain the IPv6 source address followed by = the hexadecimal value 0x878FE1F4 repeated (L-16)/4 times. > This implies that hash output is always a length of at least 16 = octets. >=20 > Cheers, Manav > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-120-882391960 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgyNDE0NDQwMVowIwYJKoZI hvcNAQkEMRYEFOagzsmIf0Tydwb7JRdtBHgoM/e3MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFxh8OIrOe6YEjdlhxG7Jh9ultvwLdAR+NpMMBdWyEqHhfZ4ULLPJ0pZGL6HBZrS GC5p/rmEDAErPwDx6SYbeOjpEhYoGAaFINyw+IyBlWpTsgUsPlXZ9PNKI7wAH2obj21oXMf1+Jp2 2ViEXQqyEd5c3UFJo99uCrO/PqAfsiT9AAAAAAAA --Apple-Mail-120-882391960-- From acee.lindem@ericsson.com Wed Aug 24 07:45:27 2011 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 B382621F8B6B; Wed, 24 Aug 2011 07:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 n1ctv8hj1CfB; Wed, 24 Aug 2011 07:45:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 117F421F8AD9; Wed, 24 Aug 2011 07:45:27 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7OEkFKK018477; Wed, 24 Aug 2011 09:46:33 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 24 Aug 2011 10:46:31 -0400 From: Acee Lindem To: Acee Lindem Date: Wed, 24 Aug 2011 10:46:31 -0400 Thread-Topic: [OSPF] [karp] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard Thread-Index: AcxibJ0W8exhPoa4TDCkVUgqhZqnuA== Message-ID: <1D4A7913-4FE3-4B9F-9D0D-9FBC5E12F56E@ericsson.com> References: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CFF9A5F02@INBANSXCHMBSA1.in.alcatel-lucent.com> <8D54DD3C-45C6-4C34-9CD3-DF6B6C758B4E@ericsson.com> In-Reply-To: <8D54DD3C-45C6-4C34-9CD3-DF6B6C758B4E@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-121-882542660"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Sam Hartman , "ospf@ietf.org" , "ietf@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [OSPF] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard 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, 24 Aug 2011 14:45:27 -0000 --Apple-Mail-121-882542660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 24, 2011, at 10:44 AM, Acee Lindem wrote: >=20 >=20 > Hi Manav,=20 >=20 > On Aug 24, 2011, at 10:39 AM, Bhatia, Manav (Manav) wrote: >=20 >> Hi, >>=20 >> [clipped] >>=20 >>>=20 >>> Based on this review I have a few recommendations for the=20 >>> OSPF v3 authentication trailers document. >>>=20 >>> 1) The v3 authentication trailer takes a step back in the=20 >>> ability to rekey security associations both from OSPF v2,=20 >>> from IPsec for OSPF v3 and from=20 >>=20 >> [ ..] >>=20 >>>=20 >>> I believe that draft-ietf-ospf-auth-trailer-ospfv3-05 needs=20 >>> to be revised to require implementation behavior at least as=20 >>> flexible as draft-ietf-karp-crypto-tables. That is,=20 >>> associated with each security association is a time for when=20 >>> sending packets can start with a given SA and for when it=20 >>> must stop. Infinity and 0 should of course be supported for=20 >>> the appropriate times. >>>=20 >>> 2) I notice terminology inconsistency between key identifier =20 >>> and security association identifier. This should probably be=20 >>> cleaned up, although it's not that big of a deal. >>=20 >> http://tools.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-06.txt = addresses the first two comments. >>=20 >>>=20 >>>=20 >>> 3) draft-ietf-ospf-analysis says that we are going to solve=20 >>> related protocol attacks. That is, we recognize that it's=20 >>> quite likely that some people will use the same preshared key=20 >>> both for OSPF authentication and for something else. We need=20 >>> to mix something into the key or hash or something that is=20 >>> unlikely to appear in any other use in order to make it=20 >>> cryptographically unlikely for the resulting OSPF=20 >>> authentication hash to be a hash useful in some other=20 >>> protocol or for the hash from some other protocol to be=20 >>> useful in OSPF. This draft does not do that. One possible=20 >>> way to solve this would be to prepend a constant in front of=20 >>> the key in the key preparation step or a constant in front of=20 >>> every packet that gets hashed. The constant should be the=20 >>> same for OSPFv3 and not used for any other purpose. >>=20 >> We had an offline discussion with Sam and others and we seem to have = converged at this text: >>=20 >> We change the hex that's repeated in the Apad from 0x878FE1F3 to = 0x878FE1F4. This value will be unique for OSPFv3. Other protocols that = use this mechanism must use a different value of Apad - you could think = of this as "salting" the Apad. >=20 > Could we simply use the OSPFv3 protocol number, 89, in the Apad, e.g., = 0x898FE1F4, (or at least the first instance of Apad). Otherwise, we = probably need a registry for IANA Apads.=20 I meant 0x898FE1F3 as to not change the last 3 octets of the existing = HMAC-SHAx Apad.=20 Thanks, Acee=20 >=20 > Thanks, > Acee=20 >=20 >=20 >>=20 >> OLD TEXT in Sec 4.4: >>=20 >> Apad is a value which is the same length as the hash output or = message digest. The first 16 octets contain the IPv6 source address = followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. >> This implies that hash output is always a length of at least 16 = octets. >>=20 >> NEW TEXT: >>=20 >> Apad is a value which is the same length as the hash output or = message digest. The first 16 octets contain the IPv6 source address = followed by the hexadecimal value 0x878FE1F4 repeated (L-16)/4 times. >> This implies that hash output is always a length of at least 16 = octets. >>=20 >> Cheers, Manav >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >=20 --Apple-Mail-121-882542660 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgyNDE0NDYzMlowIwYJKoZI hvcNAQkEMRYEFH9BW6Cw3iAeOyDw3Yb4yFoxDamTMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgBiclg0zq7RirLCErjLzunMZp7eZ2Six6yyGXQgG5MOEWnMJduiAcs9bMD3giIne 0kaKra4wDlgkujmgawVzHpHgoZx8BojxSFyE9+K5jjYmvqtq6xUSKM2uf1cS2+0F1vFTkCfFtax4 4+q2CJ2ALxEsACgoBJtMwnmcTEKdOGchAAAAAAAA --Apple-Mail-121-882542660-- From manav.bhatia@alcatel-lucent.com Wed Aug 24 07:50:07 2011 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 296D221F8BAB; Wed, 24 Aug 2011 07:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 M52X7HeBlzNF; Wed, 24 Aug 2011 07:50:06 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEA821F8B8A; Wed, 24 Aug 2011 07:50:06 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7OEpAri021455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Aug 2011 09:51:13 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7OEp9dF030370 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 Aug 2011 20:21:09 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 24 Aug 2011 20:21:09 +0530 From: "Bhatia, Manav (Manav)" To: Acee Lindem Date: Wed, 24 Aug 2011 20:21:08 +0530 Thread-Topic: [OSPF] [karp] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard Thread-Index: AcxibJ0W8exhPoa4TDCkVUgqhZqnuAAAC72A Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF9A5F06@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CFF9A5F02@INBANSXCHMBSA1.in.alcatel-lucent.com> <8D54DD3C-45C6-4C34-9CD3-DF6B6C758B4E@ericsson.com> <1D4A7913-4FE3-4B9F-9D0D-9FBC5E12F56E@ericsson.com> In-Reply-To: <1D4A7913-4FE3-4B9F-9D0D-9FBC5E12F56E@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" , Sam Hartman , "ietf@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [OSPF] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard 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, 24 Aug 2011 14:50:07 -0000 Hi Acee, > >>=20 > >> We change the hex that's repeated in the Apad from=20 > 0x878FE1F3 to 0x878FE1F4. This value will be unique for=20 > OSPFv3. Other protocols that use this mechanism must use a=20 > different value of Apad - you could think of this as=20 > "salting" the Apad. > >=20 > > Could we simply use the OSPFv3 protocol number, 89, in the=20 > Apad, e.g., 0x898FE1F4, (or at least the first instance of=20 > Apad). Otherwise, we probably need a registry for IANA Apads.=20 >=20 > I meant 0x898FE1F3 as to not change the last 3 octets of the=20 > existing HMAC-SHAx Apad.=20 We would still need an IANA registry of Apads unless youre thinking of usin= g the IP protocol type as the first octet of the Apad. If it's the latter, = then OSPFv3 and OSPFv2 would share the same Apad, which would defeat the pu= rpose of the whole exercise. This would also not work for multiple protocols that ride over UDP and TCP.= BFD and RIP would end up using the same Apad as their IP protocol is the s= ame.=20 We thus need a unique Apad that each standard can define if we want to prot= ect ourselves from the attack that Sam describes. Cheers, Manav=20 From acee.lindem@ericsson.com Wed Aug 24 09:04:42 2011 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 805EE21F8C29; Wed, 24 Aug 2011 09:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 AC9ChJ3r0pe1; Wed, 24 Aug 2011 09:04:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E1DE821F8C37; Wed, 24 Aug 2011 09:04:41 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7OG5iFK004500; Wed, 24 Aug 2011 11:05:49 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 24 Aug 2011 12:05:44 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Date: Wed, 24 Aug 2011 12:05:42 -0400 Thread-Topic: [OSPF] [karp] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard Thread-Index: Acxid626BeUAPPcnQ2m798unkem+VQ== Message-ID: <0E0AC0D0-0E8C-4CAE-8FDA-75D1AA4672D6@ericsson.com> References: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CFF9A5F02@INBANSXCHMBSA1.in.alcatel-lucent.com> <8D54DD3C-45C6-4C34-9CD3-DF6B6C758B4E@ericsson.com> <1D4A7913-4FE3-4B9F-9D0D-9FBC5E12F56E@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFF9A5F06@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFF9A5F06@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-122-887293861"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" , Sam Hartman , "ietf@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [OSPF] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard 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, 24 Aug 2011 16:04:42 -0000 --Apple-Mail-122-887293861 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Manav, On Aug 24, 2011, at 10:51 AM, Bhatia, Manav (Manav) wrote: > Hi Acee, >=20 >>>>=20 >>>> We change the hex that's repeated in the Apad from=20 >> 0x878FE1F3 to 0x878FE1F4. This value will be unique for=20 >> OSPFv3. Other protocols that use this mechanism must use a=20 >> different value of Apad - you could think of this as=20 >> "salting" the Apad. >>>=20 >>> Could we simply use the OSPFv3 protocol number, 89, in the=20 >> Apad, e.g., 0x898FE1F4, (or at least the first instance of=20 >> Apad). Otherwise, we probably need a registry for IANA Apads.=20 >>=20 >> I meant 0x898FE1F3 as to not change the last 3 octets of the=20 >> existing HMAC-SHAx Apad.=20 >=20 > We would still need an IANA registry of Apads unless youre thinking of = using the IP protocol type as the first octet of the Apad. That's exactly what I'm proposing.=20 > If it's the latter, then OSPFv3 and OSPFv2 would share the same Apad, = which would defeat the purpose of the whole exercise. Are you forgetting about the version as the first nibble of the header?=20= >=20 > This would also not work for multiple protocols that ride over UDP and = TCP. BFD and RIP would end up using the same Apad as their IP protocol = is the same.=20 UDP/TCP protocols would need a scheme that includes their well-know port = - perhaps, the second octet of the first instance of Apad ;^).=20 >=20 > We thus need a unique Apad that each standard can define if we want to = protect ourselves from the attack that Sam describes. Thanks, Acee >=20 > Cheers, Manav=20 --Apple-Mail-122-887293861 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgyNDE2MDU0M1owIwYJKoZI hvcNAQkEMRYEFOpRujaGcdfL0WArkk6oG5jwuoLqMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgB2cY+2KWiyaYGZsTDcuqeClGCQs4v5oTyN97fW9P+R4jIY7pOxLoN5qDyf5LQS5 GMIFSobD/6TNX1UgPgFO8bg4WhynxDg4H5Y4G6WwyyyyOtOlPZZeJ1zh4TIy/Nccs+/RpuEKoed0 xkYazsBbsBbSyG3uLoZP0ZPFbAQL3FM6AAAAAAAA --Apple-Mail-122-887293861-- From acee.lindem@ericsson.com Wed Aug 24 09:09:21 2011 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 2A1EC21F8C57; Wed, 24 Aug 2011 09:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zwq9tDk8zzfY; Wed, 24 Aug 2011 09:09:20 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8680821F8C51; Wed, 24 Aug 2011 09:09:20 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7OGARCB005591; Wed, 24 Aug 2011 11:10:30 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 24 Aug 2011 12:10:25 -0400 From: Acee Lindem To: Acee Lindem Date: Wed, 24 Aug 2011 12:10:22 -0400 Thread-Topic: [OSPF] [karp] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard Thread-Index: AcxieFTIhqaGR7zJSAawjNNO3iN7kQ== Message-ID: <3D1FB5AD-C17E-4071-B20A-5F9B8B2044EA@ericsson.com> References: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> <7C362EEF9C7896468B36C9B79200D8350CFF9A5F02@INBANSXCHMBSA1.in.alcatel-lucent.com> <8D54DD3C-45C6-4C34-9CD3-DF6B6C758B4E@ericsson.com> <1D4A7913-4FE3-4B9F-9D0D-9FBC5E12F56E@ericsson.com> <7C362EEF9C7896468B36C9B79200D8350CFF9A5F06@INBANSXCHMBSA1.in.alcatel-lucent.com> <0E0AC0D0-0E8C-4CAE-8FDA-75D1AA4672D6@ericsson.com> In-Reply-To: <0E0AC0D0-0E8C-4CAE-8FDA-75D1AA4672D6@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-123-887573852"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Sam Hartman , "ospf@ietf.org" , "ietf@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [OSPF] Last Call: (Supporting Authentication Trailer for OSPFv3) to Proposed Standard 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, 24 Aug 2011 16:09:21 -0000 --Apple-Mail-123-887573852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 24, 2011, at 12:05 PM, Acee Lindem wrote: > Hi Manav, >=20 > On Aug 24, 2011, at 10:51 AM, Bhatia, Manav (Manav) wrote: >=20 >> Hi Acee, >>=20 >>>>>=20 >>>>> We change the hex that's repeated in the Apad from=20 >>> 0x878FE1F3 to 0x878FE1F4. This value will be unique for=20 >>> OSPFv3. Other protocols that use this mechanism must use a=20 >>> different value of Apad - you could think of this as=20 >>> "salting" the Apad. >>>>=20 >>>> Could we simply use the OSPFv3 protocol number, 89, in the=20 >>> Apad, e.g., 0x898FE1F4, (or at least the first instance of=20 >>> Apad). Otherwise, we probably need a registry for IANA Apads.=20 >>>=20 >>> I meant 0x898FE1F3 as to not change the last 3 octets of the=20 >>> existing HMAC-SHAx Apad.=20 >>=20 >> We would still need an IANA registry of Apads unless youre thinking = of using the IP protocol type as the first octet of the Apad. >=20 > That's exactly what I'm proposing.=20 >=20 >> If it's the latter, then OSPFv3 and OSPFv2 would share the same Apad, = which would defeat the purpose of the whole exercise. >=20 > Are you forgetting about the version as the first nibble of the = header?=20 Meant the first byte of course - first nibble is for IPv4 vs IPv6 ;^)=20 >=20 >>=20 >> This would also not work for multiple protocols that ride over UDP = and TCP. BFD and RIP would end up using the same Apad as their IP = protocol is the same.=20 >=20 > UDP/TCP protocols would need a scheme that includes their well-know = port - perhaps, the second octet of the first instance of Apad ;^).=20 >=20 >>=20 >> We thus need a unique Apad that each standard can define if we want = to protect ourselves from the attack that Sam describes. >=20 > Thanks, > Acee >=20 >=20 >>=20 >> Cheers, Manav=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-123-887573852 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDgyNDE2MTAyM1owIwYJKoZI hvcNAQkEMRYEFCUqDwi7Yo7Z5jEYg0t/8/94IChDMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgH/OIfOzxr7yz1+wmoWTaSr/nux5vB8brXVB+0LH7dBLmJsTSw0ULOs8EIHrcaMu cP6dVAAutILAFrwc6MdbnPf1cPlHV+7oOCKcuxWAk7pf6S8RZN0tjOGtVOQLtdmS+Jqvb4/hg7/v cqoIA23pdehAwwt/hyBG81agE56Fd3iAAAAAAAAA --Apple-Mail-123-887573852-- From internet-drafts@ietf.org Wed Aug 24 19:47:09 2011 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 1F95921F8B67; Wed, 24 Aug 2011 19:47:09 -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 AgEFo95Q6sXb; Wed, 24 Aug 2011 19:47:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB95821F86B3; Wed, 24 Aug 2011 19:47:08 -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: 3.59 Message-ID: <20110825024708.24556.67304.idtracker@ietfa.amsl.com> Date: Wed, 24 Aug 2011 19:47:08 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-ospf-analysis-02.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: Thu, 25 Aug 2011 02:47:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Analysis of OSPF Security According to KARP Design Guide Author(s) : Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-ospf-analysis-02.txt Pages : 11 Date : 2011-08-24 This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-ospf-analysis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-ospf-analysis-02.txt