From jmh@joelhalpern.com Fri Apr 1 00:41:25 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41EF928C104 for ; Fri, 1 Apr 2011 00:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-IlktUIUHdB for ; Fri, 1 Apr 2011 00:41:24 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 3FB363A6BEC for ; Fri, 1 Apr 2011 00:41:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B1CB04300E5 for ; Fri, 1 Apr 2011 00:43:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [130.129.38.181] (dhcp-26b5.meeting.ietf.org [130.129.38.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 4617C4300E1 for ; Fri, 1 Apr 2011 00:43:04 -0700 (PDT) Message-ID: <4D958203.7030607@joelhalpern.com> Date: Fri, 01 Apr 2011 03:42:59 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Framework document X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 07:41:25 -0000 During the WG session, Sam and Gregory in the jabber room suggested moving the document to parked state. Later on, we can revisit and see if there is value in RFC publication. This seems a good idea. Does anyone object? Thank you, Joel From gregory.ietf@gmail.com Fri Apr 1 01:17:09 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD08A3A6B0B for ; Fri, 1 Apr 2011 01:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.515 X-Spam-Level: X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjOab9tL3Rg2 for ; Fri, 1 Apr 2011 01:17:08 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BA7CB3A6AF8 for ; Fri, 1 Apr 2011 01:17:08 -0700 (PDT) Received: by iwn39 with SMTP id 39so3761027iwn.31 for ; Fri, 01 Apr 2011 01:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Fv6Q7hEiAeVgOoBKB4M7znoRLhDaP795hJFC4Q2e2BE=; b=tOBHN7YbXaQQKLdh5kfXh1BB/nGgZdmVaOgLiWRK24XumxTIQ9IGz07Qyiu8MSGYBa 862QLZ5DExCrh9dzYKV8lsKYtWjQmrKEdlAkHbO60tm6U51sjM8tD6Uqe+n/Zzs0q8yQ jplWJWv/f7ixXj2YjJiaPJI/46esQv98I4EDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LuvnvHWzhI4WNEU86xMK3MbdAnKGCLuWUPHyQCM8/zP48oMP4R5oWtZjJLY8iFP+5K Qb2s/ZSbhburWJ/Vp6M44iWDJlu6NULVnbJli++MH9iRjRi1TijRITSMZHIlKU/F6JYs OOsFeZVNRE4OhFHFUK2GDYws2G/aR6v+8Vp6E= MIME-Version: 1.0 Received: by 10.231.55.90 with SMTP id t26mr2314086ibg.116.1301645928913; Fri, 01 Apr 2011 01:18:48 -0700 (PDT) Received: by 10.231.66.18 with HTTP; Fri, 1 Apr 2011 01:18:48 -0700 (PDT) In-Reply-To: <4D958203.7030607@joelhalpern.com> References: <4D958203.7030607@joelhalpern.com> Date: Fri, 1 Apr 2011 01:18:48 -0700 Message-ID: From: Gregory Lebovitz To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=000e0cd5f0d4375cb5049fd70f4d Cc: "karp@ietf.org" Subject: Re: [karp] Framework document X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 08:17:09 -0000 --000e0cd5f0d4375cb5049fd70f4d Content-Type: text/plain; charset=ISO-8859-1 No objection. That works for me. In conjunction, could we please document here, on list, why it is that the AD's and WG Chairs have decided to park the framework at present? As I was reviewing Design-guide and -mrkmp I found it problematic more than just a few times that we didn't have a framework overview that we've agreed upon from which to reflect comments. I know we wanted to actually try some different things out, like mrkmp for example, to see if indeed we could actually separate the KMP from the routing protocols before we hard-coded such a thing into the framework. But I think we still need an active doc that captures "last thinking of record" and where we can update from lessons learned in our trials and errors. For this reason I think it should be active. Can others please explain why it shouldn't be? Then can we come to WG consensus on it? Specifically, our charter currently calls for a Framework document. The decision to not do one == decision to change our charter. This is fine, as long as we have WG consensus on it after a healthy discussion. No? Gregory On Fri, Apr 1, 2011 at 12:42 AM, Joel M. Halpern wrote: > During the WG session, Sam and Gregory in the jabber room suggested moving > the document to parked state. Later on, we can revisit and see if there is > value in RFC publication. > > This seems a good idea. > Does anyone object? > > Thank you, > Joel > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000e0cd5f0d4375cb5049fd70f4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No objection. That works for me.

In conjunction, could w= e please document here, on list, why it is that the AD's and WG Chairs = have decided to park the framework at present?

As I was reviewing Design-guide and -mrkmp I found it problematic more than= just a few times that we didn't have a framework overview that we'= ve agreed upon from which to reflect comments.=A0

I know we wanted to actually try some different things out, like mrkmp for = example, to see if indeed we could actually separate the KMP from the routi= ng protocols before we hard-coded such a thing into the framework. But I th= ink we still need an active doc that captures "last thinking of record= " and where we can update from lessons learned in our trials and error= s. For this reason I think it should be active.

Can others please explain why it shouldn't be? Then= can we come to WG consensus on it?

Specifically, = our charter currently calls for a Framework document. The decision to not d= o one =3D=3D decision to change our charter. This is fine, as long as we ha= ve WG consensus on it after a healthy discussion. No?

Gregory



On Fri, Apr 1, 2011 at 12:42 AM, Joel M. Halpern <jmh@joelhalpern.com>= wrote:
During the WG session, Sam and Gregory in t= he jabber room suggested moving the document to parked state. =A0Later on, = we can revisit and see if there is value in RFC publication.

This seems a good idea.
Does anyone object?

Thank you,
Joel
_______________________________________________
karp mailing list
karp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/karp



--
----
IETF related em= ail from
Gregory M. Lebovitz
Juniper Networks
--000e0cd5f0d4375cb5049fd70f4d-- From manav.bhatia@alcatel-lucent.com Sun Apr 3 14:33:16 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570F23A689A for ; Sun, 3 Apr 2011 14:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.706 X-Spam-Level: X-Spam-Status: No, score=-6.706 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjE9MDEobpVn for ; Sun, 3 Apr 2011 14:33:15 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1A62F3A6882 for ; Sun, 3 Apr 2011 14:33:14 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p33LYlbP018719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 Apr 2011 16:34:49 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p33LYkLZ022991 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Apr 2011 03:04:46 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 4 Apr 2011 03:04:46 +0530 From: "Bhatia, Manav (Manav)" To: Mach Chen , zhenglianshu 50128 Date: Mon, 4 Apr 2011 03:04:45 +0530 Thread-Topic: draft-zheng-mpls-ldp-hello-crypto-auth Thread-Index: AcvyRvNE/utLFXVtS6uugSbqzrtpdg== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.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.37 Cc: "karp@ietf.org" Subject: [karp] draft-zheng-mpls-ldp-hello-crypto-auth X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 21:33:16 -0000 Hi, The current version of draft-zheng-mpls-ldp-hello-crypto-auth does not cont= ain any cryptographic sequence numbers and I spoke to Mach and Vero about t= his in Prague. It seems that they were told that replay attacks are not con= sidered a big deal for LDP. While I can concede that replay attacks are a t= rifle more difficult for LDP deployments (mostly service providers environm= ent) I am not comfortable in developing a solution that precludes the possi= bility of us ever supporting this. Given this I would like to suggest the following change in the draft: We either define a new 4 byte field for crypto-sequence numbers that the im= plementations MAY chose to ignore or define two Auth types where one contai= ns this field and the other doesn't. Also I just noticed that the TLV defines Auth Type which indicates the kind= of algo being used. I think this is redundant and I see no need for this g= iven that we are already carrying a Key ID. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From dharkins@lounge.org Sun Apr 3 15:20:44 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E293A68C0 for ; Sun, 3 Apr 2011 15:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6U9pNJkplXo for ; Sun, 3 Apr 2011 15:20:42 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id AE95E3A68B6 for ; Sun, 3 Apr 2011 15:20:42 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AB80B1022400A for ; Sun, 3 Apr 2011 15:22:24 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 3 Apr 2011 15:22:24 -0700 (PDT) Message-ID: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> Date: Sun, 3 Apr 2011 15:22:24 -0700 (PDT) From: "Dan Harkins" To: "karp@ietf.org" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [karp] just use IKE(v2) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 22:20:44 -0000 Hello, During the karp meeting on Friday I brought up the issue of using IKE(v2) as a key management protocol for karp or rolling-our-own. Based on comments I received after the meeting it is apparent I explained myself poorly. Let me try again. I think it is important to explore rolling-our-own key management protocol that is customized to the task at hand. The WG may eventually decide not to go that route, and to just use IKE(v2), but I think we should weigh the pluses and minuses of both before we start saying things like, "oh well we're just gonna use IKE(v2)" (and a thousand pardons up front if I'm mischaracterizing anyone with that statement). The way I see it is, we could use IKEv1 and define another DOI, or we could graft on a DOI concept on to IKEv2 and use that. The former seems correct since that's what the DOI was for, but people want to discourage the proliferation of IKEv1. The latter uses IKEv2 (which pleases the people discouraged by the proliferation of IKEv1) but adds on a complication that was intentionally left off the rev of IKE. And both of those have a security issue that would be exploited by their expected use. Today operators configure a shared key on their routers to use for securing BGP traffic. They are comfortable with that UI and would probably resist complications in their lives. So it would make sense to use a key management solution in karp that didn't have a security problem when used with a pre-shared key. Neither IKEv1 nor IKEv2 qualify in that regard, they are both susceptible to dictionary attack. IPsecme tried to come up with a single standardized solution to that problem but the result is 3 competing ones. Even picking one of those means that the IKEv2 exchange has grown from 4 messages to 6. And it, effectively, doubles the public key crypto operations. That's might be a price the WG is willing to pay. The WG might even decide that the security issue with pre-shared keys in IKE(v2) isn't worth addressing. But here's another possibility. It's possible to implement a protocol that accomplishes authentication, key agreement, and key confirmation (important characteristics of any key management protocol), using only a pre-shared key, and to do it in just 3 messages, with less crypto operations than is done in IKE today. What's more, this protocol would be resistant to dictionary attack. The EKE patent expires in a few months so it's possible to have a solution free of IPR worries, with some finessing of the Diffie-Hellman groups. It's also possible to use an unpatented protocol whose IPR situation is a little more questionable (it's what Donald Rumsfeld referred to as "the known unknowns and the unknown unknowns"), that could use any of the Diffie-Hellman groups defined in IKE today (both EC and MODP). That seems compelling to me. We give the operators the same comfortable UI they've come to expect but insert robust, misuse resistant, and provably secure cryptography underneath. Or we can just use IKE(v2). But it would be nice to discuss the possibilities before we get too far down one path (which it seemed like we were doing last Friday). regards, Dan. From Internet-Drafts@ietf.org Wed Apr 6 11:00:06 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91AA28C110; Wed, 6 Apr 2011 11:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5+vJxecHGcv; Wed, 6 Apr 2011 11:00:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D11528C119; Wed, 6 Apr 2011 11:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.15 Message-ID: <20110406180002.5691.95866.idtracker@localhost> Date: Wed, 06 Apr 2011 11:00:02 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action:draft-ietf-karp-ops-model-00.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 18:00:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Keying and Authentication for Routing Protocols Working Group of the IETF. Title : Operations Model for Router Keying Author(s) : S. Hartman, D. Zhang Filename : draft-ietf-karp-ops-model-00.txt Pages : 22 Date : 2011-04-06 Developing an operational and management model for routing protocol security that works across protocols will be critical to the success of routing protocol security efforts. This document discusses issues and begins to consider development of these models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-ops-model-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-karp-ops-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-06104627.I-D@ietf.org> --NextPart-- From hartmans@mit.edu Wed Apr 6 12:16:41 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2483A67E6 for ; Wed, 6 Apr 2011 12:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.819 X-Spam-Level: X-Spam-Status: No, score=-102.819 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYFK3w5B8h0y for ; Wed, 6 Apr 2011 12:16:41 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 327AF3A63EB for ; Wed, 6 Apr 2011 12:16:41 -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 A98A820340; Wed, 6 Apr 2011 15:15:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F0D00446E; Wed, 6 Apr 2011 15:18:21 -0400 (EDT) From: Sam Hartman To: "Dan Harkins" References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> Date: Wed, 06 Apr 2011 15:18:21 -0400 In-Reply-To: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> (Dan Harkins's message of "Sun, 3 Apr 2011 15:22:24 -0700 (PDT)") 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: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:16:41 -0000 Dan brings up an interesting question. >From an operational standpoint is it acceptable for us to use assume that the preshared keys we have are reasonably strong? I hope the answer is that we can assume they are sufficiently strong. Doing so has significant simplicity assumptions. IN particular, we avoid having to deal with the password authenticated key exchange problem, which has crippled multiple working groups ability to make forward progress on an issue. Examples include SACRED, IPSECME, and I believe others. I think that the levels of security provided by SCRAM, Kerberos, and other mechanisms that have not encountered significant process problems will be adequate, particularly protected by a DH exchange. What this means is that an active attacker can potentially mount a dictionary attack. There are a *lot* of real world systems that have made the security decision that risk is acceptable. I think we should join the crowd. If a PAKE solution should suddenly appear that has broad support in the IETF, we can pick it up. I do not think we need to bite off unnecessary tasks that multiple WGs have failed at: we have enough of a challenge already. I consider PAKE a really nice to have, not a necessary requirement. From hartmans@mit.edu Wed Apr 6 12:21:59 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507DB3A67E6 for ; Wed, 6 Apr 2011 12:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5-caYWP5cyu for ; Wed, 6 Apr 2011 12:21:56 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id A99C83A63EB for ; Wed, 6 Apr 2011 12:21:56 -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 2FCBE203A1; Wed, 6 Apr 2011 15:20:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 762FA446E; Wed, 6 Apr 2011 15:23:39 -0400 (EDT) From: Sam Hartman To: "Dan Harkins" References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> Date: Wed, 06 Apr 2011 15:23:39 -0400 In-Reply-To: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> (Dan Harkins's message of "Sun, 3 Apr 2011 15:22:24 -0700 (PDT)") 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: [karp] OUr own KMP based on IKEv2 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:21:59 -0000 Dan, I think I correctly understood what you were proposing. I'm not sure I'm proposing the same thing or not. I think we should start from IKEv2. I do not believe that we should formally build in a DOI concept into IKEv2. Instead, I think we should take IKEv2, copy it and evolve semi-independently to form a KMP that meets our needs. So, I'm proposing rolling our on, but I'm proposing that we not start completely from scratch. My suspicion is that we will have a relatively small number of differences between our protocol and IKEv2, similar in quantity and complexity to the small number of differences between TLS and DTLS. The source of these differences will be different: rather than differences between UDP and TCP it will be differences caused by domain. so, I suspect it will be possible that we can allow future extensions to IKEv2 to equally apply to our protocol. For example, we can allow PAKE messages for IKEv2 to be used if we should choose. However, I do not propose to introduce the DOI concept into IKEv2. I do not support using IKEv1 at all. IKEv2 seems like a much cleaner protocol. I'd much rather be working on it than IKEv2. I find reasoning about IKEv1 more challenging, even though in some sense it has more abstractions. These are my thoughts. I will be very interested to hear from others. From hartmans@mit.edu Wed Apr 6 12:24:07 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3603A697B for ; Wed, 6 Apr 2011 12:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaPzvnWGe2E2 for ; Wed, 6 Apr 2011 12:24:01 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id EDD843A6973 for ; Wed, 6 Apr 2011 12:24:00 -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 4EFB020340; Wed, 6 Apr 2011 15:22:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9ACE1446E; Wed, 6 Apr 2011 15:25:43 -0400 (EDT) From: Sam Hartman To: "Bhatia\, Manav \(Manav\)" References: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 06 Apr 2011 15:25:43 -0400 In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.com> (Manav Bhatia's message of "Mon, 4 Apr 2011 03:04:45 +0530") 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: Mach Chen , "karp@ietf.org" Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:24:08 -0000 I agree that draft would be improved by sequence numbers. Will the boot count mechanism work or is freshness an issue? In particular, is one LDP hello enough, or is there a non-trivial state machine? From turners@ieca.com Wed Apr 6 12:30:24 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0BD3A6978 for ; Wed, 6 Apr 2011 12:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKRFp2i76TCe for ; Wed, 6 Apr 2011 12:30:04 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by core3.amsl.com (Postfix) with SMTP id 803163A67E6 for ; Wed, 6 Apr 2011 12:30:01 -0700 (PDT) Received: from [98.139.212.150] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 06 Apr 2011 19:31:41 -0000 Received: from [98.139.212.227] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 06 Apr 2011 19:31:36 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 06 Apr 2011 19:31:36 -0000 X-Yahoo-Newman-Id: 107987.73371.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 9519 invoked from network); 6 Apr 2011 19:31:35 -0000 Received: from thunderfish.local (turners@96.231.120.227 with plain) by smtp102.biz.mail.bf1.yahoo.com with SMTP; 06 Apr 2011 12:31:35 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 4FKU7hAVM1lEB9pZu7y_sVyZUoFRkNBMlg.esqdnJ0nNElI GBpzfmF7kfc_NQlZiAB7k3S0IByK.srKXKcQXFenCTHGCFrP617zP88odXXr LUOnUEFrt82RucBrC.plBoN_JXRc1ZDH__racSvfuXhLsjkG3bLWrMjArAgC fOWizA6pemhhx7oHe_im2E0bHMkVZjab4snp2cktE51yDrx7PwuG5ISdAQie qkOi_GcwxWvOAHrSUD27XS.2hpaCZjC7WTXD5.fJUAl.D6gQ7Wh2dtm__48k 9BjX.sOxACKsd4mdEv4G0g6caTvMFDFhKl8mRDUZ1K1ITfDktJFigWrfXBBc 5zATGa6Y0XOrHswCPGBDd4g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D9CBF97.7030104@ieca.com> Date: Wed, 06 Apr 2011 15:31:35 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Sam Hartman References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "karp@ietf.org" Subject: Re: [karp] OUr own KMP based on IKEv2 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:30:24 -0000 On 4/6/11 3:23 PM, Sam Hartman wrote: snip.. > However, I do not propose to introduce the DOI concept into IKEv2. Somebody has introduced the concept of GDOI into IKEv2: https://datatracker.ietf.org/doc/draft-yeung-g-ikev2/ > I do not support using IKEv1 at all. IKEv2 seems like a much cleaner > protocol. I'd much rather be working on it than IKEv2. I find reasoning > about IKEv1 more challenging, even though in some sense it has more > abstractions. IKEv1 is obsolete and any references to it will cause all kinds of procedural problems. > These are my thoughts. > I will be very interested to hear from others. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From hartmans@mit.edu Wed Apr 6 12:49:30 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D643A697A for ; Wed, 6 Apr 2011 12:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.789 X-Spam-Level: X-Spam-Status: No, score=-102.789 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FqQRTElT0YX for ; Wed, 6 Apr 2011 12:49:30 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 1A4F63A67DA for ; Wed, 6 Apr 2011 12:49:29 -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 6823320384; Wed, 6 Apr 2011 15:47:58 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AB992446E; Wed, 6 Apr 2011 15:51:12 -0400 (EDT) From: Sam Hartman To: Sean Turner References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <4D9CBF97.7030104@ieca.com> Date: Wed, 06 Apr 2011 15:51:12 -0400 In-Reply-To: <4D9CBF97.7030104@ieca.com> (Sean Turner's message of "Wed, 06 Apr 2011 15:31:35 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] OUr own KMP based on IKEv2 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:49:30 -0000 >>>>> "Sean" == Sean Turner writes: Sean> On 4/6/11 3:23 PM, Sam Hartman wrote: Sean> snip.. >> However, I do not propose to introduce the DOI concept into >> IKEv2. Sean> Somebody has introduced the concept of GDOI into IKEv2: Sean> https://datatracker.ietf.org/doc/draft-yeung-g-ikev2/ That draft seems to accomplish adding multicast IPsec to IKEv2. That to me doesn't sound like a new DOI or a DOI concept. (The fact that the protocol has DOI in its name not withstanding.) The authors may have intended--I can't really tell--to do something that could key groups that were not IPsec groups. I don't have confidence they succeeded: there seem to be a lot of IPsec-specific assumptions scattered throughout the draft. This is definitely an interesting draft to track, especially for those of us working on multicast keying for KARP. It doesn't seem though that it really adds the DOI concept from IKEv1 in all its formality to IKEv2. From housley@vigilsec.com Wed Apr 6 13:41:00 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D3B3A69B9 for ; Wed, 6 Apr 2011 13:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk+pCoCPHb8q for ; Wed, 6 Apr 2011 13:40:59 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 976D03A67A3 for ; Wed, 6 Apr 2011 13:40:59 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B2EAD9A47C5; Wed, 6 Apr 2011 16:43:02 -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 LrBE0E7rnk0r; Wed, 6 Apr 2011 16:42:28 -0400 (EDT) Received: from [192.168.2.101] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id EEE889A47BA; Wed, 6 Apr 2011 16:42:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Wed, 6 Apr 2011 16:42:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <12822385-43B4-4A2D-9E44-C7E3EE5FAB98@vigilsec.com> References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> To: Sam Hartman X-Mailer: Apple Mail (2.1082) Cc: karp@ietf.org Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 20:41:00 -0000 I think we need to focus on incremental improvement. Today, there is = essentially no way to roll from one key to the next. If we can provide = this capability, then there will be an incentive to use strong keys. = Today, there is no such incentive. So, let's assume that strong keys = will be used once a simple roll-over capability is available. Russ On Apr 6, 2011, at 3:18 PM, Sam Hartman wrote: >=20 > Dan brings up an interesting question. >=20 > =46rom an operational standpoint is it acceptable for us to use assume > that the preshared keys we have are reasonably strong? >=20 > I hope the answer is that we can assume they are sufficiently > strong. Doing so has significant simplicity assumptions. IN = particular, > we avoid having to deal with the password authenticated key exchange > problem, which has crippled multiple working groups ability to make > forward progress on an issue. Examples include SACRED, IPSECME, and I > believe others. >=20 > I think that the levels of security provided by SCRAM, Kerberos, and > other mechanisms that have not encountered significant process = problems > will be adequate, particularly protected by a DH exchange. >=20 > What this means is that an active attacker can potentially mount a > dictionary attack. > There are a *lot* of real world systems that have made the security > decision that risk is acceptable. > I think we should join the crowd. >=20 > If a PAKE solution should suddenly appear that has broad support in = the > IETF, we can pick it up. > I do not think we need to bite off unnecessary tasks that multiple WGs > have failed at: we have enough of a challenge already. >=20 > I consider PAKE a really nice to have, not a necessary requirement. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From dharkins@lounge.org Wed Apr 6 14:40:15 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CED3A67D3 for ; Wed, 6 Apr 2011 14:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYP8OiW0lw3I for ; Wed, 6 Apr 2011 14:40:14 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 7C6933A67A8 for ; Wed, 6 Apr 2011 14:40:14 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6AC4710224064; Wed, 6 Apr 2011 14:41:58 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 6 Apr 2011 14:41:58 -0700 (PDT) Message-ID: <699b533716142ba8626985ad650a376c.squirrel@www.trepanning.net> In-Reply-To: <12822385-43B4-4A2D-9E44-C7E3EE5FAB98@vigilsec.com> References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <12822385-43B4-4A2D-9E44-C7E3EE5FAB98@vigilsec.com> Date: Wed, 6 Apr 2011 14:41:58 -0700 (PDT) From: "Dan Harkins" To: "Russ Housley" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 21:40:15 -0000 Hi Russ, On Wed, April 6, 2011 1:42 pm, Russ Housley wrote: > I think we need to focus on incremental improvement. Today, there is > essentially no way to roll from one key to the next. If we can provide > this capability, then there will be an incentive to use strong keys. > Today, there is no such incentive. So, let's assume that strong keys will > be used once a simple roll-over capability is available. I'm not following this at all. One would think that if there was a way to seemlessly roll from one key to the next that a given key would be less "strong", since it's not gonna last very long and will soon be rolled out in exchange for the next. I think the only way we can reasonably answer that question is to look into how the first key is provisioned. If it's Joe from ISP A calling Fred from ISP B on the phone and saying, "enter w-3-8-g-capital-P-x-..." then I think the answer is "probably not." Such a technique is error prone if the pre-shared key is too "strong". Hi Sam, > On Apr 6, 2011, at 3:18 PM, Sam Hartman wrote: > >> >> Dan brings up an interesting question. >> >> From an operational standpoint is it acceptable for us to use assume >> that the preshared keys we have are reasonably strong? >> >> I hope the answer is that we can assume they are sufficiently >> strong. Doing so has significant simplicity assumptions. IN particular, >> we avoid having to deal with the password authenticated key exchange >> problem, which has crippled multiple working groups ability to make >> forward progress on an issue. Examples include SACRED, IPSECME, and I >> believe others. The EKE patent is expiring in a couple of months so the reasons for the failure of SACRED should not apply. The failure of PAKE in IPsecme was due to the WG leadership and I don't believe we'll have any of those problems here. >> I think that the levels of security provided by SCRAM, Kerberos, and >> other mechanisms that have not encountered significant process problems >> will be adequate, particularly protected by a DH exchange. >> >> What this means is that an active attacker can potentially mount a >> dictionary attack. >> There are a *lot* of real world systems that have made the security >> decision that risk is acceptable. >> I think we should join the crowd. Following the crowd is a horrible reason to do anything. >> If a PAKE solution should suddenly appear that has broad support in the >> IETF, we can pick it up. >> I do not think we need to bite off unnecessary tasks that multiple WGs >> have failed at: we have enough of a challenge already. >> >> I consider PAKE a really nice to have, not a necessary requirement. Like I said, the EKE patent is expiring in a couple of months. The broad support that's needed is here in KARP. regards, Dan. From manav.bhatia@alcatel-lucent.com Wed Apr 6 15:08:17 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA2B3A697F for ; Wed, 6 Apr 2011 15:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.701 X-Spam-Level: X-Spam-Status: No, score=-6.701 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cRVFS+7g6R4 for ; Wed, 6 Apr 2011 15:08:16 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B699A3A67EA for ; Wed, 6 Apr 2011 15:08:16 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p36M9raQ007603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 17:09:56 -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 p36M9qOB015046 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Apr 2011 03:39:52 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 7 Apr 2011 03:39:52 +0530 From: "Bhatia, Manav (Manav)" To: Sam Hartman Date: Thu, 7 Apr 2011 03:39:49 +0530 Thread-Topic: [karp] draft-zheng-mpls-ldp-hello-crypto-auth Thread-Index: Acv0kHB3x+5rE4JSTDGHY2VduK0HDgAFsyVA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0371A1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.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.37 Cc: Mach Chen , "karp@ietf.org" Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 22:08:17 -0000 The boot count is applicable here as well as LDP is also susceptible to int= er-session replay attacks. Cheers, Manav=20 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Thursday, April 07, 2011 12.56 AM > To: Bhatia, Manav (Manav) > Cc: Mach Chen; zhenglianshu 50128; karp@ietf.org > Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth >=20 > I agree that draft would be improved by sequence numbers. >=20 > Will the boot count mechanism work or is freshness an issue? > In particular, is one LDP hello enough, or is there a=20 > non-trivial state > machine? > = From hartmans@mit.edu Wed Apr 6 15:10:12 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7F328C0E7 for ; Wed, 6 Apr 2011 15:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4xzFoh6vsc3 for ; Wed, 6 Apr 2011 15:10:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 7C7D328C0D0 for ; Wed, 6 Apr 2011 15:10:11 -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 2DC0C20265; Wed, 6 Apr 2011 18:08:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5A51B446E; Wed, 6 Apr 2011 18:11:52 -0400 (EDT) From: Sam Hartman To: "Bhatia\, Manav \(Manav\)" References: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0371A1@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 06 Apr 2011 18:11:52 -0400 In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0371A1@INBANSXCHMBSA1.in.alcatel-lucent.com> (Manav Bhatia's message of "Thu, 7 Apr 2011 03:39:49 +0530") 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: Mach Chen , Sam Hartman , "karp@ietf.org" Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 22:10:13 -0000 >>>>> "Bhatia," == Bhatia, Manav (Manav) writes: Bhatia,> The boot count is applicable here as well as LDP is also Bhatia,> susceptible to inter-session replay attacks. Cheers, Manav No, my question was whether the boot count will work? What does the LDP state machine look like? Are you sure a full replay wouldn't be useful? From manav.bhatia@alcatel-lucent.com Wed Apr 6 15:18:21 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20533A695E for ; Wed, 6 Apr 2011 15:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.7 X-Spam-Level: X-Spam-Status: No, score=-6.7 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9lgHh5QkU6K for ; Wed, 6 Apr 2011 15:18:21 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 107263A67E9 for ; Wed, 6 Apr 2011 15:18:21 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p36MJXgL015284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 17:19:36 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p36MJXIf008942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Apr 2011 03:49:33 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 7 Apr 2011 03:49:32 +0530 From: "Bhatia, Manav (Manav)" To: Sam Hartman Date: Thu, 7 Apr 2011 03:49:34 +0530 Thread-Topic: [karp] draft-zheng-mpls-ldp-hello-crypto-auth Thread-Index: Acv0p6W1TRZSN4pNQLSVWrG1yxe7lgAAJsYA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0371A5@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0371A1@INBANSXCHMBSA1.in.alcatel-lucent.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.33 Cc: Mach Chen , "karp@ietf.org" Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 22:18:21 -0000 Oh, Ok I get it now. I think we can bring up an entire session with the rep= lays which means we may have to mandate freshness if we really want to avoi= d the inter-session attacks. The router whose packets are replayed will pla= y the passive role when establishing a session.=20 Cheers, Manav > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Thursday, April 07, 2011 3.42 AM > To: Bhatia, Manav (Manav) > Cc: Sam Hartman; Mach Chen; zhenglianshu 50128; karp@ietf.org > Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth >=20 > >>>>> "Bhatia," =3D=3D Bhatia, Manav (Manav)=20 > writes: >=20 > Bhatia,> The boot count is applicable here as well as LDP is also > Bhatia,> susceptible to inter-session replay attacks. =20 > Cheers, Manav >=20 > No, my question was whether the boot count will work? >=20 > What does the LDP state machine look like? > Are you sure a full replay wouldn't be useful? > = From bew@cisco.com Wed Apr 6 17:27:18 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21253A6934 for ; Wed, 6 Apr 2011 17:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1w5da1shQ2d for ; Wed, 6 Apr 2011 17:27:17 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id ECB803A69A1 for ; Wed, 6 Apr 2011 17:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=2032; q=dns/txt; s=iport; t=1302136141; x=1303345741; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TgzWmL5Og0PtSzllD5LyFeMZlrI4FdSVFFDNVgQfA8M=; b=U/VugMBdYnTuVcTON1ClCPKOunJ90EkusNli+QH+/LXBRfX6C5lanAUR D1nc0HNwk0qdy+fhtUgW4OkQvGjogFz8VFicVhHFg83IreioQpSC9RTSz yOmytD1YTUFG92Z/JHmDBCpg8iVqxYngDE6HCn5Fqu2zjTTzOu+4GUPBp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPEEnU2rRDoH/2dsb2JhbACmAHeIeZ4rnHGFbASFTodvjQI X-IronPort-AV: E=Sophos;i="4.63,313,1299456000"; d="scan'208";a="425240343" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 07 Apr 2011 00:29:01 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p370T1mV030698; Thu, 7 Apr 2011 00:29:01 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Wed, 6 Apr 2011 17:29:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48D133C1-95B2-4BBC-A5B7-F339CB0A2A41@cisco.com> References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <4D9CBF97.7030104@ieca.com> To: Sam Hartman X-Mailer: Apple Mail (2.1082) Cc: karp@ietf.org Subject: Re: [karp] OUr own KMP based on IKEv2 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 00:27:18 -0000 On Apr 6, 2011, at 12:51 PM, Sam Hartman wrote: >>>>>> "Sean" =3D=3D Sean Turner writes: >=20 > Sean> On 4/6/11 3:23 PM, Sam Hartman wrote: > Sean> snip.. >=20 >>> However, I do not propose to introduce the DOI concept into >>> IKEv2. >=20 > Sean> Somebody has introduced the concept of GDOI into IKEv2: >=20 > Sean> https://datatracker.ietf.org/doc/draft-yeung-g-ikev2/ >=20 > That draft seems to accomplish adding multicast IPsec to IKEv2. That = to > me doesn't sound like a new DOI or a DOI concept. (The fact that the > protocol has DOI in its name not withstanding.) Actually, the G-IKEv2 protocol noted above doesn't have DOI in it's name = ... it's titled "Group Key Management using IKEv2".=20 >=20 > The authors may have intended--I can't really tell--to do something = that > could key groups that were not IPsec groups. > I don't have confidence they succeeded: there seem to be a lot of > IPsec-specific assumptions scattered throughout the draft. It is not intended to be IPsec-specific, although currently only = supports IPsec. Without a careful read the fact that there is ample = namespace available for passing non-IPsec policy probably isn't obvious. = And the mechanism for passing keying material is entirely unrelated to = IPsec. G-IKEv2 would simply need to define a new GSA TEK Payload type = for OSPF, IS-IS, PIM, etc. An example of what the GSA TEK payload would = like can be found in = , although this = I-D is meant for GDOI not G-IKEv2 so it's just an example. >=20 > This is definitely an interesting draft to track, especially for those > of us working on multicast keying for KARP. > It doesn't seem though that it really adds the DOI concept from IKEv1 = in > all its formality to IKEv2. Correct, it does not. Brian > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From zhangdacheng@huawei.com Wed Apr 6 18:41:57 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588F73A69A0 for ; Wed, 6 Apr 2011 18:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=2.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OZme39lwyDi for ; Wed, 6 Apr 2011 18:41:56 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A13783A682C for ; Wed, 6 Apr 2011 18:41:51 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ9001AAE4AR4@szxga03-in.huawei.com> for karp@ietf.org; Thu, 07 Apr 2011 09:43:22 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ900DD1E49XJ@szxga03-in.huawei.com> for karp@ietf.org; Thu, 07 Apr 2011 09:43:22 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Apr 2011 09:43:18 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 07 Apr 2011 09:43:20 +0800 Date: Thu, 07 Apr 2011 01:43:19 +0000 From: "Dacheng Zhang(Dacheng)" In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFD0371A5@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Originating-IP: [10.110.98.49] To: "Bhatia, Manav (Manav)" , Sam Hartman Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [karp] draft-zheng-mpls-ldp-hello-crypto-auth Thread-index: AcvyRvNE/utLFXVtS6uugSbqzrtpdgCBmpSAAAW7K4AAABJUAAAARNgAABfMd4A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0371A1@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0371A5@INBANSXCHMBSA1.in.alcatel-lucent.com> Cc: Mach Chen , "karp@ietf.org" Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 01:41:57 -0000 Do you imply there should be a challenge/Response solution for LDP as well. Similar with what we have proposed for OSPF? BR, Dacheng >> >> Oh, Ok I get it now. I think we can bring up an entire session with the replays >> which means we may have to mandate freshness if we really want to avoid >> the inter-session attacks. The router whose packets are replayed will play the >> passive role when establishing a session. >> >> Cheers, Manav >> >> > -----Original Message----- >> > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >> > Sent: Thursday, April 07, 2011 3.42 AM >> > To: Bhatia, Manav (Manav) >> > Cc: Sam Hartman; Mach Chen; zhenglianshu 50128; karp@ietf.org >> > Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth >> > >> > >>>>> "Bhatia," == Bhatia, Manav (Manav) >> > writes: >> > >> > Bhatia,> The boot count is applicable here as well as LDP is also >> > Bhatia,> susceptible to inter-session replay attacks. >> > Cheers, Manav >> > >> > No, my question was whether the boot count will work? >> > >> > What does the LDP state machine look like? >> > Are you sure a full replay wouldn't be useful? >> > >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp From manav.bhatia@alcatel-lucent.com Wed Apr 6 19:26:43 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DB43A659A for ; Wed, 6 Apr 2011 19:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGkFpXF93TGT for ; Wed, 6 Apr 2011 19:26:42 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 120003A6784 for ; Wed, 6 Apr 2011 19:26:41 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p372RoKL018719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2011 21:27:53 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p372Rmu0029389 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Apr 2011 07:57:49 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 7 Apr 2011 07:57:48 +0530 From: "Bhatia, Manav (Manav)" To: "Dacheng Zhang(Dacheng)" , Sam Hartman Date: Thu, 7 Apr 2011 07:57:45 +0530 Thread-Topic: [karp] draft-zheng-mpls-ldp-hello-crypto-auth Thread-Index: AcvyRvNE/utLFXVtS6uugSbqzrtpdgCBmpSAAAW7K4AAABJUAAAARNgAABfMd4AAAZ8mYA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0371BC@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFCF6715D@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0371A1@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0371A5@INBANSXCHMBSA1.in.alcatel-lucent.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.35 Cc: Mach Chen , "karp@ietf.org" Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 02:26:43 -0000 Yes, that's precisely what I mean. Cheers, Manav=20 > -----Original Message----- > From: Dacheng Zhang(Dacheng) [mailto:zhangdacheng@huawei.com]=20 > Sent: Thursday, April 07, 2011 7.13 AM > To: Bhatia, Manav (Manav); Sam Hartman > Cc: Mach Chen; karp@ietf.org > Subject: re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth >=20 > Do you imply there should be a challenge/Response solution=20 > for LDP as well. Similar with what we have proposed for OSPF? >=20 > BR, > Dacheng > >>=20 > >> Oh, Ok I get it now. I think we can bring up an entire=20 > session with the replays > >> which means we may have to mandate freshness if we really=20 > want to avoid > >> the inter-session attacks. The router whose packets are=20 > replayed will play the > >> passive role when establishing a session. > >>=20 > >> Cheers, Manav > >>=20 > >> > -----Original Message----- > >> > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > >> > Sent: Thursday, April 07, 2011 3.42 AM > >> > To: Bhatia, Manav (Manav) > >> > Cc: Sam Hartman; Mach Chen; zhenglianshu 50128; karp@ietf.org > >> > Subject: Re: [karp] draft-zheng-mpls-ldp-hello-crypto-auth > >> > > >> > >>>>> "Bhatia," =3D=3D Bhatia, Manav (Manav) > >> > writes: > >> > > >> > Bhatia,> The boot count is applicable here as well=20 > as LDP is also > >> > Bhatia,> susceptible to inter-session replay attacks. > >> > Cheers, Manav > >> > > >> > No, my question was whether the boot count will work? > >> > > >> > What does the LDP state machine look like? > >> > Are you sure a full replay wouldn't be useful? > >> > > >> _______________________________________________ > >> karp mailing list > >> karp@ietf.org > >> https://www.ietf.org/mailman/listinfo/karp > = From zhangdacheng@huawei.com Wed Apr 6 19:35:48 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E81A3A6817 for ; Wed, 6 Apr 2011 19:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfjWOqpcavIt for ; Wed, 6 Apr 2011 19:35:47 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id EC7EA3A6809 for ; Wed, 6 Apr 2011 19:35:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ90008RGI27B@szxga05-in.huawei.com> for karp@ietf.org; Thu, 07 Apr 2011 10:34:50 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ900KYSGHZG8@szxga05-in.huawei.com> for karp@ietf.org; Thu, 07 Apr 2011 10:34:50 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Apr 2011 10:33:18 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Thu, 07 Apr 2011 10:34:46 +0800 Date: Thu, 07 Apr 2011 02:34:46 +0000 From: "Dacheng Zhang(Dacheng)" In-reply-to: <699b533716142ba8626985ad650a376c.squirrel@www.trepanning.net> X-Originating-IP: [10.110.98.49] To: Dan Harkins , Russ Housley Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [karp] Can we assume strong preshared keys Thread-index: AQHL9I+CnOBS8fd9lkWh4GKfSJvJw5RQxxiAgAAQlQCAAM8DkA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <12822385-43B4-4A2D-9E44-C7E3EE5FAB98@vigilsec.com> <699b533716142ba8626985ad650a376c.squirrel@www.trepanning.net> Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 02:35:48 -0000 >> >> I'm not following this at all. One would think that if there was a >> way to seemlessly roll from one key to the next that a given key would >> be less "strong", since it's not gonna last very long and will soon be >> rolled out in exchange for the next. >> >> I think the only way we can reasonably answer that question is to look >> into how the first key is provisioned. If it's Joe from ISP A calling >> Fred from ISP B on the phone and saying, "enter w-3-8-g-capital-P-x-..." >> then I think the answer is "probably not." Such a technique is error >> prone if the pre-shared key is too "strong". I think Russ indicated that if there is an automatic key management system we can quickly revoke the first key with the stronger one in case the first key is weak. In the extreme condition, we can start a key revocation process at the very beginning of the execution of the whole system. For example, we use the "weak" key (e.g., exchanged through a phone call ) to generate a new stronger key (e.g., use the weak key to secure an authenticated DH exchange), and then use the newly generated stronger keys in the subsequent communication. Of course, he does not answer whether we can assume the first key distributed through a "out of band" way is strong enough or not. From christopher.morrow@gmail.com Wed Apr 6 19:49:49 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8423A6837 for ; Wed, 6 Apr 2011 19:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.473 X-Spam-Level: X-Spam-Status: No, score=-103.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QYWxZdbHRSO for ; Wed, 6 Apr 2011 19:49:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AC8F33A6784 for ; Wed, 6 Apr 2011 19:49:48 -0700 (PDT) Received: by wwa36 with SMTP id 36so1765545wwa.13 for ; Wed, 06 Apr 2011 19:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n83HOetLJAtpPPcds/mpcSnS+ciw6jx1TlJRNoEiLkU=; b=YOZvjnOvmH3wla/pckth7IJo/RuCunvloOu9b593TYmZZKAIl/StB3N/Z9/nLePWS1 YIBF5k7IM4i8ZFxPI0LUtOs7Bfvzqhg6af/5EaN47x8U3uoew/XCQ7Fe57EYK1TYkENJ NJ4n5uT22rt7i94N3LiP5CPaPpktx7CV2a5so= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Ayxs2tTxBiTgL7ysSHbsElnJq2qfc+kJFbxlDUNYBpFfUhj3Nnpsv1RrP1v7FR0ak5 4OrsK2rBIhYK/pOqJhOHQlJsDDoAgJG//y2/zWDzG1BR54KycyAcUFXl5UNDZ7nysZAQ QRsQ7gTpv5EU4sCFpkl5MMw3pH5Q2htUM3cGs= MIME-Version: 1.0 Received: by 10.216.239.130 with SMTP id c2mr300036wer.60.1302144691490; Wed, 06 Apr 2011 19:51:31 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.185.16 with HTTP; Wed, 6 Apr 2011 19:51:31 -0700 (PDT) In-Reply-To: <12822385-43B4-4A2D-9E44-C7E3EE5FAB98@vigilsec.com> References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <12822385-43B4-4A2D-9E44-C7E3EE5FAB98@vigilsec.com> Date: Wed, 6 Apr 2011 22:51:31 -0400 X-Google-Sender-Auth: ux47-qvEyJplk-1MCWPJTef634A Message-ID: From: Christopher Morrow To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 02:49:50 -0000 On Wed, Apr 6, 2011 at 4:42 PM, Russ Housley wrote: > I think we need to focus on incremental improvement. =A0Today, there is e= ssentially no way to roll from one key to the next. =A0If we can provide th= is capability, then there will be an incentive to use strong keys. =A0Today= , there is no such incentive. =A0So, let's assume that strong keys will be = used once a simple roll-over capability is available. > yes, this 1000 times... I missed, due to 'unfortunate scheduling' of grow over karp (what the F!?!?!), karp where I was hoping to have this very discussion. > On Apr 6, 2011, at 3:18 PM, Sam Hartman wrote: > >> >> Dan brings up an interesting question. >> >> From an operational standpoint is it acceptable for us to use assume >> that the preshared keys we have are reasonably strong? >> >> I hope the answer is that we can assume they are sufficiently >> strong. Doing so has significant simplicity assumptions. IN particular, >> we avoid having to deal with the password authenticated key exchange >> problem, which has crippled multiple working groups ability to make >> forward progress on an issue. Examples include SACRED, IPSECME, and I >> believe others. >> >> I think that the levels of security provided by SCRAM, Kerberos, and >> other mechanisms that have not encountered significant process problems >> will be adequate, particularly protected by a DH exchange. >> >> What this means is that an active attacker can potentially mount a >> dictionary attack. >> There are a *lot* of real world systems that have made the security >> decision that risk is acceptable. >> I think we should join the crowd. >> >> If a PAKE solution should suddenly appear that has broad support in the >> IETF, we can pick it up. >> I do not think we need to bite off unnecessary tasks that multiple WGs >> have failed at: we have enough of a challenge already. >> >> I consider PAKE a really nice to have, not a necessary requirement. >> _______________________________________________ >> 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 christopher.morrow@gmail.com Wed Apr 6 19:56:27 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF883A6837 for ; Wed, 6 Apr 2011 19:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.478 X-Spam-Level: X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-XTczTN2k5c for ; Wed, 6 Apr 2011 19:56:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5B98B3A6784 for ; Wed, 6 Apr 2011 19:56:25 -0700 (PDT) Received: by wwa36 with SMTP id 36so1768024wwa.13 for ; Wed, 06 Apr 2011 19:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=w2rQFJusKlqLqT7joisc3cFc8kpSwrpvJPyZLmrRyM8=; b=SaIBT7EGSYdaHn+FvFvXn7ONTjwoREThcn46CJ2x67c+DUuXCjZCd/3UEp67QFxhNT 0TsNlKG2GUIQh5NfkX9eXZot4bXS/2iFY+G3mJzC0bFTiSEZC38f41I0FBu65pjK2Vzu EmzgUOTxUKuL7urb80nlcvBOkZH8LjZ7t4Bu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ckWZ+sOw/Q9cK8Qy98BO6qUmleCZ2Sq9fNayOgIMkaMssQBr/YF+5kDVurjAZKybcc BS3Mu5WT1xg+asva2fcZDv2HV0zMnBW88/FkkgB9GWGopjc1yROUvlRYghCcpCKJaznG 99ntn7Q4fABmNS5rKWl0qRUb1NY9jOXArf2R8= MIME-Version: 1.0 Received: by 10.216.239.130 with SMTP id c2mr303748wer.60.1302145088893; Wed, 06 Apr 2011 19:58:08 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.185.16 with HTTP; Wed, 6 Apr 2011 19:58:08 -0700 (PDT) In-Reply-To: References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> Date: Wed, 6 Apr 2011 22:58:08 -0400 X-Google-Sender-Auth: V1aPEU444V2uOO4NcgcLK7o9Jvg Message-ID: From: Christopher Morrow To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Cc: "karp@ietf.org" Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 02:56:27 -0000 On Wed, Apr 6, 2011 at 3:18 PM, Sam Hartman wrote: > > Dan brings up an interesting question. > > From an operational standpoint is it acceptable for us to use assume > that the preshared keys we have are reasonably strong? why are you injecting your ideas of password strength into the standard? does it matter if I have 1 char for a passwd or 15 non-alpha mixedup jumbles? (aside from 1 char is dumb because it's ... 1char) Perhaps put another way: "What is a 'strong' preshared key?" > I hope the answer is that we can assume they are sufficiently > strong. Doing so has significant simplicity assumptions. IN particular, some folks use 'strong' passwords, some folks use 'cisco' (or other similar dictionary-esque words). I don't think that matters as much as the fact that once set ... they are unchangeable (essentially at least). > we avoid having to deal with the password authenticated key exchange > problem, which has crippled multiple working groups ability to make > forward progress on an issue. Examples include SACRED, IPSECME, and I > believe others. > > I think that the levels of security provided by SCRAM, Kerberos, and > other mechanisms that have not encountered significant process problems > will be adequate, particularly protected by a DH exchange. > > What this means is that an active attacker can potentially mount a > dictionary attack. keep in mind that long before most dictionary attacks are successful ... the router will have rebooted several thousand times. Keep in mind that your cell phone (anything of the modern 'smart phone' set) has more CPU power than almost every router in the field today. > There are a *lot* of real world systems that have made the security > decision that risk is acceptable. > I think we should join the crowd. > > If a PAKE solution should suddenly appear that has broad support in the > IETF, we can pick it up. > I do not think we need to bite off unnecessary tasks that multiple WGs > have failed at: we have enough of a challenge already. > > I consider PAKE a really nice to have, not a necessary requirement. seriously, the most critical problem today is that once set, a passwd/key on a bgp or ospf/isis session is essentially never going to change, since the mechanisms to enable that change simply don't exist. (I note that some folks have implemented ospf key management/change procedures, and ibgp changes were done at one very large network, but the inter-dependencies and failure scenarios are ... horrific beyond a few routers. The end effect is that these keys never change. If you could simply configure a second/third/fourth key and reliably roll those ... lots more goodness would be possible.) -chris From christopher.morrow@gmail.com Wed Apr 6 20:00:42 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069D33A6978 for ; Wed, 6 Apr 2011 20:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-fNsXPZ1WRb for ; Wed, 6 Apr 2011 20:00:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8CD253A6837 for ; Wed, 6 Apr 2011 20:00:40 -0700 (PDT) Received: by wyb29 with SMTP id 29so2025860wyb.31 for ; Wed, 06 Apr 2011 20:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3Bvi7WaiV+87K7SN/AM81W+O3eWT0K+YH1nHTZV8EQk=; b=Q5VP23V1G03DWsdRf+F1pVRjDVmn+P4BdM1x24ShOkN71k0fUrxdPS7/trkrhQJGkw s7Q4vtz5jPbm3ZfYWjR7vTs35AGuArqQ0+5BqYA6UgrZdoG0zYhjP/TmCNArnXioapAv k7sctExW05TFolwv1VSficZ0FowJr2Rep+n5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UTMUBpXU3Lb6/+PgV/cDSUlE+BaA1qmoONELHvlt3fTFxzbyXYb/L2gjQplwMMGZ2s f1Q19aDtAcBWMFoBJEgR8TBXbyTEo33884IyGPgjckIvO655GlE0rO1VryFQBdFnOrdi EEv70MhsxPqnLoFbaPt+B4TaKV0ViUOOc9Ltw= MIME-Version: 1.0 Received: by 10.216.254.82 with SMTP id g60mr298445wes.90.1302145344256; Wed, 06 Apr 2011 20:02:24 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.185.16 with HTTP; Wed, 6 Apr 2011 20:02:24 -0700 (PDT) In-Reply-To: <699b533716142ba8626985ad650a376c.squirrel@www.trepanning.net> References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <12822385-43B4-4A2D-9E44-C7E3EE5FAB98@vigilsec.com> <699b533716142ba8626985ad650a376c.squirrel@www.trepanning.net> Date: Wed, 6 Apr 2011 23:02:24 -0400 X-Google-Sender-Auth: Xnl54CvXHv9HXl9dcBQKnPlxeoU Message-ID: From: Christopher Morrow To: Dan Harkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 03:00:42 -0000 On Wed, Apr 6, 2011 at 5:41 PM, Dan Harkins wrote: > > =A0Hi Russ, > > On Wed, April 6, 2011 1:42 pm, Russ Housley wrote: >> I think we need to focus on incremental improvement. =A0Today, there is >> essentially no way to roll from one key to the next. =A0If we can provid= e >> this capability, then there will be an incentive to use strong keys. >> Today, there is no such incentive. =A0So, let's assume that strong keys = will >> be used once a simple roll-over capability is available. > > =A0I'm not following this at all. One would think that if there was a > way to seemlessly roll from one key to the next that a given key would > be less "strong", since it's not gonna last very long and will soon be > rolled out in exchange for the next. the problem today is you probably have to type it in, you probably have to remember what it is (or be able to tell simply by looking at it: "g-o-o-g-l-e .. yes, that's right!" If you could change keys easily it may make more sense for you to just implement some system to shovel new key material out to devices 'weekly' and then just make that key 'dd if=3D/dev/urandom bs=3D512 count=3D1 | md5sum' (or some similarly not-human-genrated-manner). > > =A0I think the only way we can reasonably answer that question is to look > into how the first key is provisioned. If it's Joe from ISP A calling > Fred from ISP B on the phone and saying, "enter w-3-8-g-capital-P-x-..." that's about it, or it's emailed in plain text ... :) w00t! -chris (no, I'm not joking that people just email it in plain text, it's not a "password" it's a 'stronger checksum' than 16bit CRC, for bgp at least) > then I think the answer is "probably not." Such a technique is error > prone if the pre-shared key is too "strong". > > =A0Hi Sam, > >> On Apr 6, 2011, at 3:18 PM, Sam Hartman wrote: >> >>> >>> Dan brings up an interesting question. >>> >>> From an operational standpoint is it acceptable for us to use assume >>> that the preshared keys we have are reasonably strong? >>> >>> I hope the answer is that we can assume they are sufficiently >>> strong. Doing so has significant simplicity assumptions. IN particular, >>> we avoid having to deal with the password authenticated key exchange >>> problem, which has crippled multiple working groups ability to make >>> forward progress on an issue. Examples include SACRED, IPSECME, and I >>> believe others. > > =A0The EKE patent is expiring in a couple of months so the reasons for > the failure of SACRED should not apply. The failure of PAKE in IPsecme > was due to the WG leadership and I don't believe we'll have any of those > problems here. > >>> I think that the levels of security provided by SCRAM, Kerberos, and >>> other mechanisms that have not encountered significant process problems >>> will be adequate, particularly protected by a DH exchange. >>> >>> What this means is that an active attacker can potentially mount a >>> dictionary attack. >>> There are a *lot* of real world systems that have made the security >>> decision that risk is acceptable. >>> I think we should join the crowd. > > =A0Following the crowd is a horrible reason to do anything. > >>> If a PAKE solution should suddenly appear that has broad support in the >>> IETF, we can pick it up. >>> I do not think we need to bite off unnecessary tasks that multiple WGs >>> have failed at: we have enough of a challenge already. >>> >>> I consider PAKE a really nice to have, not a necessary requirement. > > =A0Like I said, the EKE patent is expiring in a couple of months. The > broad support that's needed is here in KARP. > > =A0regards, > > =A0Dan. > > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From hartmans@mit.edu Thu Apr 7 04:42:05 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570773A6907 for ; Thu, 7 Apr 2011 04:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAaVviHatEA8 for ; Thu, 7 Apr 2011 04:42:03 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BE4023A68C1 for ; Thu, 7 Apr 2011 04:42:03 -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 82EEC2011F; Thu, 7 Apr 2011 07:40:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 22A6F446E; Thu, 7 Apr 2011 07:43:45 -0400 (EDT) From: Sam Hartman To: Christopher Morrow References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> Date: Thu, 07 Apr 2011 07:43:45 -0400 In-Reply-To: (Christopher Morrow's message of "Wed, 6 Apr 2011 22:58:08 -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] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 11:42:05 -0000 >>>>> "Christopher" == Christopher Morrow writes: Christopher> On Wed, Apr 6, 2011 at 3:18 PM, Sam Hartman wrote: >> > Dan brings up an interesting question. >> >> From an operational standpoint is it acceptable for us to use >> assume that the preshared keys we have are reasonably strong? Christopher> why are you injecting your ideas of password strength Christopher> into the standard? does it matter if I have 1 char for Christopher> a passwd or 15 non-alpha mixedup jumbles? (aside from 1 Christopher> char is dumb because it's ... 1char) I'm actually arguing that we should not inject ideas of password strength. The reason one might want to inject ideas of password strength is that there are two possible sets of security technologies. The first is a traditional challenge/response mechanism. We know how to do that. The drawback is that it has offline dictionary attack potential. That means an attacker can (under certain circumstances--depends on the protocol) capture material that allows the attacker to mount a dictionary attack against the key on the attacker's hardware without interactions with the router. There are other systems that fall into this basic category. The other class is PAKE systems. They have stronger dictionary attack resistance, but have traditionally had IPR and other process problems. The IPR situation *may* get easier later this year. Dan proposes that PAKE be a requirement for our key management protocol. I don't think that is necessary. From housley@vigilsec.com Thu Apr 7 06:58:42 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7434528C0E3 for ; Thu, 7 Apr 2011 06:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZIW08U5LyZa for ; Thu, 7 Apr 2011 06:58:41 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 8C3E128C0DD for ; Thu, 7 Apr 2011 06:58:41 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 93BE1F24030; Thu, 7 Apr 2011 10:00:53 -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 BjfZJdXNT42A; Thu, 7 Apr 2011 10:00:13 -0400 (EDT) Received: from [192.168.2.100] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id EFCE8F2402F; Thu, 7 Apr 2011 10:00:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Russ Housley X-Priority: 3 (Normal) In-Reply-To: <699b533716142ba8626985ad650a376c.squirrel@www.trepanning.net> Date: Thu, 7 Apr 2011 10:00:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <43F68AE2-4B28-4F10-8387-CA098C01FC35@vigilsec.com> References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <12822385-43B4-4A2D-9E44-C7E3EE5FAB98@vigilsec.com> <699b533716142ba8626985ad650a376c.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1082) Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 13:58:42 -0000 Dan: That is exactly my point. The key rollover is the thing we need to = focus on right now. This is the whole point of the key-table draft. = Procedures similar to the ones in TCP-AO can be used with the key-table = to seamlessly roll from one key to the next. This ability will allow = strong keys to be manually installed, used, and removed in a = straightforward manner. Then, we can go to work on an automated protocol to populate the = key-table with strong keys. My discussions with several people that build and operate routers leads = me to believe that this is a reasonable way forward. It provides a = common model for key management across all routing protocols, and it = avoids the designing of integrated key management for each routing = protocol. Russ >=20 > Hi Russ, >=20 > On Wed, April 6, 2011 1:42 pm, Russ Housley wrote: >> I think we need to focus on incremental improvement. Today, there is >> essentially no way to roll from one key to the next. If we can = provide >> this capability, then there will be an incentive to use strong keys. >> Today, there is no such incentive. So, let's assume that strong keys = will >> be used once a simple roll-over capability is available. >=20 > I'm not following this at all. One would think that if there was a > way to seemlessly roll from one key to the next that a given key would > be less "strong", since it's not gonna last very long and will soon be > rolled out in exchange for the next. >=20 > I think the only way we can reasonably answer that question is to = look > into how the first key is provisioned. If it's Joe from ISP A calling > Fred from ISP B on the phone and saying, "enter = w-3-8-g-capital-P-x-..." > then I think the answer is "probably not." Such a technique is error > prone if the pre-shared key is too "strong". >=20 > Hi Sam, >=20 >> On Apr 6, 2011, at 3:18 PM, Sam Hartman wrote: >>=20 >>>=20 >>> Dan brings up an interesting question. >>>=20 >>> =46rom an operational standpoint is it acceptable for us to use = assume >>> that the preshared keys we have are reasonably strong? >>>=20 >>> I hope the answer is that we can assume they are sufficiently >>> strong. Doing so has significant simplicity assumptions. IN = particular, >>> we avoid having to deal with the password authenticated key exchange >>> problem, which has crippled multiple working groups ability to make >>> forward progress on an issue. Examples include SACRED, IPSECME, and = I >>> believe others. >=20 > The EKE patent is expiring in a couple of months so the reasons for > the failure of SACRED should not apply. The failure of PAKE in IPsecme > was due to the WG leadership and I don't believe we'll have any of = those > problems here. >=20 >>> I think that the levels of security provided by SCRAM, Kerberos, and >>> other mechanisms that have not encountered significant process = problems >>> will be adequate, particularly protected by a DH exchange. >>>=20 >>> What this means is that an active attacker can potentially mount a >>> dictionary attack. >>> There are a *lot* of real world systems that have made the security >>> decision that risk is acceptable. >>> I think we should join the crowd. >=20 > Following the crowd is a horrible reason to do anything. >=20 >>> If a PAKE solution should suddenly appear that has broad support in = the >>> IETF, we can pick it up. >>> I do not think we need to bite off unnecessary tasks that multiple = WGs >>> have failed at: we have enough of a challenge already. >>>=20 >>> I consider PAKE a really nice to have, not a necessary requirement. >=20 > Like I said, the EKE patent is expiring in a couple of months. The > broad support that's needed is here in KARP. >=20 > regards, >=20 > Dan. >=20 >=20 >=20 From christopher.morrow@gmail.com Thu Apr 7 09:18:58 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250C428C0DB for ; Thu, 7 Apr 2011 09:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UssjFZqxziEM for ; Thu, 7 Apr 2011 09:18:57 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 394913A6A14 for ; Thu, 7 Apr 2011 09:18:57 -0700 (PDT) Received: by eye13 with SMTP id 13so977895eye.31 for ; Thu, 07 Apr 2011 09:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=en1n94LI9raJToeKKOz/SuF2h9E+DI3mzFf3EgCN9fQ=; b=bm0+ebdVXMadz2Z5prTF6e9vs8dZf1DH6NFCN5yI0PRIlDcp6pSr0kV2zqSiE7Yb3I Q8Ru46ULBrORV9U6bBM1VKs+towjiJ87GFad/Pklvdu2lD9JZx0+je9Z+bGC22OMSapz Z/la0l3R7IoQ8QIZBj9+6lnwon3F2usDwNsMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=J0ETSuXz+XhyA2r1Nnhs/fbGmYGE2qLNmzbvSa0NXJlhDdmjNfzhhW5tsP+Qvrzyjs ecUUlOqWT/SKXRcxU9lLfevg8emuqRTbN6sJjgSpePiOOh86ddw4gP2fH+4IDR1IroKB pxI/Yl9GrQl2IgRefi+jPaFaVXwEmYKvV5ZyE= MIME-Version: 1.0 Received: by 10.213.13.212 with SMTP id d20mr502609eba.139.1302193241004; Thu, 07 Apr 2011 09:20:41 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.213.33.81 with HTTP; Thu, 7 Apr 2011 09:20:40 -0700 (PDT) In-Reply-To: References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> Date: Thu, 7 Apr 2011 12:20:40 -0400 X-Google-Sender-Auth: EBKX28B4rpnfPHEAZrCLYA11lII Message-ID: From: Christopher Morrow To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "karp@ietf.org" Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 16:18:58 -0000 On Thu, Apr 7, 2011 at 7:43 AM, Sam Hartman wrote: >>>>>> "Christopher" =3D=3D Christopher Morrow wr= ites: > > =A0 =A0Christopher> On Wed, Apr 6, 2011 at 3:18 PM, Sam Hartman wrote: > =A0 =A0>> >> Dan brings up an interesting question. > =A0 =A0>> > =A0 =A0>> From an operational standpoint is it acceptable for us to use > =A0 =A0>> assume that the preshared keys we have are reasonably strong? > > =A0 =A0Christopher> why are you injecting your ideas of password strength > =A0 =A0Christopher> into the standard? does it matter if I have 1 char fo= r > =A0 =A0Christopher> a passwd or 15 non-alpha mixedup jumbles? (aside from= 1 > =A0 =A0Christopher> char is dumb because it's ... 1char) > > I'm actually arguing that we should not inject ideas of password > strength. good. this I agree with. > The reason one might want to inject ideas of password strength is that > there are two possible sets of security technologies. > > The first is a traditional challenge/response mechanism. =A0We know how t= o > do that. =A0The drawback is that it has offline dictionary attack > potential. =A0That means an attacker can (under certain > circumstances--depends on the protocol) capture material that allows the > attacker to mount a dictionary attack against the key on the attacker's > hardware without interactions with the router. > > There are other systems that fall into this basic category. > > The other class is PAKE systems. > They have stronger dictionary attack resistance, but have traditionally > had IPR and other process problems. > The IPR situation *may* get easier later this year. > > Dan proposes that PAKE be a requirement for our key management protocol. > I don't think that is necessary. I don't think it's super helpful either. -chris From dharkins@lounge.org Thu Apr 7 09:51:47 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD58E28C163 for ; Thu, 7 Apr 2011 09:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssVcC5H+iXzB for ; Thu, 7 Apr 2011 09:51:44 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8A23228C16E for ; Thu, 7 Apr 2011 09:51:43 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 26BA410224062; Thu, 7 Apr 2011 09:53:28 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 7 Apr 2011 09:53:28 -0700 (PDT) Message-ID: <6b0b3fb40c9de5309e29368bef5fe0f8.squirrel@www.trepanning.net> In-Reply-To: References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> Date: Thu, 7 Apr 2011 09:53:28 -0700 (PDT) From: "Dan Harkins" To: "Christopher Morrow" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 16:51:48 -0000 Hello, On Thu, April 7, 2011 9:20 am, Christopher Morrow wrote: > On Thu, Apr 7, 2011 at 7:43 AM, Sam Hartman wrote: >>>>>>> "Christopher" == Christopher Morrow >>>>>>> writes: >> >>    Christopher> On Wed, Apr 6, 2011 at 3:18 PM, Sam Hartman >> wrote: >>    >> >>> Dan brings up an interesting question. >>    >> >>    >> From an operational standpoint is it acceptable for us to use >>    >> assume that the preshared keys we have are reasonably strong? >> >>    Christopher> why are you injecting your ideas of password strength >>    Christopher> into the standard? does it matter if I have 1 char for >>    Christopher> a passwd or 15 non-alpha mixedup jumbles? (aside from 1 >>    Christopher> char is dumb because it's ... 1char) >> >> I'm actually arguing that we should not inject ideas of password >> strength. > > good. this I agree with. If the use of this credential opens the protocol up to attack then why is discussion of this topic something to argue _against_? >> The reason one might want to inject ideas of password strength is that >> there are two possible sets of security technologies. >> >> The first is a traditional challenge/response mechanism.  We know how to >> do that.  The drawback is that it has offline dictionary attack >> potential.  That means an attacker can (under certain >> circumstances--depends on the protocol) capture material that allows the >> attacker to mount a dictionary attack against the key on the attacker's >> hardware without interactions with the router. Right! >> There are other systems that fall into this basic category. >> >> The other class is PAKE systems. >> They have stronger dictionary attack resistance, but have traditionally >> had IPR and other process problems. >> The IPR situation *may* get easier later this year. Right! >> Dan proposes that PAKE be a requirement for our key management protocol. >> I don't think that is necessary. Now hold on a second. What I proposed was we not just blindly say "let's use IKE(v2)". There seems to be a desire these days to grab a tool and use it without taking the time to decide whether its use is appropriate. Just because I have a screwdriver within arms reach doesn't mean it's the best tool to use to drive a nail. > I don't think it's super helpful either. What an interesting statement. What do you value in a key management protocol if resistance to attack is not "super helpful"? Dan. From christopher.morrow@gmail.com Thu Apr 7 11:09:23 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B2B3A695D for ; Thu, 7 Apr 2011 11:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCPAoQ86GqlV for ; Thu, 7 Apr 2011 11:09:22 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 390BD28C0DB for ; Thu, 7 Apr 2011 11:09:22 -0700 (PDT) Received: by eye13 with SMTP id 13so1016481eye.31 for ; Thu, 07 Apr 2011 11:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7AOHTeNtUO0UHvWKyxiuXoY4sXK+x9Yw0ZiaRGYbq0s=; b=RDpB41VQ0BlIM6iVc+4DtmgEda1Xq83VXGWJrJgJT9Hg+l0rq/bnzpLdyckMWq3QE7 rH96WO8dMaxOaM5Apm1PfeArc7WY2anFJZIiwxuXtxHGg/wjtRqWhDvmBuTIaWTWzDZ1 q8eAGpZcRziXoIAxvBc+Ob+4oK6Kd28kzId7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NKdKCgtJ6D4f9dKpvhGBXvZC917Nxhe1HU28TsV8Sq6jWDzvw+sxl/3Hp0gDyd2lqQ 6BNhrXnucZiQip+V6nMpKp5qPDvwyk3Ki2YMbvuNn0iLKQD08MnUWyZYnnXFwuIKXj9J UNJa3lWjIq9MVM5ohcCwOiJKgNn7UjkxMPEe4= MIME-Version: 1.0 Received: by 10.213.27.14 with SMTP id g14mr622085ebc.63.1302199866217; Thu, 07 Apr 2011 11:11:06 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.213.33.81 with HTTP; Thu, 7 Apr 2011 11:11:06 -0700 (PDT) In-Reply-To: <6b0b3fb40c9de5309e29368bef5fe0f8.squirrel@www.trepanning.net> References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <6b0b3fb40c9de5309e29368bef5fe0f8.squirrel@www.trepanning.net> Date: Thu, 7 Apr 2011 20:11:06 +0200 X-Google-Sender-Auth: 7A-PWL41JvNBIzJkqHiugR2Eqnw Message-ID: From: Christopher Morrow To: Dan Harkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Can we assume strong preshared keys X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 18:09:23 -0000 On Thu, Apr 7, 2011 at 6:53 PM, Dan Harkins wrote: >> I don't think it's super helpful either. > > =A0What an interesting statement. What do you value in a key management > protocol if resistance to attack is not "super helpful"? i don't want a key management protocol. today I can not change keys on sessions, all I want is a simple (and again, this may be just implementation details for vendors to agree upon) 'add new key to config, devices work until they fail hashes, cycle on keys until they work or the session fails, lock on a new key if hashes start working with that new key' permit me to change keys sanely and at a rate that works for me. From hartmans@mit.edu Thu Apr 7 11:49:15 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1EF3A69DB for ; Thu, 7 Apr 2011 11:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.867 X-Spam-Level: X-Spam-Status: No, score=-102.867 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6gkERDEgTev for ; Thu, 7 Apr 2011 11:49:14 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B909A3A696D for ; Thu, 7 Apr 2011 11:49:14 -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 4EE5B203A1; Thu, 7 Apr 2011 14:47:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A213C446E; Thu, 7 Apr 2011 14:50:55 -0400 (EDT) From: Sam Hartman To: Christopher Morrow References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <6b0b3fb40c9de5309e29368bef5fe0f8.squirrel@www.trepanning.net> Date: Thu, 07 Apr 2011 14:50:55 -0400 In-Reply-To: (Christopher Morrow's message of "Thu, 7 Apr 2011 20:11:06 +0200") 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] key rollover X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 18:49:15 -0000 >>>>> "Christopher" == Christopher Morrow writes: Christopher> today I can not change keys on sessions, all I want is Christopher> a simple (and again, this may be just implementation Christopher> details for vendors to agree upon) 'add new key to Christopher> config, devices work until they fail hashes, cycle on Christopher> keys until they work or the session fails, lock on a Christopher> new key if hashes start working with that new key' Hi. Draft-ietf-karp-crypto-table-00 and draft-ietf-karp-ops-model together are intended to give you this. (The ops model goes beyond that; for the purposes of this discussion feel free to not focus on the parts of the document beyond the interactions with the key table.) If you get a chance it would be really helpful if you could take a look and 1) see if we're on the right track 2) Do you see any gaps left Any input you could provide would be greatly appreciated. From christopher.morrow@gmail.com Thu Apr 7 12:10:44 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F39E28C0D6 for ; Thu, 7 Apr 2011 12:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th5ITdOI6VTM for ; Thu, 7 Apr 2011 12:10:44 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A6FD73A69D3 for ; Thu, 7 Apr 2011 12:10:43 -0700 (PDT) Received: by ewy19 with SMTP id 19so1034948ewy.31 for ; Thu, 07 Apr 2011 12:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vVslTO8uGVLPcIhNEFNIhGeCkzO34xBoptAlPZ9AKcE=; b=o963bFfe6FxY7vmOehUPuDu7qW39X67X7kupcuZN3zpCm3sgh26UshgWVlE0W15gbp G8LJrk+L7cMIlNl/WhuAbdRIWfTapm0PvyS0oM23twIx7/X20UecEA8jzL3nSBIbgx1G p+qOqet6PZwKW+6BBMbuGPExYoFSVI/mw7aG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OeDUT6f6JnNRX24W9NVG72SgweKLhsB+ylfjSbYbH6SH12Zk7/SMXzrPPGzuE1rl9k /m27LSNpwTEqBGXBumLciEkCsykaPcrzoFH5XDPM+SAITSUqM9IuJofHCLr7N3d2/YAw ALaC/ul37ztQuELvmSOF0gRukfwGyk7Xm3fF4= MIME-Version: 1.0 Received: by 10.213.27.14 with SMTP id g14mr653897ebc.63.1302203547848; Thu, 07 Apr 2011 12:12:27 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.213.33.81 with HTTP; Thu, 7 Apr 2011 12:12:27 -0700 (PDT) In-Reply-To: References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <6b0b3fb40c9de5309e29368bef5fe0f8.squirrel@www.trepanning.net> Date: Thu, 7 Apr 2011 15:12:27 -0400 X-Google-Sender-Auth: yjA7G6UQDDoV16XJ79dBBuni3eA Message-ID: From: Christopher Morrow To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: karp@ietf.org Subject: Re: [karp] key rollover X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 19:10:44 -0000 On Thu, Apr 7, 2011 at 2:50 PM, Sam Hartman wrote: >>>>>> "Christopher" =3D=3D Christopher Morrow wr= ites: > > > =A0 =A0Christopher> today I can not change keys on sessions, all I want i= s > =A0 =A0Christopher> a simple (and again, this may be just implementation > =A0 =A0Christopher> details for vendors to agree upon) 'add new key to > =A0 =A0Christopher> config, devices work until they fail hashes, cycle on > =A0 =A0Christopher> keys until they work or the session fails, lock on a > =A0 =A0Christopher> new key if hashes start working with that new key' > > Hi. > Draft-ietf-karp-crypto-table-00 and draft-ietf-karp-ops-model together > are intended to give you this. > (The ops model goes beyond that; for the purposes of this discussion > feel free to not focus on the parts of the document beyond the > interactions with the key table.) > If you get a chance it would be really helpful if you could take a look > and > I will attempt to read/comment, thanks! > 1) see if we're on the right track > > 2) Do you see any gaps left > > Any input you could provide would be greatly appreciated. > From christopher.morrow@gmail.com Thu Apr 7 20:36:39 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3850D3A6A36 for ; Thu, 7 Apr 2011 20:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.844 X-Spam-Level: X-Spam-Status: No, score=-101.844 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18aOYi5zsK-L for ; Thu, 7 Apr 2011 20:36:38 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 59BA33A681C for ; Thu, 7 Apr 2011 20:36:38 -0700 (PDT) Received: by wwa36 with SMTP id 36so2653172wwa.13 for ; Thu, 07 Apr 2011 20:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SwlVwly/gA16kzm8crz0JZ5q5qY/15fGnkEfWm8tn48=; b=BAXizWqdCC9Z6q0JLb1MzoRjiMchiQvpDgtNlM0RSpGGFFnJP9YBwV/rXbREpefhZE zliV3N62/moAWaU3Mmf++lY9YqxCsViI8Q4Q7L8SIJkuTuKHPt8GdR0Fnbi5XTBAGwRJ 3fP8ofvKoDhbeThEqGiFUYsPtLVh4ZhNX/Wy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=lhgKsknPdknFd+OoDzqWGJNDSdOiG3sSPXA9B4CfXFIqwQPbaKsdBsQ8IqphKt6Yke gCacYjO3uEpG9Py0mYv4D3Fe5pjXTaajRgFo+FULQnnQdgPRGOb5EawRNJhak+ls3B6K uvVxdKZpd+8I0ChHws7EecpWNQRPdFI/w6sxo= MIME-Version: 1.0 Received: by 10.216.144.86 with SMTP id m64mr806532wej.32.1302233902915; Thu, 07 Apr 2011 20:38:22 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.13.131 with HTTP; Thu, 7 Apr 2011 20:38:22 -0700 (PDT) In-Reply-To: References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <6b0b3fb40c9de5309e29368bef5fe0f8.squirrel@www.trepanning.net> Date: Thu, 7 Apr 2011 23:38:22 -0400 X-Google-Sender-Auth: WDBrffHhQGku22cx9e6Xmqo6Ujw Message-ID: From: Christopher Morrow To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] key rollover X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 03:36:39 -0000 On Thu, Apr 7, 2011 at 3:12 PM, Christopher Morrow wrote: > draft-ietf-karp-ops-model morrowc@host: rfc-editor/ids-text-only$ ls draft-ietf-karp* draft-ietf-karp-crypto-key-table-00.txt draft-ietf-karp-crypto-key-table-00.txt.p7s draft-ietf-karp-design-guide-02.txt draft-ietf-karp-design-guide-02.txt.p7s draft-ietf-karp-ospf-analysis-00.txt draft-ietf-karp-ospf-analysis-00.txt.p7s draft-ietf-karp-threats-reqs-01.txt draft-ietf-karp-threats-reqs-01.xml hrm, no ops-model? From christopher.morrow@gmail.com Thu Apr 7 21:09:17 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0353A6A36 for ; Thu, 7 Apr 2011 21:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.791 X-Spam-Level: X-Spam-Status: No, score=-101.791 tagged_above=-999 required=5 tests=[AWL=-1.486, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TlSzsIsfFqj for ; Thu, 7 Apr 2011 21:09:17 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B25AC3A6784 for ; Thu, 7 Apr 2011 21:09:16 -0700 (PDT) Received: by wyb29 with SMTP id 29so3028207wyb.31 for ; Thu, 07 Apr 2011 21:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2kWee5KJuIPuanTXuNOlrAKlatGi3W7SQY3hIUXSRvE=; b=kK/hlyMSEKUY6SyxSEmfZOgQDgF7Mm87ijKNRuCJQ6X+uybT97sfkyvRBaIo6UBg6/ hrbqsH7PWmwFNhBs/yFCuBx1ED/0o0BnmWGHSXBmT6KZzlXVYmxHPr6G0YEUN0ZWScpN q5/VDPNhFxXfJWAbIgkc7tRW3tq4FFCwCrOr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=VJrZb9IDO7WQ0BfnVTD/i8KVydjbPbz1000Qduo5KZ4c5GAQAo5YSlQSlwkjE+9uUJ lyuVrMuivJ4ZpwoOI14AWG4G67yypBFXUMafegaSXmHVUZywyjfmCofSjJdx+pLp2fc/ CprweujrR+sLIedPDxw5rbCeNBpqtBY46kuVg= MIME-Version: 1.0 Received: by 10.216.184.129 with SMTP id s1mr1452197wem.32.1302235860958; Thu, 07 Apr 2011 21:11:00 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.13.131 with HTTP; Thu, 7 Apr 2011 21:11:00 -0700 (PDT) In-Reply-To: References: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> <6b0b3fb40c9de5309e29368bef5fe0f8.squirrel@www.trepanning.net> Date: Fri, 8 Apr 2011 00:11:00 -0400 X-Google-Sender-Auth: PYqr6BCPP8VNttjVGx09stllbUI Message-ID: From: Christopher Morrow To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] key rollover X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 04:09:17 -0000 On Thu, Apr 7, 2011 at 11:38 PM, Christopher Morrow wrote: > On Thu, Apr 7, 2011 at 3:12 PM, Christopher Morrow > wrote: >> draft-ietf-karp-ops-model > > morrowc@host: rfc-editor/ids-text-only$ ls draft-ietf-karp* > draft-ietf-karp-crypto-key-table-00.txt > draft-ietf-karp-crypto-key-table-00.txt.p7s > draft-ietf-karp-design-guide-02.txt > draft-ietf-karp-design-guide-02.txt.p7s > draft-ietf-karp-ospf-analysis-00.txt > draft-ietf-karp-ospf-analysis-00.txt.p7s > draft-ietf-karp-threats-reqs-01.txt > draft-ietf-karp-threats-reqs-01.xml > > hrm, no ops-model? a kind reader notes it was posted today, or appeared in the repo today... From liang.xiaoping@zte.com.cn Mon Apr 11 02:50:45 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC7A3A69EB for ; Mon, 11 Apr 2011 02:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDee6f24EEGZ for ; Mon, 11 Apr 2011 02:50:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 9F0193A6AA7 for ; Mon, 11 Apr 2011 02:50:41 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 12520536813104; Mon, 11 Apr 2011 17:50:01 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 22671.1258253720; Mon, 11 Apr 2011 17:39:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3B9deIl094179; Mon, 11 Apr 2011 17:39:40 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: <362d440a4d6126a0e7f330883c0a46f6.squirrel@www.trepanning.net> To: "Dan Harkins" MIME-Version: 1.0 X-KeepSent: D6FBC7C0:13FE9611-4825786F:003472C5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Mon, 11 Apr 2011 17:39:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-11 17:39:41, Serialize complete at 2011-04-11 17:39:41 Content-Type: multipart/alternative; boundary="=_alternative 003511084825786F_=" X-MAIL: mse02.zte.com.cn p3B9deIl094179 Cc: "karp@ietf.org" Subject: Re: [karp] just use IKE(v2) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 09:50:45 -0000 This is a multipart message in MIME format. --=_alternative 003511084825786F_= Content-Type: text/plain; charset="US-ASCII" Hi Dan, Surely we can use IKEv2 as KMP, but with some extensions to support routing protocols, please refer to my draft "Automated Security Association Management for Routing Protocols" ( http://tools.ietf.org/html/draft-liang-karp-auto-sa-management-rp-01), especially Section 3.1. While one big concern is, do we really need to reply on IPsec, which seems clumsy? I think a light KMP for routing protocols is better. Cheers, Ellen (Xiaoping) Liang 2011-04-04 06:22 Hello, During the karp meeting on Friday I brought up the issue of using IKE(v2) as a key management protocol for karp or rolling-our-own. Based on comments I received after the meeting it is apparent I explained myself poorly. Let me try again. I think it is important to explore rolling-our-own key management protocol that is customized to the task at hand. The WG may eventually decide not to go that route, and to just use IKE(v2), but I think we should weigh the pluses and minuses of both before we start saying things like, "oh well we're just gonna use IKE(v2)" (and a thousand pardons up front if I'm mischaracterizing anyone with that statement). The way I see it is, we could use IKEv1 and define another DOI, or we could graft on a DOI concept on to IKEv2 and use that. The former seems correct since that's what the DOI was for, but people want to discourage the proliferation of IKEv1. The latter uses IKEv2 (which pleases the people discouraged by the proliferation of IKEv1) but adds on a complication that was intentionally left off the rev of IKE. And both of those have a security issue that would be exploited by their expected use. Today operators configure a shared key on their routers to use for securing BGP traffic. They are comfortable with that UI and would probably resist complications in their lives. So it would make sense to use a key management solution in karp that didn't have a security problem when used with a pre-shared key. Neither IKEv1 nor IKEv2 qualify in that regard, they are both susceptible to dictionary attack. IPsecme tried to come up with a single standardized solution to that problem but the result is 3 competing ones. Even picking one of those means that the IKEv2 exchange has grown from 4 messages to 6. And it, effectively, doubles the public key crypto operations. That's might be a price the WG is willing to pay. The WG might even decide that the security issue with pre-shared keys in IKE(v2) isn't worth addressing. But here's another possibility. It's possible to implement a protocol that accomplishes authentication, key agreement, and key confirmation (important characteristics of any key management protocol), using only a pre-shared key, and to do it in just 3 messages, with less crypto operations than is done in IKE today. What's more, this protocol would be resistant to dictionary attack. The EKE patent expires in a few months so it's possible to have a solution free of IPR worries, with some finessing of the Diffie-Hellman groups. It's also possible to use an unpatented protocol whose IPR situation is a little more questionable (it's what Donald Rumsfeld referred to as "the known unknowns and the unknown unknowns"), that could use any of the Diffie-Hellman groups defined in IKE today (both EC and MODP). That seems compelling to me. We give the operators the same comfortable UI they've come to expect but insert robust, misuse resistant, and provably secure cryptography underneath. Or we can just use IKE(v2). But it would be nice to discuss the possibilities before we get too far down one path (which it seemed like we were doing last Friday). regards, Dan. _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003511084825786F_= Content-Type: text/html; charset="US-ASCII"
Hi Dan,

Surely we can use IKEv2 as KMP, but with some extensions to support routing protocols, please refer to my draft "Automated Security Association Management for Routing Protocols" (http://tools.ietf.org/html/draft-liang-karp-auto-sa-management-rp-01), especially Section 3.1.

While one big concern is, do we really need to reply on IPsec, which seems clumsy? I think a light KMP for routing protocols is better.

Cheers,
Ellen (Xiaoping) Liang

2011-04-04 06:22


 Hello,

 During the karp meeting on Friday I brought up the issue of using
IKE(v2) as a key management protocol for karp or rolling-our-own.
Based on comments I received after the meeting it is apparent I
explained myself poorly. Let me try again.

 I think it is important to explore rolling-our-own key management
protocol that is customized to the task at hand. The WG may eventually
decide not to go that route, and to just use IKE(v2), but I think we
should weigh the pluses and minuses of both before we start saying
things like, "oh well we're just gonna use IKE(v2)" (and a thousand
pardons up front if I'm mischaracterizing anyone with that statement).

 The way I see it is, we could use IKEv1 and define another DOI, or we
could graft on a DOI concept on to IKEv2 and use that. The former seems
correct since that's what the DOI was for, but people want to discourage
the proliferation of IKEv1. The latter uses IKEv2 (which pleases the
people discouraged by the proliferation of IKEv1) but adds on a
complication that was intentionally left off the rev of IKE. And
both of those have a security issue that would be exploited by their
expected use.

 Today operators configure a shared key on their routers to use for
securing BGP traffic. They are comfortable with that UI and would
probably resist complications in their lives. So it would make sense to
use a key management solution in karp that didn't have a security
problem when used with a pre-shared key. Neither IKEv1 nor IKEv2 qualify
in that regard, they are both susceptible to dictionary attack.

 IPsecme tried to come up with a single standardized solution to that
problem but the result is 3 competing ones. Even picking one of those
means that the IKEv2 exchange has grown from 4 messages to 6. And it,
effectively, doubles the public key crypto operations. That's might be
a price the WG is willing to pay. The WG might even decide that the
security issue with pre-shared keys in IKE(v2) isn't worth addressing.
But here's another possibility.

 It's possible to implement a protocol that accomplishes authentication,
key agreement, and key confirmation (important characteristics of any
key management protocol), using only a pre-shared key, and to do it in
just 3 messages, with less crypto operations than is done in IKE today.
What's more, this protocol would be resistant to dictionary attack.

 The EKE patent expires in a few months so it's possible to have a
solution free of IPR worries, with some finessing of the Diffie-Hellman
groups. It's also possible to use an unpatented protocol whose IPR
situation is a little more questionable (it's what Donald Rumsfeld
referred to as "the known unknowns and the unknown unknowns"), that
could use any of the Diffie-Hellman groups defined in IKE today (both
EC and MODP).

 That seems compelling to me. We give the operators the same
comfortable UI they've come to expect but insert robust, misuse
resistant, and provably secure cryptography underneath.

 Or we can just use IKE(v2).

 But it would be nice to discuss the possibilities before we get too
far down one path (which it seemed like we were doing last Friday).

 regards,

 Dan.


_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003511084825786F_=-- From liang.xiaoping@zte.com.cn Mon Apr 11 02:56:56 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468553A6AE9 for ; Mon, 11 Apr 2011 02:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.708 X-Spam-Level: X-Spam-Status: No, score=-99.708 tagged_above=-999 required=5 tests=[AWL=-2.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HaR3X6bIM2v for ; Mon, 11 Apr 2011 02:56:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 97F073A6AE1 for ; Mon, 11 Apr 2011 02:56:53 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12520536813104; Mon, 11 Apr 2011 17:56:23 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 69889.2291438175; Mon, 11 Apr 2011 17:45:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3B9ucnU014874; Mon, 11 Apr 2011 17:56:38 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-KeepSent: EBCDE30C:50DB61C5-4825786F:00351C21; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Mon, 11 Apr 2011 17:56:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-11 17:56:40, Serialize complete at 2011-04-11 17:56:40 Content-Type: multipart/alternative; boundary="=_alternative 00369EED4825786F_=" X-MAIL: mse02.zte.com.cn p3B9ucnU014874 Cc: "karp@ietf.org" Subject: Re: [karp] OUr own KMP based on IKEv2 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 09:56:56 -0000 This is a multipart message in MIME format. --=_alternative 00369EED4825786F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2FtLA0KDQpJS0V2MiBpcyBhIHZlcnkgZ29vZCBLTVAgaW4gbXkgZXllLiBBbmQganVzdCBh cyB5b3Ugc2FpZCwgIndlIHNob3VsZCBzdGFydCANCmZyb20gSUtFdjIiLCB0aGF0J3Mgd2hhdCBJ IGhhdmUgZG9uZS4gUGxlYXNlIHJlYWQgbXkgZHJhZnQgICJBdXRvbWF0ZWQgDQpTZWN1cml0eSBB c3NvY2lhdGlvbiBNYW5hZ2VtZW50IGZvciBSb3V0aW5nIFByb3RvY29scyIgKA0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGlhbmcta2FycC1hdXRvLXNhLW1hbmFnZW1lbnQtcnAt MDEpLCANCmVzcGVjaWFsbHkgU2VjdGlvbiAzLjEuIFdpdGggZW5vdWdoIGV4dGVuc2lvbnMsIElL RXYyIGNhbiBzZXJ2ZSByb3V0aW5nIA0KcHJvdG9jb2xzIGluIG9uZS10by1vbmUgbWVzc2FnZSB0 cmFuc2FjdGlvbiB0eXBlLiBBcyB0byByb3V0aW5nIHByb3RvY29scyANCmluIG9uZS10by1tYW55 IG1lc3NhZ2UgdHJhbnNhY3Rpb24gdHlwZSwgeW91ciBwcm9wb3NhbCBNUktNUCBhbmQgRy1JS0V2 MiANCnByb3Bvc2VkIGJ5IEFsZG91cyBZZXVuZywgZXQuIGFsLiBzZWVtIHBvc3NpYmxlIHNvbHV0 aW9ucy4gDQoNCkJ1dCBJIHByZWZlciBhIGxpZ2h0IEtNUCwgbm90IGEgS01QIHJlbGllZCBvbiBJ UHNlYy4gU28gSSBqdXN0IHRoaW5rIA0KYWJvdXQuLi5jb3VsZCB3ZSBkZXNpZ24gYSBLTVAgd2hp Y2ggZG9lc24ndCBuZWVkIElQc2VjPyBXaGF0J3MgeW91ciANCm9waW5pb24/IERvIHlvdSB0aGlu ayBpdCBpcyBhIGdvb2QgaWRlYT8gDQoNCkkgcmVhbGx5IGxpa2UgdGhlIGtleSB0YWJsZSBpZGVh ICgNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1rYXJwLWNyeXB0 by1rZXktdGFibGUvKSwgYW5kIA0KZ290IGFuIGlkZWEgdGhhdCBleHRlbmRlZCBJS0V2MiBiYXNl ZCBvbiBrZXkgdGFibGUgbWFrZXMgYSBsaWdodCBLTVAgZm9yIA0Kcm91dGluZyBwcm90b2NvbHMu DQoNCldvdWxkIGxpa2UgdG8gaGVhciBmcm9tIHlvdSBvbiB0aGlzIHRvcGljIF5fXg0KDQpDaGVl cnMsDQpFbGxlbiAoWGlhb3BpbmcpIExpYW5nDQogDQoNCg0KDQpTYW0gSGFydG1hbiA8aGFydG1h bnMtaWV0ZkBtaXQuZWR1PiANCreivP7IyzogIGthcnAtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0w NC0wNyAwMzoyMw0KDQrK1bz+yMsNCiJEYW4gSGFya2lucyIgPGRoYXJraW5zQGxvdW5nZS5vcmc+ DQqzrcvNDQoia2FycEBpZXRmLm9yZyIgPGthcnBAaWV0Zi5vcmc+DQrW98ziDQpba2FycF0gT1Vy IG93biBLTVAgYmFzZWQgb24gSUtFdjINCg0KDQoNCg0KDQoNCg0KDQpEYW4sIEkgdGhpbmsgSSBj b3JyZWN0bHkgdW5kZXJzdG9vZCB3aGF0IHlvdSB3ZXJlIHByb3Bvc2luZy4NCg0KSSdtIG5vdCBz dXJlIEknbSBwcm9wb3NpbmcgdGhlIHNhbWUgdGhpbmcgb3Igbm90Lg0KDQpJIHRoaW5rIHdlIHNo b3VsZCBzdGFydCBmcm9tIElLRXYyLg0KSSBkbyBub3QgYmVsaWV2ZSB0aGF0IHdlIHNob3VsZCBm b3JtYWxseSBidWlsZCBpbiBhIERPSSBjb25jZXB0IGludG8NCklLRXYyLg0KSW5zdGVhZCwgSSB0 aGluayB3ZSBzaG91bGQgdGFrZSBJS0V2MiwgY29weSBpdCBhbmQgZXZvbHZlDQpzZW1pLWluZGVw ZW5kZW50bHkgdG8gZm9ybSBhIEtNUCB0aGF0IG1lZXRzIG91ciBuZWVkcy4NClNvLCBJJ20gcHJv cG9zaW5nIHJvbGxpbmcgb3VyIG9uLCBidXQgSSdtIHByb3Bvc2luZyB0aGF0IHdlIG5vdCBzdGFy dA0KY29tcGxldGVseSBmcm9tIHNjcmF0Y2guDQoNCk15IHN1c3BpY2lvbiBpcyB0aGF0IHdlIHdp bGwgaGF2ZSBhIHJlbGF0aXZlbHkgc21hbGwgbnVtYmVyIG9mDQpkaWZmZXJlbmNlcyBiZXR3ZWVu IG91ciBwcm90b2NvbCBhbmQgSUtFdjIsIHNpbWlsYXIgaW4gcXVhbnRpdHkgYW5kDQpjb21wbGV4 aXR5IHRvIHRoZSBzbWFsbCBudW1iZXIgb2YgZGlmZmVyZW5jZXMgYmV0d2VlbiBUTFMgYW5kIERU TFMuIFRoZQ0Kc291cmNlIG9mIHRoZXNlIGRpZmZlcmVuY2VzIHdpbGwgYmUgZGlmZmVyZW50OiBy YXRoZXIgdGhhbiBkaWZmZXJlbmNlcw0KYmV0d2VlbiBVRFAgYW5kIFRDUCBpdCB3aWxsIGJlIGRp ZmZlcmVuY2VzIGNhdXNlZCBieSBkb21haW4uICBzbywgSQ0Kc3VzcGVjdCBpdCB3aWxsIGJlIHBv c3NpYmxlIHRoYXQgd2UgY2FuIGFsbG93IGZ1dHVyZSBleHRlbnNpb25zIHRvIElLRXYyDQp0byBl cXVhbGx5IGFwcGx5IHRvIG91ciBwcm90b2NvbC4gIEZvciBleGFtcGxlLCB3ZSBjYW4gYWxsb3cg UEFLRQ0KbWVzc2FnZXMgZm9yIElLRXYyIHRvIGJlIHVzZWQgaWYgd2Ugc2hvdWxkIGNob29zZS4N Cg0KSG93ZXZlciwgSSBkbyBub3QgcHJvcG9zZSB0byBpbnRyb2R1Y2UgdGhlIERPSSBjb25jZXB0 IGludG8gSUtFdjIuDQoNCkkgZG8gbm90IHN1cHBvcnQgdXNpbmcgSUtFdjEgYXQgYWxsLiAgSUtF djIgc2VlbXMgbGlrZSBhIG11Y2ggY2xlYW5lcg0KcHJvdG9jb2wuICBJJ2QgbXVjaCByYXRoZXIg YmUgd29ya2luZyBvbiBpdCB0aGFuIElLRXYyLiBJIGZpbmQgcmVhc29uaW5nDQphYm91dCBJS0V2 MSBtb3JlIGNoYWxsZW5naW5nLCBldmVuIHRob3VnaCBpbiBzb21lIHNlbnNlIGl0IGhhcyBtb3Jl DQphYnN0cmFjdGlvbnMuDQoNClRoZXNlIGFyZSBteSB0aG91Z2h0cy4NCkkgd2lsbCBiZSB2ZXJ5 IGludGVyZXN0ZWQgdG8gaGVhciBmcm9tIG90aGVycy4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQprYXJwIG1haWxpbmcgbGlzdA0Ka2FycEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9rYXJwDQoNCg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUg bm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRo IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt Lg0K --=_alternative 00369EED4825786F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBTYW0sPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5JS0V2MiBpcyBhIHZlcnkgZ29vZCBLTVAgaW4gbXkgZXllLiBBbmQganVz dCBhcyB5b3UNCnNhaWQsICZxdW90O3dlIHNob3VsZCBzdGFydCBmcm9tIElLRXYyJnF1b3Q7LCB0 aGF0J3Mgd2hhdCBJIGhhdmUgZG9uZS4NClBsZWFzZSByZWFkIG15IGRyYWZ0ICZuYnNwOyZxdW90 O0F1dG9tYXRlZCBTZWN1cml0eSBBc3NvY2lhdGlvbiBNYW5hZ2VtZW50DQpmb3IgUm91dGluZyBQ cm90b2NvbHMmcXVvdDsgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpYW5nLWth cnAtYXV0by1zYS1tYW5hZ2VtZW50LXJwLTAxKSwNCmVzcGVjaWFsbHkgU2VjdGlvbiAzLjEuIFdp dGggZW5vdWdoIGV4dGVuc2lvbnMsIElLRXYyIGNhbiBzZXJ2ZSByb3V0aW5nDQpwcm90b2NvbHMg aW4gb25lLXRvLW9uZSBtZXNzYWdlIHRyYW5zYWN0aW9uIHR5cGUuIEFzIHRvIHJvdXRpbmcgcHJv dG9jb2xzDQppbiBvbmUtdG8tbWFueSBtZXNzYWdlIHRyYW5zYWN0aW9uIHR5cGUsIHlvdXIgcHJv cG9zYWwgTVJLTVAgYW5kIEctSUtFdjINCnByb3Bvc2VkIGJ5IDwvZm9udD48L3R0Pjxmb250IHNp emU9Mj5BbGRvdXMgWWV1bmc8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj4sDQpldC4gYWwuIHNlZW0g cG9zc2libGUgc29sdXRpb25zLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPkJ1dCBJIHByZWZlciBhIGxpZ2h0IEtNUCwgbm90IGEgS01QIHJlbGllZCBvbiBJUHNlYy4N ClNvIEkganVzdCB0aGluayBhYm91dC4uLmNvdWxkIHdlIGRlc2lnbiBhIEtNUCB3aGljaCBkb2Vz bid0IG5lZWQgSVBzZWM/DQpXaGF0J3MgeW91ciBvcGluaW9uPyBEbyB5b3UgdGhpbmsgaXQgaXMg YSBnb29kIGlkZWE/ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+SSByZWFsbHkgbGlrZSB0aGUga2V5IHRhYmxlIGlkZWEgKGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1rYXJwLWNyeXB0by1rZXktdGFibGUvKSwNCmFuZCBnb3Qg YW4gaWRlYSB0aGF0IGV4dGVuZGVkIElLRXYyIGJhc2VkIG9uIGtleSB0YWJsZSBtYWtlcyBhIGxp Z2h0IEtNUA0KZm9yIHJvdXRpbmcgcHJvdG9jb2xzLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+V291bGQgbGlrZSB0byBoZWFyIGZyb20geW91IG9uIHRoaXMgdG9waWMg Xl9ePC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5DaGVlcnMsPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5FbGxlbiAoWGlhb3BpbmcpIExpYW5nPC9mb250 PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+U2FtIEhhcnRtYW4gJmx0 O2hhcnRtYW5zLWlldGZAbWl0LmVkdSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7a2FycC1ib3VuY2VzQGlldGYub3JnPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDQtMDcgMDM6MjM8 L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ JnF1b3Q7RGFuIEhhcmtpbnMmcXVvdDsgJmx0O2RoYXJraW5zQGxvdW5nZS5vcmcmZ3Q7PC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4mcXVvdDtrYXJwQGlldGYub3JnJnF1b3Q7ICZsdDtrYXJwQGlldGYub3Jn Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W2thcnBdIE9VciBvd24gS01QIGJhc2VkIG9uIElLRXYy PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj48YnI+DQo8YnI+DQpEYW4sIEkgdGhpbmsgSSBjb3JyZWN0bHkgdW5kZXJzdG9vZCB3aGF0IHlv dSB3ZXJlIHByb3Bvc2luZy48YnI+DQo8YnI+DQpJJ20gbm90IHN1cmUgSSdtIHByb3Bvc2luZyB0 aGUgc2FtZSB0aGluZyBvciBub3QuPGJyPg0KPGJyPg0KSSB0aGluayB3ZSBzaG91bGQgc3RhcnQg ZnJvbSBJS0V2Mi48YnI+DQpJIGRvIG5vdCBiZWxpZXZlIHRoYXQgd2Ugc2hvdWxkIGZvcm1hbGx5 IGJ1aWxkIGluIGEgRE9JIGNvbmNlcHQgaW50bzxicj4NCklLRXYyLjxicj4NCkluc3RlYWQsIEkg dGhpbmsgd2Ugc2hvdWxkIHRha2UgSUtFdjIsIGNvcHkgaXQgYW5kIGV2b2x2ZTxicj4NCnNlbWkt aW5kZXBlbmRlbnRseSB0byBmb3JtIGEgS01QIHRoYXQgbWVldHMgb3VyIG5lZWRzLjxicj4NClNv LCBJJ20gcHJvcG9zaW5nIHJvbGxpbmcgb3VyIG9uLCBidXQgSSdtIHByb3Bvc2luZyB0aGF0IHdl IG5vdCBzdGFydDxicj4NCmNvbXBsZXRlbHkgZnJvbSBzY3JhdGNoLjxicj4NCjxicj4NCk15IHN1 c3BpY2lvbiBpcyB0aGF0IHdlIHdpbGwgaGF2ZSBhIHJlbGF0aXZlbHkgc21hbGwgbnVtYmVyIG9m PGJyPg0KZGlmZmVyZW5jZXMgYmV0d2VlbiBvdXIgcHJvdG9jb2wgYW5kIElLRXYyLCBzaW1pbGFy IGluIHF1YW50aXR5IGFuZDxicj4NCmNvbXBsZXhpdHkgdG8gdGhlIHNtYWxsIG51bWJlciBvZiBk aWZmZXJlbmNlcyBiZXR3ZWVuIFRMUyBhbmQgRFRMUy4gVGhlPGJyPg0Kc291cmNlIG9mIHRoZXNl IGRpZmZlcmVuY2VzIHdpbGwgYmUgZGlmZmVyZW50OiByYXRoZXIgdGhhbiBkaWZmZXJlbmNlczxi cj4NCmJldHdlZW4gVURQIGFuZCBUQ1AgaXQgd2lsbCBiZSBkaWZmZXJlbmNlcyBjYXVzZWQgYnkg ZG9tYWluLiAmbmJzcDtzbywNCkk8YnI+DQpzdXNwZWN0IGl0IHdpbGwgYmUgcG9zc2libGUgdGhh dCB3ZSBjYW4gYWxsb3cgZnV0dXJlIGV4dGVuc2lvbnMgdG8gSUtFdjI8YnI+DQp0byBlcXVhbGx5 IGFwcGx5IHRvIG91ciBwcm90b2NvbC4gJm5ic3A7Rm9yIGV4YW1wbGUsIHdlIGNhbiBhbGxvdyBQ QUtFPGJyPg0KbWVzc2FnZXMgZm9yIElLRXYyIHRvIGJlIHVzZWQgaWYgd2Ugc2hvdWxkIGNob29z ZS48YnI+DQo8YnI+DQpIb3dldmVyLCBJIGRvIG5vdCBwcm9wb3NlIHRvIGludHJvZHVjZSB0aGUg RE9JIGNvbmNlcHQgaW50byBJS0V2Mi48YnI+DQo8YnI+DQpJIGRvIG5vdCBzdXBwb3J0IHVzaW5n IElLRXYxIGF0IGFsbC4gJm5ic3A7SUtFdjIgc2VlbXMgbGlrZSBhIG11Y2ggY2xlYW5lcjxicj4N CnByb3RvY29sLiAmbmJzcDtJJ2QgbXVjaCByYXRoZXIgYmUgd29ya2luZyBvbiBpdCB0aGFuIElL RXYyLiBJIGZpbmQgcmVhc29uaW5nPGJyPg0KYWJvdXQgSUtFdjEgbW9yZSBjaGFsbGVuZ2luZywg ZXZlbiB0aG91Z2ggaW4gc29tZSBzZW5zZSBpdCBoYXMgbW9yZTxicj4NCmFic3RyYWN0aW9ucy48 YnI+DQo8YnI+DQpUaGVzZSBhcmUgbXkgdGhvdWdodHMuPGJyPg0KSSB3aWxsIGJlIHZlcnkgaW50 ZXJlc3RlZCB0byBoZWFyIGZyb20gb3RoZXJzLjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Ka2FycCBtYWlsaW5nIGxpc3Q8YnI+DQprYXJw QGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9rYXJw PGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZv cm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0 aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5i c3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5i c3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZu YnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNw O2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNw O3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0 byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwm bmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZu YnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQm bmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNw O3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZl Jm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5i c3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5i c3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZu YnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdl Jm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5i c3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lz dGVtLg0KPC9wcmU+ --=_alternative 00369EED4825786F_=-- From liang.xiaoping@zte.com.cn Mon Apr 11 03:15:10 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4753128C0E9 for ; Mon, 11 Apr 2011 03:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.263 X-Spam-Level: X-Spam-Status: No, score=-101.263 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thNsHNYK7DNM for ; Mon, 11 Apr 2011 03:15:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 69AE53A6AF6 for ; Mon, 11 Apr 2011 03:15:08 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510536813104; Mon, 11 Apr 2011 18:12:21 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 22671.1642050135; Mon, 11 Apr 2011 18:04:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3BA4U7c024020; Mon, 11 Apr 2011 18:04:30 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: <48D133C1-95B2-4BBC-A5B7-F339CB0A2A41@cisco.com> To: Brian Weis MIME-Version: 1.0 X-KeepSent: D8B3E099:5AF92D16-4825786F:0036CCEB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Mon, 11 Apr 2011 18:04:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-11 18:04:32, Serialize complete at 2011-04-11 18:04:32 Content-Type: multipart/alternative; boundary="=_alternative 0037573A4825786F_=" X-MAIL: mse02.zte.com.cn p3BA4U7c024020 Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] OUr own KMP based on IKEv2 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 10:15:10 -0000 This is a multipart message in MIME format. --=_alternative 0037573A4825786F_= Content-Type: text/plain; charset="US-ASCII" I'm thinking a light G-IKEv2 without living in IPsec...^_^ Cheers, Ellen (Xiaoping) Liang 2011-04-07 08:29 On Apr 6, 2011, at 12:51 PM, Sam Hartman wrote: >>>>>> "Sean" == Sean Turner writes: > > Sean> On 4/6/11 3:23 PM, Sam Hartman wrote: > Sean> snip.. > >>> However, I do not propose to introduce the DOI concept into >>> IKEv2. > > Sean> Somebody has introduced the concept of GDOI into IKEv2: > > Sean> https://datatracker.ietf.org/doc/draft-yeung-g-ikev2/ > > That draft seems to accomplish adding multicast IPsec to IKEv2. That to > me doesn't sound like a new DOI or a DOI concept. (The fact that the > protocol has DOI in its name not withstanding.) Actually, the G-IKEv2 protocol noted above doesn't have DOI in it's name ... it's titled "Group Key Management using IKEv2". > > The authors may have intended--I can't really tell--to do something that > could key groups that were not IPsec groups. > I don't have confidence they succeeded: there seem to be a lot of > IPsec-specific assumptions scattered throughout the draft. It is not intended to be IPsec-specific, although currently only supports IPsec. Without a careful read the fact that there is ample namespace available for passing non-IPsec policy probably isn't obvious. And the mechanism for passing keying material is entirely unrelated to IPsec. G-IKEv2 would simply need to define a new GSA TEK Payload type for OSPF, IS-IS, PIM, etc. An example of what the GSA TEK payload would like can be found in , although this I-D is meant for GDOI not G-IKEv2 so it's just an example. > > This is definitely an interesting draft to track, especially for those > of us working on multicast keying for KARP. > It doesn't seem though that it really adds the DOI concept from IKEv1 in > all its formality to IKEv2. Correct, it does not. Brian > _______________________________________________ > 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 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0037573A4825786F_= Content-Type: text/html; charset="US-ASCII"
I'm thinking a light G-IKEv2 without living in IPsec...^_^

Cheers,
Ellen (Xiaoping) Liang
 

2011-04-07 08:29

On Apr 6, 2011, at 12:51 PM, Sam Hartman wrote:

>>>>>> "Sean" == Sean Turner <turners@ieca.com> writes:
>
>    Sean> On 4/6/11 3:23 PM, Sam Hartman wrote:
>    Sean> snip..
>
>>> However, I do not propose to introduce the DOI concept into
>>> IKEv2.
>
>    Sean> Somebody has introduced the concept of GDOI into IKEv2:
>
>    Sean> https://datatracker.ietf.org/doc/draft-yeung-g-ikev2/
>
> That draft seems to accomplish adding multicast IPsec to IKEv2.  That to
> me doesn't sound like a new DOI or a DOI concept.  (The fact that the
> protocol has DOI in its name not withstanding.)

Actually, the G-IKEv2 protocol noted above doesn't have DOI in it's name ... it's titled "Group Key Management using IKEv2".

>
> The authors may have intended--I can't really tell--to do something that
> could key groups that were not IPsec groups.
> I don't have confidence they succeeded: there seem to be a lot of
> IPsec-specific assumptions scattered throughout the draft.

It is not intended to be IPsec-specific, although currently only supports IPsec. Without a careful read the fact that there is ample namespace available for passing non-IPsec policy probably isn't obvious. And the mechanism for passing keying material is entirely unrelated to IPsec. G-IKEv2 would simply need to define a new GSA TEK Payload type for OSPF, IS-IS, PIM, etc. An example of what the GSA TEK payload would like can be found in <http://tools.ietf.org/html/draft-weis-gdoi-mac-tek-02>, although this I-D is meant for GDOI not G-IKEv2 so it's just an example.

>
> This is definitely an interesting draft to track, especially for those
> of us working on multicast keying for KARP.
> It doesn't seem though that it really adds the DOI concept from IKEv1 in
> all its formality to IKEv2.

Correct, it does not.

Brian

> _______________________________________________
> 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

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0037573A4825786F_=-- From manav.bhatia@alcatel-lucent.com Tue Apr 12 03:15:15 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8F957E070B for ; Tue, 12 Apr 2011 03:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.043 X-Spam-Level: X-Spam-Status: No, score=-5.043 tagged_above=-999 required=5 tests=[AWL=1.556, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC1eYv5ShlKm for ; Tue, 12 Apr 2011 03:15:15 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id D871BE0705 for ; Tue, 12 Apr 2011 03:15:11 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3CAF74m023435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Apr 2011 05:15:10 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3CAF6d0015436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 12 Apr 2011 15:45:06 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 12 Apr 2011 15:45:06 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Tue, 12 Apr 2011 15:45:11 +0530 Thread-Topic: BFD Security Gap Analysis Thread-Index: Acv4+oILfEeuQaBtTK2B2k1+obeqCQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD037C81@INBANSXCHMBSA1.in.alcatel-lucent.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.35 Subject: [karp] BFD Security Gap Analysis 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, 12 Apr 2011 10:15:15 -0000 Hi, Dacheng and I have posted a draft that does BFD securtity gap analysis. Wou= ld be great if the WG can review this and provide some feedback. http://www.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-00.txt Cheers, Manav -- Manav Bhatia, Service Router Product Group (SRPG) Alcatel-Lucent, India= From vnktshsriram@gmail.com Tue Apr 12 08:33:15 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE2B0E080E for ; Tue, 12 Apr 2011 08:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W924VMy7KJNC for ; Tue, 12 Apr 2011 08:33:15 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id EEBD0E07EA for ; Tue, 12 Apr 2011 08:33:14 -0700 (PDT) Received: by vws12 with SMTP id 12so6414796vws.31 for ; Tue, 12 Apr 2011 08:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2MzjNMJRok+prh7V6kIcPs2/9axZmxp5UK5QYaEQX/U=; b=avE05PyjDRcYo3hMRMDOAtVOghuvbpmBECeXOYKp4Kr3HLh6PG4zv+VU+YLQM/q8MG pyJf6sAuZ5zVdXMJVN6fx5V5kXyMMoCrQjYpMY10G6UrPHx3fi37VqmD1ls98JHuCG6I baIxPirP2ZRZN+muCYWfrPs+ffagG/UGCuNUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OfaxKiCwkXL1E7bPN1is8Vwgm88Xbvf/KFt7VP53uVxbq1O2oRsTfwQ3g+34y6ERxS i/7X0/QByOvhSeyBS6OuVCdYiBqCF1JpWTe0Q2pgP8mTv6aDURNlK5DTXZKICnU3kozy rFU4l46FQ4y89uuUC3Q0oQs0vvbNttAKpOQz8= MIME-Version: 1.0 Received: by 10.52.73.196 with SMTP id n4mr1882153vdv.227.1302622394588; Tue, 12 Apr 2011 08:33:14 -0700 (PDT) Received: by 10.52.166.39 with HTTP; Tue, 12 Apr 2011 08:33:14 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD037C81@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD037C81@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 12 Apr 2011 21:03:14 +0530 Message-ID: From: Venkatesh Sriram To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "karp@ietf.org" Subject: Re: [karp] BFD Security Gap Analysis 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, 12 Apr 2011 15:33:15 -0000 Hi, I agree that BFD may prove to be the weakest link in the chain if its the only one using Keyed-MD5 when every other protocol that BFD provides bidirectional reachability check for is using an HMAC-SHA variant. Thus, we do need to upgrade its security. The only issue is that its digest needs to be verified in HW as opposed to the other routing protocols where this can be done in SW. But, then this is not an issue and i already see vendors supporting MD5 for BFD in HW. The draft mentions inter-session replay attacks. I would wager that the existing methods being debated in this WG (non volatile memory, etc) would work for BFD as well. The authors might want to provide a link to that work here in this draft. Sriram On Tue, Apr 12, 2011 at 3:45 PM, Bhatia, Manav (Manav) wrote: > Hi, > > Dacheng and I have posted a draft that does BFD securtity gap analysis. Would be great if the WG can review this and provide some feedback. > > http://www.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-00.txt > > Cheers, Manav > > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From manav.bhatia@alcatel-lucent.com Tue Apr 12 13:54:40 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92749E08F6 for ; Tue, 12 Apr 2011 13:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANdZsIy57OaS for ; Tue, 12 Apr 2011 13:54:39 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id A099CE0688 for ; Tue, 12 Apr 2011 13:54:39 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3CKsZ1u009241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 15:54:37 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3CKsYWv015586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Apr 2011 02:24:34 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 13 Apr 2011 02:24:34 +0530 From: "Bhatia, Manav (Manav)" To: Venkatesh Sriram Date: Wed, 13 Apr 2011 02:24:37 +0530 Thread-Topic: [karp] BFD Security Gap Analysis Thread-Index: Acv5JvO1XVI8MMBrTzaZNsH9Zo2+JQALKhZw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD037D6A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD037C81@INBANSXCHMBSA1.in.alcatel-lucent.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.37 Cc: "karp@ietf.org" Subject: Re: [karp] BFD Security Gap Analysis 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, 12 Apr 2011 20:54:40 -0000 Hi Sriram, =20 > I agree that BFD may prove to be the weakest link in the chain if its > the only one using Keyed-MD5 when every other protocol that BFD > provides bidirectional reachability check for is using an HMAC-SHA > variant. Thus, we do need to upgrade its security. The only issue is > that its digest needs to be verified in HW as opposed to the other > routing protocols where this can be done in SW. But, then this is not > an issue and i already see vendors supporting MD5 for BFD in HW. I agree. >=20 > The draft mentions inter-session replay attacks. I would wager that > the existing methods being debated in this WG (non volatile memory, > etc) would work for BFD as well. The authors might want to provide a > link to that work here in this draft. Yes you are correct - the methods currently being debated here will work fo= r BFD as well. We will definitely include a pointer to one of those documents. Cheers, Manav >=20 > Sriram >=20 > On Tue, Apr 12, 2011 at 3:45 PM, Bhatia, Manav (Manav) > wrote: > > Hi, > > > > Dacheng and I have posted a draft that does BFD securtity=20 > gap analysis. Would be great if the WG can review this and=20 > provide some feedback. > > > > http://www.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-00.txt > > > > Cheers, Manav > > > > -- > > Manav Bhatia, > > Service Router Product Group (SRPG) > > Alcatel-Lucent, India > > _______________________________________________ > > karp mailing list > > karp@ietf.org > > https://www.ietf.org/mailman/listinfo/karp > > > = From curtis@occnc.com Tue Apr 12 17:13:25 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D590E0722 for ; Tue, 12 Apr 2011 17:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Uh7dlihrL9S for ; Tue, 12 Apr 2011 17:13:24 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id B5DC8E06B8 for ; Tue, 12 Apr 2011 17:13:24 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3D0DK2C073603; Tue, 12 Apr 2011 20:13:21 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104130013.p3D0DK2C073603@harbor.orleans.occnc.com> To: "Bhatia, Manav (Manav)" From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 02:24:37 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD037D6A@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 12 Apr 2011 20:13:20 -0400 Sender: curtis@occnc.com Cc: "karp@ietf.org" Subject: Re: [karp] BFD Security Gap Analysis X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com 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, 13 Apr 2011 00:13:25 -0000 In message <7C362EEF9C7896468B36C9B79200D8350CFD037D6A@INBANSXCHMBSA1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > Hi Sriram, > > > I agree that BFD may prove to be the weakest link in the chain if its > > the only one using Keyed-MD5 when every other protocol that BFD > > provides bidirectional reachability check for is using an HMAC-SHA > > variant. Thus, we do need to upgrade its security. The only issue is > > that its digest needs to be verified in HW as opposed to the other > > routing protocols where this can be done in SW. But, then this is not > > an issue and i already see vendors supporting MD5 for BFD in HW. > > I agree. > > > > > The draft mentions inter-session replay attacks. I would wager that > > the existing methods being debated in this WG (non volatile memory, > > etc) would work for BFD as well. The authors might want to provide a > > link to that work here in this draft. > > Yes you are correct - the methods currently being debated here will > work for BFD as well. > > We will definitely include a pointer to one of those documents. > > Cheers, Manav It doesn't hurt to define both MD5 and SHA* for BFD. If a provider wants to run SHA2048 at a low rate, thats fine. If they need to back off to SHA1 or MD5 to acheive a high rate or go to more sessions, that is OK too. Different deployments will have different requirements. The only sticky issue is which methods carry a MUST in the specs. Long key SHA is not hard to do in hardware, just hard to do fast. Curtis > > Sriram > > > > On Tue, Apr 12, 2011 at 3:45 PM, Bhatia, Manav (Manav) > > wrote: > > > Hi, > > > > > > Dacheng and I have posted a draft that does BFD securtity > > gap analysis. Would be great if the WG can review this and > > provide some feedback. > > > > > > http://www.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-00.txt > > > > > > Cheers, Manav > > > > > > -- > > > Manav Bhatia, > > > Service Router Product Group (SRPG) > > > Alcatel-Lucent, India > From manav.bhatia@alcatel-lucent.com Tue Apr 12 17:33:01 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5FD89E0714 for ; Tue, 12 Apr 2011 17:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.592 X-Spam-Level: X-Spam-Status: No, score=-5.592 tagged_above=-999 required=5 tests=[AWL=1.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdLEDapBvo6i for ; Tue, 12 Apr 2011 17:33:00 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id C2DA8E0681 for ; Tue, 12 Apr 2011 17:32:59 -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 p3D0Wrmw007120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2011 19:32:55 -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 p3D0Wp0K007094 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Apr 2011 06:02:52 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 13 Apr 2011 06:02:51 +0530 From: "Bhatia, Manav (Manav)" To: "curtis@occnc.com" Date: Wed, 13 Apr 2011 06:02:51 +0530 Thread-Topic: [karp] BFD Security Gap Analysis Thread-Index: Acv5b57aGjXUXduJSza8L0OnJGVsJwAAdmAA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD037D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of "Wed, 13 Apr 2011 02:24:37 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD037D6A@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104130013.p3D0DK2C073603@harbor.orleans.occnc.com> In-Reply-To: <201104130013.p3D0DK2C073603@harbor.orleans.occnc.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: "karp@ietf.org" Subject: Re: [karp] BFD Security Gap Analysis 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, 13 Apr 2011 00:33:01 -0000 =20 > It doesn't hurt to define both MD5 and SHA* for BFD. If a provider > wants to run SHA2048 at a low rate, thats fine. If they need to back > off to SHA1 or MD5 to acheive a high rate or go to more sessions, that > is OK too. Different deployments will have different requirements. I agree! >=20 > The only sticky issue is which methods carry a MUST in the specs. > Long key SHA is not hard to do in hardware, just hard to do fast. Very true and which is why draft-bhatia-bfd-crypto-auth- hasn't been able t= o make any progress since 2009 when it was first published. The security fo= lks want stronger algorithms as MUSTs which becomes trickier for vendors to= support for BFD when supporting 10ms timeouts. Cheers, Manav >=20 > Curtis From zhangdacheng@huawei.com Tue Apr 12 20:42:47 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EEC6CE06C3 for ; Tue, 12 Apr 2011 20:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5fncw3lBL0A for ; Tue, 12 Apr 2011 20:42:47 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 34222E0687 for ; Tue, 12 Apr 2011 20:42:47 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJK00CDRNJ8BC@szxga05-in.huawei.com> for karp@ietf.org; Wed, 13 Apr 2011 11:40:20 +0800 (CST) Received: from szxeml204-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJK003LINJ7U9@szxga05-in.huawei.com> for karp@ietf.org; Wed, 13 Apr 2011 11:40:20 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 13 Apr 2011 11:40:05 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 13 Apr 2011 11:39:47 +0800 Date: Wed, 13 Apr 2011 03:39:47 +0000 From: "Dacheng Zhang(Dacheng)" In-reply-to: X-Originating-IP: [10.110.98.49] To: Venkatesh Sriram , "Bhatia, Manav (Manav)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [karp] BFD Security Gap Analysis Thread-index: Acv4+oILfEeuQaBtTK2B2k1+obeqCf//0r8A//6yBIA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7C362EEF9C7896468B36C9B79200D8350CFD037C81@INBANSXCHMBSA1.in.alcatel-lucent.com> Cc: "karp@ietf.org" Subject: Re: [karp] BFD Security Gap Analysis 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, 13 Apr 2011 03:42:48 -0000 >> >> Hi, >> >> I agree that BFD may prove to be the weakest link in the chain if its >> the only one using Keyed-MD5 when every other protocol that BFD >> provides bidirectional reachability check for is using an HMAC-SHA >> variant. Thus, we do need to upgrade its security. The only issue is >> that its digest needs to be verified in HW as opposed to the other >> routing protocols where this can be done in SW. But, then this is not >> an issue and i already see vendors supporting MD5 for BFD in HW. >> >> The draft mentions inter-session replay attacks. I would wager that >> the existing methods being debated in this WG (non volatile memory, >> etc) would work for BFD as well. The authors might want to provide a >> link to that work here in this draft. >> [Dacheng Zhang] That is a good idea. We will do that. Actually, it is worthwhile for us to have a little more discussion on this topic. For instance, we mentioned that the current 32 bits sequence number is not long enough in some cases. So, if we extend the sequence number to 64 bits in order to support the anti replay solution adopting non-volatile memory. It may be more reasonable to use 16 bits for reboot times counting and use the rest 48 bits for sequence number. In addition, as we have mentioned in the draft, maybe we can deal with inter-connection replay attacks by updating discriminators. ^_^ From curtis@occnc.com Tue Apr 12 22:40:09 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00A03E06EC for ; Tue, 12 Apr 2011 22:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdyKvVqVXGip for ; Tue, 12 Apr 2011 22:40:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 56099E06C5 for ; Tue, 12 Apr 2011 22:40:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3D5e5ix007320; Wed, 13 Apr 2011 01:40:05 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104130540.p3D5e5ix007320@harbor.orleans.occnc.com> To: "Bhatia, Manav (Manav)" From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 06:02:51 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD037D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 13 Apr 2011 01:40:05 -0400 Sender: curtis@occnc.com Cc: "karp@ietf.org" Subject: Re: [karp] BFD Security Gap Analysis X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com 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, 13 Apr 2011 05:40:09 -0000 In message <7C362EEF9C7896468B36C9B79200D8350CFD037D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > > > It doesn't hurt to define both MD5 and SHA* for BFD. If a provider > > wants to run SHA2048 at a low rate, thats fine. If they need to back > > off to SHA1 or MD5 to acheive a high rate or go to more sessions, that > > is OK too. Different deployments will have different requirements. > > I agree! > > > > > The only sticky issue is which methods carry a MUST in the specs. > > Long key SHA is not hard to do in hardware, just hard to do fast. > > Very true and which is why draft-bhatia-bfd-crypto-auth- hasn't been > able to make any progress since 2009 when it was first published. The > security folks want stronger algorithms as MUSTs which becomes > trickier for vendors to support for BFD when supporting 10ms timeouts. > > Cheers, Manav > > > > > Curtis Manav, So we can't just indicate MUST implement on MD5 and SHOULD implement on SHA* and have the providers decide whether to beat up vendors in their RFI, RFP, RFQ process? At RFI/RFP/RFQ time, it is better for a provider to have an RFC with a SHOULD in it than an internet-draft with a MUST in it. Without the RFC status it is difficult internally for someone within the provider to cite a draft at all. The RFI/RFP/RFQ can easily change a SHOULD into a MUST if the provider wants something to be a MUST in their deployment. Sometimes the security folks are their own worst enemies. Curtis btw - Some people might remember how POSIX got passed by making all sorts of things optional and then creating FIPS-151 (Federal Information Processing Standard 151) which cited POSIX but made all the optional "profiles" manditory for government purchases. From manav.bhatia@alcatel-lucent.com Wed Apr 13 10:53:17 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5BE59E0848 for ; Wed, 13 Apr 2011 10:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmnkk1KeQE0s for ; Wed, 13 Apr 2011 10:53:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfc.amsl.com (Postfix) with ESMTP id AF5D2E0850 for ; Wed, 13 Apr 2011 10:53:16 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p3DHrDhT017588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Apr 2011 12:53:15 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3DHrCjC025687 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 13 Apr 2011 23:23:12 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 13 Apr 2011 23:23:12 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Wed, 13 Apr 2011 23:23:10 +0530 Thread-Topic: PIM-SM Gap Analysis Thread-Index: Acv6A6b8G1oy4Q3ZReGsuSvMmQuIfw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE216@INBANSXCHMBSA1.in.alcatel-lucent.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.33 Subject: [karp] PIM-SM Gap Analysis 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, 13 Apr 2011 17:53:17 -0000 Hi, I have written a small draft that does security gap analysis for PIM-SM. I = don't think its complete yet and could definitely do with some review from = the KARP and the PIM WGs. URL for the draft: http://www.ietf.org/id/draft-bhatia-karp-pim-gap-analysis-00.txt Cheers, Manav -- Manav Bhatia, Service Router Product Group (SRPG) Alcatel-Lucent, India= From manav.bhatia@alcatel-lucent.com Wed Apr 13 16:47:57 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 246E5E0679 for ; Wed, 13 Apr 2011 16:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKNnT5cPnDwh for ; Wed, 13 Apr 2011 16:47:56 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfc.amsl.com (Postfix) with ESMTP id 6E92BE061E for ; Wed, 13 Apr 2011 16:47:56 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p3DNlqCB004658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Apr 2011 18:47:55 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3DNlpqJ027027 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 14 Apr 2011 05:17:51 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 14 Apr 2011 05:17:51 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Thu, 14 Apr 2011 05:17:50 +0530 Thread-Topic: Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv6NTMFTlWOl/kBQCiD5tHWT/WyAQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.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.33 Subject: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 13 Apr 2011 23:47:57 -0000 Hi, Instead of using the pre shared key (PSK) in manual keying for all packets = the routing protocols could use a traffic key that's derived from the PSK u= sing some key derivation function. Each side could announce a random number= (a nonce) and the KDF could mix this with the PSK to derive the traffic ke= y per session. Benefits of this approach: o Key rollover becomes very easy as it's a local decision now requiring now= co-ordination with our peers. Each side can generate a new nonce and all o= thers recompute the traffic key based on the new nonce value. Attackers can= t inject packets with spurious nonces as this packet will be protected usin= g the traffic key based on the nonce that others have sent. o Avoids inter-session replay attacks without involving non volatile memory= as each router will use a different nonce upon booting up. In OSPF the nonce could be carried in the HELLO packets. There could be bit= carried in the HELLOs which would indicate that the Hello is currently usi= ng the long lived key (or the PSK). The receiver upon receiving this would = authenticate the packet using the PSK and would use the KDF to derive the t= raffic key. The KDF would mix the nonce with the PSK in some deterministic = fashion. The receiver uses the derived traffic key for signing all subseque= nt OSPF packets and would indicate this by setting some bit (which says usi= ng traffic key). It will also include its own nonce. The original sender no= w uses the nonce that it receives and starts using the traffic key derived = from this nonce for all subsequent packets. For a key rollover, the senders= just have to choose a new nonce value. This can be done as frequently as d= esired and requires no manual intervention.=20 Does this sound as going in the right direction? Cheers, Manav -- Manav Bhatia, Service Router Product Group (SRPG) Alcatel-Lucent, India= From zhangdacheng@huawei.com Wed Apr 13 20:52:36 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E62B8E07E4 for ; Wed, 13 Apr 2011 20:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.724 X-Spam-Level: X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WbuGJr7hZCN for ; Wed, 13 Apr 2011 20:52:36 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 51507E0707 for ; Wed, 13 Apr 2011 20:52:22 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00311IOWM2@szxga05-in.huawei.com> for karp@ietf.org; Thu, 14 Apr 2011 11:50:56 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM003UKIOUOW@szxga05-in.huawei.com> for karp@ietf.org; Thu, 14 Apr 2011 11:50:56 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Apr 2011 11:50:39 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 14 Apr 2011 11:50:54 +0800 Date: Thu, 14 Apr 2011 03:50:53 +0000 From: "Dacheng Zhang(Dacheng)" In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Originating-IP: [10.110.98.49] To: "Bhatia, Manav (Manav)" , "karp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Using dynamically derived Traffic Keys for Routing Protocols Thread-index: Acv6NTMFTlWOl/kBQCiD5tHWT/WyAQAIaYLQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 14 Apr 2011 03:52:37 -0000 SGksIE1hbmF2Og0KDQpJIGp1c3QgaGFuZGxlZCBteSByZXBvcnQgYW5kIHJlYWQgeW91ciBlbWFp bC4gSXQgc2VlbXMgdGhhdCB5b3UgYXJlIHRyeWluZyB0byBpbXBsZW1lbnQgc29tZSBmdW5jdGlv bnMgKGdlbmVyYXRpbmcgc2Vzc2lvbiBrZXlzIGF0IHJ1biB0aW1lKSBvZiBhbiBhdXRvbWF0aWMg b2Yga21wIGludG8gcm91dGluZyBwcm90b2NvbHMgaW5zdGVhZCBvZiBnZW5lcmF0aW5nIGEgZ2Vu ZXJpYyBLTVAgc29sdXRpb24gZm9yIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scz8gIE15IGNv bmNlcm4gaXMgd2hldGhlciBpdCBpcyBjb25mbGljdCB3aXRoIHRoZSBvYmplY3RpdmUgb2Yga2Fy cD8NCg0KQ2hlZXJzDQpEYWNoZW5nDQoNCj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4gt6K8/sjL OiBrYXJwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzprYXJwLWJvdW5jZXNAaWV0Zi5vcmddILT6 se0gQmhhdGlhLA0KPj4gTWFuYXYgKE1hbmF2KQ0KPj4gt6LLzcqxvOQ6IDIwMTHE6jTUwjE0yNUg Nzo0OA0KPj4gytW8/sjLOiBrYXJwQGlldGYub3JnDQo+PiDW98ziOiBba2FycF0gVXNpbmcgZHlu YW1pY2FsbHkgZGVyaXZlZCBUcmFmZmljIEtleXMgZm9yIFJvdXRpbmcgUHJvdG9jb2xzDQo+PiAN Cj4+IEhpLA0KPj4gDQo+PiBJbnN0ZWFkIG9mIHVzaW5nIHRoZSBwcmUgc2hhcmVkIGtleSAoUFNL KSBpbiBtYW51YWwga2V5aW5nIGZvciBhbGwgcGFja2V0cyB0aGUNCj4+IHJvdXRpbmcgcHJvdG9j b2xzIGNvdWxkIHVzZSBhIHRyYWZmaWMga2V5IHRoYXQncyBkZXJpdmVkIGZyb20gdGhlIFBTSyB1 c2luZw0KPj4gc29tZSBrZXkgZGVyaXZhdGlvbiBmdW5jdGlvbi4gRWFjaCBzaWRlIGNvdWxkIGFu bm91bmNlIGEgcmFuZG9tIG51bWJlciAoYQ0KPj4gbm9uY2UpIGFuZCB0aGUgS0RGIGNvdWxkIG1p eCB0aGlzIHdpdGggdGhlIFBTSyB0byBkZXJpdmUgdGhlIHRyYWZmaWMga2V5IHBlcg0KPj4gc2Vz c2lvbi4gQmVuZWZpdHMgb2YgdGhpcyBhcHByb2FjaDoNCj4+IA0KPj4gbyBLZXkgcm9sbG92ZXIg YmVjb21lcyB2ZXJ5IGVhc3kgYXMgaXQncyBhIGxvY2FsIGRlY2lzaW9uIG5vdyByZXF1aXJpbmcg bm93DQo+PiBjby1vcmRpbmF0aW9uIHdpdGggb3VyIHBlZXJzLiBFYWNoIHNpZGUgY2FuIGdlbmVy YXRlIGEgbmV3IG5vbmNlIGFuZCBhbGwNCj4+IG90aGVycyByZWNvbXB1dGUgdGhlIHRyYWZmaWMg a2V5IGJhc2VkIG9uIHRoZSBuZXcgbm9uY2UgdmFsdWUuIEF0dGFja2Vycw0KPj4gY2FudCBpbmpl Y3QgcGFja2V0cyB3aXRoIHNwdXJpb3VzIG5vbmNlcyBhcyB0aGlzIHBhY2tldCB3aWxsIGJlIHBy b3RlY3RlZCB1c2luZw0KPj4gdGhlIHRyYWZmaWMga2V5IGJhc2VkIG9uIHRoZSBub25jZSB0aGF0 IG90aGVycyBoYXZlIHNlbnQuDQo+PiANCj4+IG8gQXZvaWRzIGludGVyLXNlc3Npb24gcmVwbGF5 IGF0dGFja3Mgd2l0aG91dCBpbnZvbHZpbmcgbm9uIHZvbGF0aWxlIG1lbW9yeSBhcw0KPj4gZWFj aCByb3V0ZXIgd2lsbCB1c2UgYSBkaWZmZXJlbnQgbm9uY2UgdXBvbiBib290aW5nIHVwLg0KPj4g DQo+PiBJbiBPU1BGIHRoZSBub25jZSBjb3VsZCBiZSBjYXJyaWVkIGluIHRoZSBIRUxMTyBwYWNr ZXRzLiBUaGVyZSBjb3VsZCBiZSBiaXQNCj4+IGNhcnJpZWQgaW4gdGhlIEhFTExPcyB3aGljaCB3 b3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSBIZWxsbyBpcyBjdXJyZW50bHkgdXNpbmcNCj4+IHRoZSBs b25nIGxpdmVkIGtleSAob3IgdGhlIFBTSykuIFRoZSByZWNlaXZlciB1cG9uIHJlY2VpdmluZyB0 aGlzIHdvdWxkDQo+PiBhdXRoZW50aWNhdGUgdGhlIHBhY2tldCB1c2luZyB0aGUgUFNLIGFuZCB3 b3VsZCB1c2UgdGhlIEtERiB0byBkZXJpdmUgdGhlDQo+PiB0cmFmZmljIGtleS4gVGhlIEtERiB3 b3VsZCBtaXggdGhlIG5vbmNlIHdpdGggdGhlIFBTSyBpbiBzb21lIGRldGVybWluaXN0aWMNCj4+ IGZhc2hpb24uIFRoZSByZWNlaXZlciB1c2VzIHRoZSBkZXJpdmVkIHRyYWZmaWMga2V5IGZvciBz aWduaW5nIGFsbCBzdWJzZXF1ZW50DQo+PiBPU1BGIHBhY2tldHMgYW5kIHdvdWxkIGluZGljYXRl IHRoaXMgYnkgc2V0dGluZyBzb21lIGJpdCAod2hpY2ggc2F5cyB1c2luZw0KPj4gdHJhZmZpYyBr ZXkpLiBJdCB3aWxsIGFsc28gaW5jbHVkZSBpdHMgb3duIG5vbmNlLiBUaGUgb3JpZ2luYWwgc2Vu ZGVyIG5vdyB1c2VzIHRoZQ0KPj4gbm9uY2UgdGhhdCBpdCByZWNlaXZlcyBhbmQgc3RhcnRzIHVz aW5nIHRoZSB0cmFmZmljIGtleSBkZXJpdmVkIGZyb20gdGhpcyBub25jZQ0KPj4gZm9yIGFsbCBz dWJzZXF1ZW50IHBhY2tldHMuIEZvciBhIGtleSByb2xsb3ZlciwgdGhlIHNlbmRlcnMganVzdCBo YXZlIHRvIGNob29zZQ0KPj4gYSBuZXcgbm9uY2UgdmFsdWUuIFRoaXMgY2FuIGJlIGRvbmUgYXMg ZnJlcXVlbnRseSBhcyBkZXNpcmVkIGFuZCByZXF1aXJlcyBubw0KPj4gbWFudWFsIGludGVydmVu dGlvbi4NCj4+IA0KPj4gRG9lcyB0aGlzIHNvdW5kIGFzIGdvaW5nIGluIHRoZSByaWdodCBkaXJl Y3Rpb24/DQo+PiANCj4+IENoZWVycywgTWFuYXYNCj4+IA0KPj4gLS0NCj4+IE1hbmF2IEJoYXRp YSwNCj4+IFNlcnZpY2UgUm91dGVyIFByb2R1Y3QgR3JvdXAgKFNSUEcpDQo+PiBBbGNhdGVsLUx1 Y2VudCwgSW5kaWENCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBrYXJwIG1haWxpbmcgbGlzdA0KPj4ga2FycEBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9rYXJwDQo= From manav.bhatia@alcatel-lucent.com Wed Apr 13 21:11:34 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D7C47E0707 for ; Wed, 13 Apr 2011 21:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.546 X-Spam-Level: X-Spam-Status: No, score=-4.546 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mZf7KReA+qa for ; Wed, 13 Apr 2011 21:11:29 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id C64EEE06F0 for ; Wed, 13 Apr 2011 21:11:29 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3E4BHLw018478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2011 23:11:19 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3E4BGUo022845 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Apr 2011 09:41:16 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 14 Apr 2011 09:41:16 +0530 Message-ID: <4DA673AE.9020400@alcatel-lucent.com> Date: Thu, 14 Apr 2011 09:40:22 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: "Dacheng Zhang(Dacheng)" References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 14 Apr 2011 04:11:35 -0000 Hi Dacheng, This mechanism will provide a seamless way to do a key rollover when using manual keying which i believe is one of the main things that KARP has been commissioned to work on. In fact, i believe that this will integrate very nicely with draft-ietf-karp-crypto-key-table-00 which can be extended to explain how the traffic keys should be used instead of the long lived PSKs. Please note that this is NOT an alternative to the KARP boot count approach as the latter is only meant for protecting against inter-session replays. This mechanism helps in implementing key rollover and as a by-product helps preventing inter-session replay attacks. This is not contending with a generic KMP that the KARP has to work on and is providing key rollovers when using manual keying. Cheers, Manav On 4/14/2011 9:20 AM, Dacheng Zhang(Dacheng) wrote: > Hi, Manav: > > I just handled my report and read your email. It seems that you are trying to implement some functions (generating session keys at run time) of an automatic of kmp into routing protocols instead of generating a generic KMP solution for different routing protocols? My concern is whether it is conflict with the objective of karp? > > Cheers > Dacheng > >>> -----ÓʼþÔ­¼þ----- >>> ·¢¼þÈË: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] ´ú±í Bhatia, >>> Manav (Manav) >>> ·¢ËÍʱ¼ä: 2011Äê4ÔÂ14ÈÕ 7:48 >>> ÊÕ¼þÈË: karp@ietf.org >>> Ö÷Ìâ: [karp] Using dynamically derived Traffic Keys for Routing Protocols >>> >>> Hi, >>> >>> Instead of using the pre shared key (PSK) in manual keying for all packets the >>> routing protocols could use a traffic key that's derived from the PSK using >>> some key derivation function. Each side could announce a random number (a >>> nonce) and the KDF could mix this with the PSK to derive the traffic key per >>> session. Benefits of this approach: >>> >>> o Key rollover becomes very easy as it's a local decision now requiring now >>> co-ordination with our peers. Each side can generate a new nonce and all >>> others recompute the traffic key based on the new nonce value. Attackers >>> cant inject packets with spurious nonces as this packet will be protected using >>> the traffic key based on the nonce that others have sent. >>> >>> o Avoids inter-session replay attacks without involving non volatile memory as >>> each router will use a different nonce upon booting up. >>> >>> In OSPF the nonce could be carried in the HELLO packets. There could be bit >>> carried in the HELLOs which would indicate that the Hello is currently using >>> the long lived key (or the PSK). The receiver upon receiving this would >>> authenticate the packet using the PSK and would use the KDF to derive the >>> traffic key. The KDF would mix the nonce with the PSK in some deterministic >>> fashion. The receiver uses the derived traffic key for signing all subsequent >>> OSPF packets and would indicate this by setting some bit (which says using >>> traffic key). It will also include its own nonce. The original sender now uses the >>> nonce that it receives and starts using the traffic key derived from this nonce >>> for all subsequent packets. For a key rollover, the senders just have to choose >>> a new nonce value. This can be done as frequently as desired and requires no >>> manual intervention. >>> >>> Does this sound as going in the right direction? >>> >>> Cheers, Manav >>> >>> -- >>> Manav Bhatia, >>> Service Router Product Group (SRPG) >>> Alcatel-Lucent, India >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp From curtis@occnc.com Wed Apr 13 21:14:15 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 782BDE07E4 for ; Wed, 13 Apr 2011 21:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3NDVLxf0R8u for ; Wed, 13 Apr 2011 21:14:14 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 98661E07C7 for ; Wed, 13 Apr 2011 21:14:14 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3E4ECck025945; Thu, 14 Apr 2011 00:14:12 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104140414.p3E4ECck025945@harbor.orleans.occnc.com> To: "Bhatia, Manav (Manav)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 05:17:50 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 14 Apr 2011 00:14:12 -0400 Sender: curtis@occnc.com Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com 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, 14 Apr 2011 04:14:15 -0000 In message <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > Hi, > > Instead of using the pre shared key (PSK) in manual keying for all > packets the routing protocols could use a traffic key that's derived > from the PSK using some key derivation function. Each side could > announce a random number (a nonce) and the KDF could mix this with the > PSK to derive the traffic key per session. Benefits of this approach: > > o Key rollover becomes very easy as it's a local decision now > requiring now co-ordination with our peers. Each side can generate a > new nonce and all others recompute the traffic key based on the new > nonce value. Attackers cant inject packets with spurious nonces as > this packet will be protected using the traffic key based on the nonce > that others have sent. > > o Avoids inter-session replay attacks without involving non volatile > memory as each router will use a different nonce upon booting up. > > In OSPF the nonce could be carried in the HELLO packets. There could > be bit carried in the HELLOs which would indicate that the Hello is > currently using the long lived key (or the PSK). The receiver upon > receiving this would authenticate the packet using the PSK and would > use the KDF to derive the traffic key. The KDF would mix the nonce > with the PSK in some deterministic fashion. The receiver uses the > derived traffic key for signing all subsequent OSPF packets and would > indicate this by setting some bit (which says using traffic key). It > will also include its own nonce. The original sender now uses the > nonce that it receives and starts using the traffic key derived from > this nonce for all subsequent packets. For a key rollover, the senders > just have to choose a new nonce value. This can be done as frequently > as desired and requires no manual intervention. > > Does this sound as going in the right direction? > > Cheers, Manav Manav, It seems like a good direction for any routing protocol, with the application to OSPF done in the HELLO. A shorter session key and more simple authentication method could be used with a strong persistent shared key and method for any protocol for which the authentication burden on each packet was considered too great a computational load to be practical with a long key and stronger algorithm. Another thing to consider in KARP is using two methods, a weak one with short key and a stronger one. The purpose of the weak one would be to toss out denial-of-service attack packets at the highest rate possible and the stronger method would only be used after the weaker passed. If packets start to arrive with the cheap authentication passing and the expensive one failing, then time to pick new keys. One of the reasons that vendors and providers don't like strong authentication and long keys is that it make a denial of service attack much more effective. This would eliminate that objections. Of course, line rate filtering as a first protection is still needed for high speed interfaces, particularly with boxes with lots of 10 Gb/s or 100 Gb/s interfaces. [Do they make 40G interfaces? :) ] Curtis > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India From vishwas.ietf@gmail.com Wed Apr 13 22:04:17 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5DC90E07FF for ; Wed, 13 Apr 2011 22:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LuFJd2PFO02 for ; Wed, 13 Apr 2011 22:04:16 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 4485DE07A3 for ; Wed, 13 Apr 2011 22:04:16 -0700 (PDT) Received: by pxi20 with SMTP id 20so755149pxi.27 for ; Wed, 13 Apr 2011 22:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8d5dKpdkikLqdXY+QlQFHhVFmwsGFIrbLK8i5mEKWD0=; b=YnlgnpxitPCX3m4rVcK5wDGD/0d25g29IP41nRdq3ayTCSMPV1UB6YHrZw0ArmZ50G zjw05WteG8/o01c+bhB8eilG//CSZ3H/1BO0t5BXyOnYb/SlU7ZHbAcl0enxnAmZq4TR zUL2cUEd1vAk/r5IwrO90h6Xp57KbVv7zPbW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X/p7zSGF453fdG8aJ/XvVEVBA4zl5fQNHlZ/cWD05yWpPLz/pcTwdgMETtsQ2TH+OC 2Zg8zJVX01vO0TVTEa5s2bRpxNVeAhFD+mpVBTdR4JwyVkcqr364RSU9TdJJaMuoO5Zf ZopiWUA3OWPnxK9KVzJ2KV528T7btlmO9FJLk= MIME-Version: 1.0 Received: by 10.68.6.35 with SMTP id x3mr119662pbx.463.1302757455510; Wed, 13 Apr 2011 22:04:15 -0700 (PDT) Received: by 10.68.41.163 with HTTP; Wed, 13 Apr 2011 22:04:15 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 13 Apr 2011 22:04:15 -0700 Message-ID: From: Vishwas Manral To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=bcaec53961085d3db604a0d9dbc6 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 14 Apr 2011 05:04:17 -0000 --bcaec53961085d3db604a0d9dbc6 Content-Type: text/plain; charset=ISO-8859-1 Hi Manav, Interesting. Isn't this what the Key tables draft already states? I guess what you are stating is how to use the Key Tables for OSPF right? Thanks, Vishwas On Wed, Apr 13, 2011 at 4:47 PM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > Hi, > > Instead of using the pre shared key (PSK) in manual keying for all packets > the routing protocols could use a traffic key that's derived from the PSK > using some key derivation function. Each side could announce a random number > (a nonce) and the KDF could mix this with the PSK to derive the traffic key > per session. Benefits of this approach: > > o Key rollover becomes very easy as it's a local decision now requiring now > co-ordination with our peers. Each side can generate a new nonce and all > others recompute the traffic key based on the new nonce value. Attackers > cant inject packets with spurious nonces as this packet will be protected > using the traffic key based on the nonce that others have sent. > > o Avoids inter-session replay attacks without involving non volatile memory > as each router will use a different nonce upon booting up. > > In OSPF the nonce could be carried in the HELLO packets. There could be bit > carried in the HELLOs which would indicate that the Hello is currently using > the long lived key (or the PSK). The receiver upon receiving this would > authenticate the packet using the PSK and would use the KDF to derive the > traffic key. The KDF would mix the nonce with the PSK in some deterministic > fashion. The receiver uses the derived traffic key for signing all > subsequent OSPF packets and would indicate this by setting some bit (which > says using traffic key). It will also include its own nonce. The original > sender now uses the nonce that it receives and starts using the traffic key > derived from this nonce for all subsequent packets. For a key rollover, the > senders just have to choose a new nonce value. This can be done as > frequently as desired and requires no manual intervention. > > Does this sound as going in the right direction? > > Cheers, Manav > > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > --bcaec53961085d3db604a0d9dbc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Manav,
=A0
Interesting. Isn't this what the Key tables draft already states?<= /div>
=A0
I guess what you are stating is how to use the Key Tables for OSPF rig= ht?
=A0
Thanks,
Vishwas
On Wed, Apr 13, 2011 at 4:47 PM, Bhatia, Manav (= Manav) <manav.bhatia@alcatel-lucent.com> wrote:
Hi,

Instead of using the = pre shared key (PSK) in manual keying for all packets the routing protocols= could use a traffic key that's derived from the PSK using some key der= ivation function. Each side could announce a random number (a nonce) and th= e KDF could mix this with the PSK to derive the traffic key per session. Be= nefits of this approach:

o Key rollover becomes very easy as it's a local decision now requi= ring now co-ordination with our peers. Each side can generate a new nonce a= nd all others recompute the traffic key based on the new nonce value. Attac= kers cant inject packets with spurious nonces as this packet will be protec= ted using the traffic key based on the nonce that others have sent.

o Avoids inter-session replay attacks without involving non volatile me= mory as each router will use a different nonce upon booting up.

In O= SPF the nonce could be carried in the HELLO packets. There could be bit car= ried in the HELLOs which would indicate that the Hello is currently using t= he long lived key (or the PSK). The receiver upon receiving this would auth= enticate the packet using the PSK and would use the KDF to derive the traff= ic key. The KDF would mix the nonce with the PSK in some deterministic fash= ion. The receiver uses the derived traffic key for signing all subsequent O= SPF packets and would indicate this by setting some bit (which says using t= raffic key). It will also include its own nonce. The original sender now us= es the nonce that it receives and starts using the traffic key derived from= this nonce for all subsequent packets. For a key rollover, the senders jus= t have to choose a new nonce value. This can be done as frequently as desir= ed and requires no manual intervention.

Does this sound as going in the right direction?

Cheers, Manav
--
Manav Bhatia,
Service Router Product= Group (SRPG)
Alcatel-Lucent, India
_________________________________= ______________
karp mailing list
karp@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/karp
<= br> --bcaec53961085d3db604a0d9dbc6-- From curtis@occnc.com Wed Apr 13 22:22:34 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C40BDE080B for ; Wed, 13 Apr 2011 22:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, CN_BODY_35=0.339] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwSlqxcEi-dC for ; Wed, 13 Apr 2011 22:22:34 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 00ED1E07A3 for ; Wed, 13 Apr 2011 22:22:33 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3E5M5G6031172; Thu, 14 Apr 2011 01:22:05 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104140522.p3E5M5G6031172@harbor.orleans.occnc.com> To: "Dacheng Zhang(Dacheng)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 03:50:53 -0000." Date: Thu, 14 Apr 2011 01:22:05 -0400 Sender: curtis@occnc.com Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com 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, 14 Apr 2011 05:22:34 -0000 In message "Dacheng Zhang(Dacheng)" writes: > > Hi, Manav: > > I just handled my report and read your email. It seems that you are > trying to implement some functions (generating session keys at run > time) of an automatic of kmp into routing protocols instead of > generating a generic KMP solution for different routing protocols? My > concern is whether it is conflict with the objective of karp? > > Cheers > Dacheng Dacheng, If a goal of KARP is to produce something secure *and deployable*, then a strong persistent key and a computationally more easy session key is a good idea. If the goals of KARP are limited to producing things that seem neat to security guys, then maybe not. Right now providers don't want to deploy strong authentication because is makes denial-of-service attacks more effective and DDOS attacks are considered a more real threat than any other for most providers. I think KARP is the right place to address that problem (with a usable solution, not with more complaints about strong authentication not being used). Curtis > >> -----ÓʼþÔ­¼þ----- > >> ·¢¼þÈË: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] ´ú±í Bhatia, > >> Manav (Manav) > >> ·¢ËÍʱ¼ä: 2011Äê4ÔÂ14ÈÕ 7:48 > >> ÊÕ¼þÈË: karp@ietf.org > >> Ö÷Ìâ: [karp] Using dynamically derived Traffic Keys for Routing Protocols > >> > >> Hi, > >> > >> Instead of using the pre shared key (PSK) in manual keying for all packets the > >> routing protocols could use a traffic key that's derived from the PSK using > >> some key derivation function. Each side could announce a random number (a > >> nonce) and the KDF could mix this with the PSK to derive the traffic key per > >> session. Benefits of this approach: > >> > >> o Key rollover becomes very easy as it's a local decision now requiring now > >> co-ordination with our peers. Each side can generate a new nonce and all > >> others recompute the traffic key based on the new nonce value. Attackers > >> cant inject packets with spurious nonces as this packet will be protected using > >> the traffic key based on the nonce that others have sent. > >> > >> o Avoids inter-session replay attacks without involving non volatile memory as > >> each router will use a different nonce upon booting up. > >> > >> In OSPF the nonce could be carried in the HELLO packets. There could be bit > >> carried in the HELLOs which would indicate that the Hello is currently using > >> the long lived key (or the PSK). The receiver upon receiving this would > >> authenticate the packet using the PSK and would use the KDF to derive the > >> traffic key. The KDF would mix the nonce with the PSK in some deterministic > >> fashion. The receiver uses the derived traffic key for signing all subsequent > >> OSPF packets and would indicate this by setting some bit (which says using > >> traffic key). It will also include its own nonce. The original sender now uses the > >> nonce that it receives and starts using the traffic key derived from this nonce > >> for all subsequent packets. For a key rollover, the senders just have to choose > >> a new nonce value. This can be done as frequently as desired and requires no > >> manual intervention. > >> > >> Does this sound as going in the right direction? > >> > >> Cheers, Manav > >> > >> -- > >> Manav Bhatia, > >> Service Router Product Group (SRPG) > >> Alcatel-Lucent, India > >> _______________________________________________ > >> 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 manav.bhatia@alcatel-lucent.com Wed Apr 13 22:28:58 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3A5DE06C8 for ; Wed, 13 Apr 2011 22:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRUAq3GWf1py for ; Wed, 13 Apr 2011 22:28:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id CB8ABE0670 for ; Wed, 13 Apr 2011 22:28:57 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3E5Srt5007426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2011 00:28:55 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3E5SqCJ023538 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Apr 2011 10:58:52 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 14 Apr 2011 10:58:52 +0530 Message-ID: <4DA685DD.7070007@alcatel-lucent.com> Date: Thu, 14 Apr 2011 10:57:57 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: Vishwas Manral References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 14 Apr 2011 05:28:58 -0000 No Vishwas, the key tables draft is not discussing this. Its different and is dealing with what the database should look like. It is also not (and it needn't) going into the details of how the short-lived key is derived from the long-lived keys. You can look at http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-layer-protection-03#page-17 to see how OSPF can use the Key Tables described in that draft. Cheers, Manav On 4/14/2011 10:34 AM, Vishwas Manral wrote: > Hi Manav, > Interesting. Isn't this what the Key tables draft already states? > I guess what you are stating is how to use the Key Tables for OSPF right? > Thanks, > Vishwas > On Wed, Apr 13, 2011 at 4:47 PM, Bhatia, Manav (Manav) > > wrote: > > Hi, > > Instead of using the pre shared key (PSK) in manual keying for all > packets the routing protocols could use a traffic key that's derived > from the PSK using some key derivation function. Each side could > announce a random number (a nonce) and the KDF could mix this with > the PSK to derive the traffic key per session. Benefits of this > approach: > > o Key rollover becomes very easy as it's a local decision now > requiring now co-ordination with our peers. Each side can generate a > new nonce and all others recompute the traffic key based on the new > nonce value. Attackers cant inject packets with spurious nonces as > this packet will be protected using the traffic key based on the > nonce that others have sent. > > o Avoids inter-session replay attacks without involving non volatile > memory as each router will use a different nonce upon booting up. > > In OSPF the nonce could be carried in the HELLO packets. There could > be bit carried in the HELLOs which would indicate that the Hello is > currently using the long lived key (or the PSK). The receiver upon > receiving this would authenticate the packet using the PSK and would > use the KDF to derive the traffic key. The KDF would mix the nonce > with the PSK in some deterministic fashion. The receiver uses the > derived traffic key for signing all subsequent OSPF packets and > would indicate this by setting some bit (which says using traffic > key). It will also include its own nonce. The original sender now > uses the nonce that it receives and starts using the traffic key > derived from this nonce for all subsequent packets. For a key > rollover, the senders just have to choose a new nonce value. This > can be done as frequently as desired and requires no manual > intervention. > > Does this sound as going in the right direction? > > Cheers, Manav > > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > > From zhangdacheng@huawei.com Wed Apr 13 23:41:04 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1C4ABE081C for ; Wed, 13 Apr 2011 23:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=3.662, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJqYKhOT6d+E for ; Wed, 13 Apr 2011 23:41:02 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id ABCAEE0670 for ; Wed, 13 Apr 2011 23:41:02 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00CGEQK6LX@szxga03-in.huawei.com> for karp@ietf.org; Thu, 14 Apr 2011 14:40:54 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM007SGQK676@szxga03-in.huawei.com> for karp@ietf.org; Thu, 14 Apr 2011 14:40:54 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Apr 2011 14:40:40 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 14 Apr 2011 14:40:54 +0800 Date: Thu, 14 Apr 2011 06:40:53 +0000 From: "Dacheng Zhang(Dacheng)" In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Originating-IP: [10.110.98.49] To: "Bhatia, Manav (Manav)" , "karp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Using dynamically derived Traffic Keys for Routing Protocols Thread-index: Acv6NTMFTlWOl/kBQCiD5tHWT/WyAQAODEvg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 14 Apr 2011 06:41:04 -0000 For a key rollover, the senders just have to choose >> a new nonce value. This can be done as frequently as desired and requires no >> manual intervention. >> [Dacheng Zhang] A very tiny comment here. Since OSPF provides Key ID, it may be possible to use nonce values and psk to generate a list of keys in one turn. So, two routers does not have to exchange nonce to update session keys. >> Does this sound as going in the right direction? >> >> Cheers, Manav >> >> -- >> Manav Bhatia, >> Service Router Product Group (SRPG) >> Alcatel-Lucent, India >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp From acee@lindem.com Thu Apr 14 02:36:45 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4664E0673 for ; Thu, 14 Apr 2011 02:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JET0mWFRKUds for ; Thu, 14 Apr 2011 02:36:45 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfc.amsl.com (Postfix) with ESMTP id 27B78E0669 for ; Thu, 14 Apr 2011 02:36:45 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=ToWar1fa9ljTHbeJIRNQycBnYxCRNi5M/11QAwRcJ6A= c=1 sm=0 a=dMhIGy2K6e0A:10 a=Wma4Of2gTTwA:10 a=_l4uJm6h9gAA:10 a=vBnH86IIPThSVV33hWu2Vw==:17 a=48vgC7mUAAAA:8 a=qJ_SmspoDris_7HNOlkA:9 a=EZEd6iV0TjM9t2MNkNwA:7 a=mFyHDrcPJccA:10 a=lZB815dzVvQA:10 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:55556] helo=[192.168.1.100]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 82/A4-29678-C20C6AD4; Thu, 14 Apr 2011 09:36:44 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=GB2312 From: Acee Lindem In-Reply-To: Date: Thu, 14 Apr 2011 05:36:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Dacheng Zhang(Dacheng)" X-Mailer: Apple Mail (2.1084) Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 14 Apr 2011 09:36:46 -0000 Hi Dacheng, I agree with Manav that the KMP protocol should provide the master keys = and the traffic or session keys should be derived by the individual = routing protocols.=20 Thanks, Acee=20 On Apr 13, 2011, at 11:50 PM, Dacheng Zhang(Dacheng) wrote: > Hi, Manav: >=20 > I just handled my report and read your email. It seems that you are = trying to implement some functions (generating session keys at run time) = of an automatic of kmp into routing protocols instead of generating a = generic KMP solution for different routing protocols? My concern is = whether it is conflict with the objective of karp? >=20 > Cheers > Dacheng >=20 >>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>> =B7=A2=BC=FE=C8=CB: karp-bounces@ietf.org = [mailto:karp-bounces@ietf.org] =B4=FA=B1=ED Bhatia, >>> Manav (Manav) >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C214=C8=D5 7:48 >>> =CA=D5=BC=FE=C8=CB: karp@ietf.org >>> =D6=F7=CC=E2: [karp] Using dynamically derived Traffic Keys for = Routing Protocols >>>=20 >>> Hi, >>>=20 >>> Instead of using the pre shared key (PSK) in manual keying for all = packets the >>> routing protocols could use a traffic key that's derived from the = PSK using >>> some key derivation function. Each side could announce a random = number (a >>> nonce) and the KDF could mix this with the PSK to derive the traffic = key per >>> session. Benefits of this approach: >>>=20 >>> o Key rollover becomes very easy as it's a local decision now = requiring now >>> co-ordination with our peers. Each side can generate a new nonce and = all >>> others recompute the traffic key based on the new nonce value. = Attackers >>> cant inject packets with spurious nonces as this packet will be = protected using >>> the traffic key based on the nonce that others have sent. >>>=20 >>> o Avoids inter-session replay attacks without involving non volatile = memory as >>> each router will use a different nonce upon booting up. >>>=20 >>> In OSPF the nonce could be carried in the HELLO packets. There could = be bit >>> carried in the HELLOs which would indicate that the Hello is = currently using >>> the long lived key (or the PSK). The receiver upon receiving this = would >>> authenticate the packet using the PSK and would use the KDF to = derive the >>> traffic key. The KDF would mix the nonce with the PSK in some = deterministic >>> fashion. The receiver uses the derived traffic key for signing all = subsequent >>> OSPF packets and would indicate this by setting some bit (which says = using >>> traffic key). It will also include its own nonce. The original = sender now uses the >>> nonce that it receives and starts using the traffic key derived from = this nonce >>> for all subsequent packets. For a key rollover, the senders just = have to choose >>> a new nonce value. This can be done as frequently as desired and = requires no >>> manual intervention. >>>=20 >>> Does this sound as going in the right direction? >>>=20 >>> Cheers, Manav >>>=20 >>> -- >>> Manav Bhatia, >>> Service Router Product Group (SRPG) >>> Alcatel-Lucent, India >>> _______________________________________________ >>> 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 zhangdacheng@huawei.com Thu Apr 14 03:05:52 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF008E06D8 for ; Thu, 14 Apr 2011 03:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.113 X-Spam-Level: X-Spam-Status: No, score=0.113 tagged_above=-999 required=5 tests=[AWL=-1.830, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMKZBtdr5ft6 for ; Thu, 14 Apr 2011 03:05:52 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id BB073E06AF for ; Thu, 14 Apr 2011 03:05:51 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJN00MYW013Q9@szxga05-in.huawei.com> for karp@ietf.org; Thu, 14 Apr 2011 18:05:27 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJN00NUR0123M@szxga05-in.huawei.com> for karp@ietf.org; Thu, 14 Apr 2011 18:05:27 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Apr 2011 18:05:22 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 14 Apr 2011 18:05:26 +0800 Date: Thu, 14 Apr 2011 10:05:25 +0000 From: "Dacheng Zhang(Dacheng)" In-reply-to: X-Originating-IP: [10.110.98.49] To: Acee Lindem Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-index: Acv6NTMFTlWOl/kBQCiD5tHWT/WyAQAIaYLQ///bIAD//3T48A== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 14 Apr 2011 10:05:53 -0000 SGksIA0KSSBoYXZlIHNlbnQgTWFuYXYgYSBwcml2YXRlIGVtYWlsIHNldmVyYWwgaG91cnMgYWdv LCAgaW4gd2hpY2ggSSBhZ3JlZWQgdGhhdCB0aGlzIHNvbHV0aW9uIGlzIGdvb2QgaW4gc2VjdXJp dHkuIEkganVzdCBkb24ndCBrbm93IHdoZXRoZXIgcGVvcGxlIHdpbGwgbGlrZSB0aGUgY29tcGxl eGl0eSBpbnRyb2R1Y2VkIGJ5IGludGVncmF0aW5nIHNlc3Npb24ga2V5IG1hbmFnZW1lbnQgaW50 byB0aGUgaW1wbGVtZW50YXRpb25zIG9mIHJvdXRpbmcgcHJvdG9jb2xzLiBJZiBwZW9wbGUgZG9u J3QgY2FyZSBhYm91dCB0aGlzIHByb2JsZW0sIHRoaXMgc29sdXRpb24gaXMgb2sgd2l0aCBtZSB0 b28uIF5fXg0KQ2hlZXJzDQoNCkRhY2hlbmcgDQoNCj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4g t6K8/sjLOiBBY2VlIExpbmRlbSBbbWFpbHRvOmFjZWVAbGluZGVtLmNvbV0NCj4+ILeiy83Ksbzk OiAyMDExxOo01MIxNMjVIDE3OjM3DQo+PiDK1bz+yMs6IERhY2hlbmcgWmhhbmcoRGFjaGVuZykN Cj4+ILOty806IEJoYXRpYSwgTWFuYXYgKE1hbmF2KTsga2FycEBpZXRmLm9yZw0KPj4g1vfM4jog UmU6IFtrYXJwXSBVc2luZyBkeW5hbWljYWxseSBkZXJpdmVkIFRyYWZmaWMgS2V5cyBmb3IgUm91 dGluZyBQcm90b2NvbHMNCj4+IA0KPj4gSGkgRGFjaGVuZywNCj4+IEkgYWdyZWUgd2l0aCBNYW5h diB0aGF0IHRoZSBLTVAgcHJvdG9jb2wgc2hvdWxkIHByb3ZpZGUgdGhlIG1hc3RlciBrZXlzIGFu ZA0KPj4gdGhlIHRyYWZmaWMgb3Igc2Vzc2lvbiBrZXlzIHNob3VsZCBiZSBkZXJpdmVkIGJ5IHRo ZSBpbmRpdmlkdWFsIHJvdXRpbmcNCj4+IHByb3RvY29scy4NCj4+IFRoYW5rcywNCj4+IEFjZWUN Cj4+IE9uIEFwciAxMywgMjAxMSwgYXQgMTE6NTAgUE0sIERhY2hlbmcgWmhhbmcoRGFjaGVuZykg d3JvdGU6DQo+PiANCj4+ID4gSGksIE1hbmF2Og0KPj4gPg0KPj4gPiBJIGp1c3QgaGFuZGxlZCBt eSByZXBvcnQgYW5kIHJlYWQgeW91ciBlbWFpbC4gSXQgc2VlbXMgdGhhdCB5b3UgYXJlIHRyeWlu ZyB0bw0KPj4gaW1wbGVtZW50IHNvbWUgZnVuY3Rpb25zIChnZW5lcmF0aW5nIHNlc3Npb24ga2V5 cyBhdCBydW4gdGltZSkgb2YgYW4NCj4+IGF1dG9tYXRpYyBvZiBrbXAgaW50byByb3V0aW5nIHBy b3RvY29scyBpbnN0ZWFkIG9mIGdlbmVyYXRpbmcgYSBnZW5lcmljIEtNUA0KPj4gc29sdXRpb24g Zm9yIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scz8gIE15IGNvbmNlcm4gaXMgd2hldGhlciBp dCBpcyBjb25mbGljdA0KPj4gd2l0aCB0aGUgb2JqZWN0aXZlIG9mIGthcnA/DQo+PiA+DQo+PiA+ IENoZWVycw0KPj4gPiBEYWNoZW5nDQo+PiA+DQo+PiA+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ PiA+Pj4gt6K8/sjLOiBrYXJwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzprYXJwLWJvdW5jZXNA aWV0Zi5vcmddILT6se0NCj4+IEJoYXRpYSwNCj4+ID4+PiBNYW5hdiAoTWFuYXYpDQo+PiA+Pj4g t6LLzcqxvOQ6IDIwMTHE6jTUwjE0yNUgNzo0OA0KPj4gPj4+IMrVvP7Iyzoga2FycEBpZXRmLm9y Zw0KPj4gPj4+INb3zOI6IFtrYXJwXSBVc2luZyBkeW5hbWljYWxseSBkZXJpdmVkIFRyYWZmaWMg S2V5cyBmb3IgUm91dGluZyBQcm90b2NvbHMNCj4+ID4+Pg0KPj4gPj4+IEhpLA0KPj4gPj4+DQo+ PiA+Pj4gSW5zdGVhZCBvZiB1c2luZyB0aGUgcHJlIHNoYXJlZCBrZXkgKFBTSykgaW4gbWFudWFs IGtleWluZyBmb3IgYWxsIHBhY2tldHMNCj4+IHRoZQ0KPj4gPj4+IHJvdXRpbmcgcHJvdG9jb2xz IGNvdWxkIHVzZSBhIHRyYWZmaWMga2V5IHRoYXQncyBkZXJpdmVkIGZyb20gdGhlIFBTSyB1c2lu Zw0KPj4gPj4+IHNvbWUga2V5IGRlcml2YXRpb24gZnVuY3Rpb24uIEVhY2ggc2lkZSBjb3VsZCBh bm5vdW5jZSBhIHJhbmRvbSBudW1iZXINCj4+IChhDQo+PiA+Pj4gbm9uY2UpIGFuZCB0aGUgS0RG IGNvdWxkIG1peCB0aGlzIHdpdGggdGhlIFBTSyB0byBkZXJpdmUgdGhlIHRyYWZmaWMga2V5IHBl cg0KPj4gPj4+IHNlc3Npb24uIEJlbmVmaXRzIG9mIHRoaXMgYXBwcm9hY2g6DQo+PiA+Pj4NCj4+ ID4+PiBvIEtleSByb2xsb3ZlciBiZWNvbWVzIHZlcnkgZWFzeSBhcyBpdCdzIGEgbG9jYWwgZGVj aXNpb24gbm93IHJlcXVpcmluZyBub3cNCj4+ID4+PiBjby1vcmRpbmF0aW9uIHdpdGggb3VyIHBl ZXJzLiBFYWNoIHNpZGUgY2FuIGdlbmVyYXRlIGEgbmV3IG5vbmNlIGFuZCBhbGwNCj4+ID4+PiBv dGhlcnMgcmVjb21wdXRlIHRoZSB0cmFmZmljIGtleSBiYXNlZCBvbiB0aGUgbmV3IG5vbmNlIHZh bHVlLiBBdHRhY2tlcnMNCj4+ID4+PiBjYW50IGluamVjdCBwYWNrZXRzIHdpdGggc3B1cmlvdXMg bm9uY2VzIGFzIHRoaXMgcGFja2V0IHdpbGwgYmUgcHJvdGVjdGVkDQo+PiB1c2luZw0KPj4gPj4+ IHRoZSB0cmFmZmljIGtleSBiYXNlZCBvbiB0aGUgbm9uY2UgdGhhdCBvdGhlcnMgaGF2ZSBzZW50 Lg0KPj4gPj4+DQo+PiA+Pj4gbyBBdm9pZHMgaW50ZXItc2Vzc2lvbiByZXBsYXkgYXR0YWNrcyB3 aXRob3V0IGludm9sdmluZyBub24gdm9sYXRpbGUNCj4+IG1lbW9yeSBhcw0KPj4gPj4+IGVhY2gg cm91dGVyIHdpbGwgdXNlIGEgZGlmZmVyZW50IG5vbmNlIHVwb24gYm9vdGluZyB1cC4NCj4+ID4+ Pg0KPj4gPj4+IEluIE9TUEYgdGhlIG5vbmNlIGNvdWxkIGJlIGNhcnJpZWQgaW4gdGhlIEhFTExP IHBhY2tldHMuIFRoZXJlIGNvdWxkIGJlDQo+PiBiaXQNCj4+ID4+PiBjYXJyaWVkIGluIHRoZSBI RUxMT3Mgd2hpY2ggd291bGQgaW5kaWNhdGUgdGhhdCB0aGUgSGVsbG8gaXMgY3VycmVudGx5DQo+ PiB1c2luZw0KPj4gPj4+IHRoZSBsb25nIGxpdmVkIGtleSAob3IgdGhlIFBTSykuIFRoZSByZWNl aXZlciB1cG9uIHJlY2VpdmluZyB0aGlzIHdvdWxkDQo+PiA+Pj4gYXV0aGVudGljYXRlIHRoZSBw YWNrZXQgdXNpbmcgdGhlIFBTSyBhbmQgd291bGQgdXNlIHRoZSBLREYgdG8gZGVyaXZlDQo+PiB0 aGUNCj4+ID4+PiB0cmFmZmljIGtleS4gVGhlIEtERiB3b3VsZCBtaXggdGhlIG5vbmNlIHdpdGgg dGhlIFBTSyBpbiBzb21lDQo+PiBkZXRlcm1pbmlzdGljDQo+PiA+Pj4gZmFzaGlvbi4gVGhlIHJl Y2VpdmVyIHVzZXMgdGhlIGRlcml2ZWQgdHJhZmZpYyBrZXkgZm9yIHNpZ25pbmcgYWxsDQo+PiBz dWJzZXF1ZW50DQo+PiA+Pj4gT1NQRiBwYWNrZXRzIGFuZCB3b3VsZCBpbmRpY2F0ZSB0aGlzIGJ5 IHNldHRpbmcgc29tZSBiaXQgKHdoaWNoIHNheXMNCj4+IHVzaW5nDQo+PiA+Pj4gdHJhZmZpYyBr ZXkpLiBJdCB3aWxsIGFsc28gaW5jbHVkZSBpdHMgb3duIG5vbmNlLiBUaGUgb3JpZ2luYWwgc2Vu ZGVyIG5vdyB1c2VzDQo+PiB0aGUNCj4+ID4+PiBub25jZSB0aGF0IGl0IHJlY2VpdmVzIGFuZCBz dGFydHMgdXNpbmcgdGhlIHRyYWZmaWMga2V5IGRlcml2ZWQgZnJvbSB0aGlzDQo+PiBub25jZQ0K Pj4gPj4+IGZvciBhbGwgc3Vic2VxdWVudCBwYWNrZXRzLiBGb3IgYSBrZXkgcm9sbG92ZXIsIHRo ZSBzZW5kZXJzIGp1c3QgaGF2ZSB0bw0KPj4gY2hvb3NlDQo+PiA+Pj4gYSBuZXcgbm9uY2UgdmFs dWUuIFRoaXMgY2FuIGJlIGRvbmUgYXMgZnJlcXVlbnRseSBhcyBkZXNpcmVkIGFuZCByZXF1aXJl cw0KPj4gbm8NCj4+ID4+PiBtYW51YWwgaW50ZXJ2ZW50aW9uLg0KPj4gPj4+DQo+PiA+Pj4gRG9l cyB0aGlzIHNvdW5kIGFzIGdvaW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24/DQo+PiA+Pj4NCj4+ ID4+PiBDaGVlcnMsIE1hbmF2DQo+PiA+Pj4NCj4+ID4+PiAtLQ0KPj4gPj4+IE1hbmF2IEJoYXRp YSwNCj4+ID4+PiBTZXJ2aWNlIFJvdXRlciBQcm9kdWN0IEdyb3VwIChTUlBHKQ0KPj4gPj4+IEFs Y2F0ZWwtTHVjZW50LCBJbmRpYQ0KPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+Pj4ga2FycCBtYWlsaW5nIGxpc3QNCj4+ID4+PiBrYXJw QGlldGYub3JnDQo+PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9r YXJwDQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiA+IGthcnAgbWFpbGluZyBsaXN0DQo+PiA+IGthcnBAaWV0Zi5vcmcNCj4+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9rYXJwDQoNCg== From vnktshsriram@gmail.com Thu Apr 14 08:51:08 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A214DE0718 for ; Thu, 14 Apr 2011 08:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEm+K4QhUz9c for ; Thu, 14 Apr 2011 08:51:07 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id 89082E06A4 for ; Thu, 14 Apr 2011 08:51:07 -0700 (PDT) Received: by qyk7 with SMTP id 7so1166570qyk.10 for ; Thu, 14 Apr 2011 08:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AsWO9q+QfFXVf//VprdsY3y9xlo4hkrIY8dHufStGIs=; b=Oj3fXIMXT6TbYWuvhOzs3vizh5GyK7wmxtuGrgheLT5AFEpUvdCwLyA9pCyEH6SCT0 TaFjKq6okMq1TIPF8FafNjWGJI0hwrWFG7ui0N+U56xfZl6rnBAXaN3irA1mLfprcqAO 1n7weu0AGsOVUgjKePxFtwFD3DwFM4056q/2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HgQepW3wbcfI/NU2Rlrcaas+lx60Pv8aFTxpbZ6g2L+r/3iXCQkmyJtz3IE7LNosy/ 9MzjqJNXxOvvSyJpUFEE1+ku8XFHVmVDKF2xuhtPEeKuTcLxQD1vJ63WeZyD6ZxhR+Rm rWWKD4sxCVcsikk7j5chC2lsgRPG2AVFE25vU= MIME-Version: 1.0 Received: by 10.52.69.140 with SMTP id e12mr1320201vdu.187.1302796266899; Thu, 14 Apr 2011 08:51:06 -0700 (PDT) Received: by 10.52.166.39 with HTTP; Thu, 14 Apr 2011 08:51:06 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 14 Apr 2011 21:21:06 +0530 Message-ID: From: Venkatesh Sriram To: "Bhatia, Manav (Manav)" , Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 14 Apr 2011 15:51:08 -0000 It would be great if someone can draft this idea (in Manav's original email) so that it becomes easier to track and follow. I believe this will work for IS-IS as well where this additional information needs to be passed in TLV 10. I like the idea of a KMP providing a long-lived key (or a shared secret when using manual keying) and the routing protocols deriving the short-term keys and using it internally themselves. This imo is completely within the charter of KARP. I also agree with what Curtis said earlier about this mechanism being applicable for regular key rollover - something that operators have been looking for since a long time now. Sriram From bew@cisco.com Thu Apr 14 15:17:40 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E52C1E0721 for ; Thu, 14 Apr 2011 15:17: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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOz9aYZhVZix for ; Thu, 14 Apr 2011 15:17:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 38F6AE0715 for ; Thu, 14 Apr 2011 15:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=240; q=dns/txt; s=iport; t=1302819460; x=1304029060; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=cm25Wc1B8TwNf1LbfQA2IesJb74QMwOS6Nzo7JIHZuY=; b=h8gSi5PtwrHzJP/kCSPAaXqe/iU8q0p1edB+oCvb88j5kb3n5Lk10o1I 5JaHr7ba+59nmk34AFHWUjELT6YgKGFxSqr0LkeMaWMSV9jpfa6I9trNY cG2vuOu20SgBlEE9aypi9kIrKPte1rD3/CSqB959+twNUhWjrDcbcHY7D 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMHAP1xp02rRDoG/2dsb2JhbACYPY0/d6cwnQuFbgSFWogV X-IronPort-AV: E=Sophos;i="4.64,213,1301875200"; d="scan'208";a="681697367" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2011 22:17:39 +0000 Received: from sjc-vpn7-34.cisco.com (sjc-vpn7-34.cisco.com [10.21.144.34]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3EMHdBG020591 for ; Thu, 14 Apr 2011 22:17:39 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 15:13:53 -0700 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [karp] KARP WG IETF 80 Minutes Posted 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, 14 Apr 2011 22:17:41 -0000 Greetings, The minutes for the KARP WG session have been made available in the = proceedings: . = Please send corrections to the list or privately to the chairs. Thanks, Brian= From vnktshsriram@gmail.com Thu Apr 14 17:28:41 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54E92E0677 for ; Thu, 14 Apr 2011 17:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnBLud2zFpg2 for ; Thu, 14 Apr 2011 17:28:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id A48FCE061E for ; Thu, 14 Apr 2011 17:28:40 -0700 (PDT) Received: by vws12 with SMTP id 12so2190272vws.31 for ; Thu, 14 Apr 2011 17:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=goT6pdh25+CuCGi4Rd/Wmhd84RfyBGJ6PpveYB0Lss0=; b=Fbp2DVCHM/wc1xtj+0nrqZfj6W4ismQ1o1oaSG5AMTwdaAcCuLdgVK6/ahwhu8CNyQ 1J+kkz4BQJdWPIse9tWmYTOvPOMz1C8VPsaWr2es758MM8M0iPLADBmi5c+fIX17n6vd t9jP0O64aS+lrPS2B8ySYC5xeY6bDc04FS1mU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rivahYOugmnfHZnmRzmvnZwq69N5voLY7/Xe8wabyntod1UfmQ/dEAP26oQVlhcRvN rr6HyU0digo825nJRPl/xvt0L+XB8SIVU7bUnfTAdvjxqVA6o0oL+y2wGXxmzrN8cCAi mVGdDF57Q4ZdX0W7gCD3mil4wb3YuyuNUrsN8= MIME-Version: 1.0 Received: by 10.52.97.99 with SMTP id dz3mr1986693vdb.267.1302827320430; Thu, 14 Apr 2011 17:28:40 -0700 (PDT) Received: by 10.52.166.39 with HTTP; Thu, 14 Apr 2011 17:28:40 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0DE216@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE216@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Fri, 15 Apr 2011 05:58:40 +0530 Message-ID: From: Venkatesh Sriram To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "karp@ietf.org" Subject: Re: [karp] PIM-SM Gap Analysis 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, 15 Apr 2011 00:28:41 -0000 Essentially what this draft says is that we need to get rid of IPsec as its unmanageable and people are not using it for securing PIM-SM. I agree to the latter part about people not using it for securing PIM-SM but not sure if you'll have enough people agreeing to the IPsec part - especially here in this WG! ;-) There has been work happening in OSPF WG on similar lines (replacing IPsec with some in-band mechanism) which has had significant support, so there are several people who echo this sentiment. Sriram On Wed, Apr 13, 2011 at 11:23 PM, Bhatia, Manav (Manav) wrote: > Hi, > > I have written a small draft that does security gap analysis for PIM-SM. I don't think its complete yet and could definitely do with some review from the KARP and the PIM WGs. > > URL for the draft: > http://www.ietf.org/id/draft-bhatia-karp-pim-gap-analysis-00.txt > > Cheers, Manav > > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From mjbarnes@cisco.com Thu Apr 14 17:41:53 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B06DE0679 for ; Thu, 14 Apr 2011 17:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAuWdYqlNaEl for ; Thu, 14 Apr 2011 17:41:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id C3895E065C for ; Thu, 14 Apr 2011 17:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mjbarnes@cisco.com; l=414; q=dns/txt; s=iport; t=1302828112; x=1304037712; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Y+RMSNw8f4hG2cBrnqYZOmIP9eLCHr3K4vxsM8v+aMg=; b=iMDi9NQ6GJI0zKgaEqMZOclQmf5C0h6aMLBmaYEvLRe3pTZQHX1PjA8z IZYwhM9eNHDY5rbOKaBo+I1DLKhXPryptw/e+MdJ83/60Zk3KTvxmC84X KX1LwP9tAVovLiznR6oxJyNkmZbJAITpRyyZa5WGNxJkcnkjaxLwaLxrn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkHABSTp02rRDoI/2dsb2JhbACYQI0/d6ctnQ+FbgSFWogVg3M X-IronPort-AV: E=Sophos;i="4.64,214,1301875200"; d="scan'208";a="681763988" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2011 00:41:52 +0000 Received: from [10.21.67.198] (sjc-vpn3-966.cisco.com [10.21.67.198]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3F0fqhL008542 for ; Fri, 15 Apr 2011 00:41:52 GMT Message-ID: <4DA7944F.4030302@cisco.com> Date: Thu, 14 Apr 2011 17:41:51 -0700 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: karp@ietf.org References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE216@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [karp] PIM-SM Gap Analysis 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, 15 Apr 2011 00:41:53 -0000 On 04/14/2011 05:28 PM, Venkatesh Sriram wrote: > There has been work happening in OSPF WG on similar lines (replacing > IPsec with some in-band mechanism) which has had significant support, Just a PoI regarding OSPFv3: I want to point out that IPsec will not be *replaced* by the new authentication mechanism, it's just another option. And folks *are* using IPsec to secure OSPFv3. Regards, Michael From vnktshsriram@gmail.com Thu Apr 14 17:59:30 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EA057E0865 for ; Thu, 14 Apr 2011 17:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS2vqIzFGnao for ; Thu, 14 Apr 2011 17:59:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 5C1C6E0711 for ; Thu, 14 Apr 2011 17:59:30 -0700 (PDT) Received: by vws12 with SMTP id 12so2204377vws.31 for ; Thu, 14 Apr 2011 17:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IGpGDEbil5pk4yn2/sbroAwo8ZNxp4bCqBD+Vo7lFEE=; b=eaD6DNayZlrWD+xUfRbn7NhbPYrgUXgRAxCX2gY7U34Dj1upnCwrTsnIbI8IRzW1ad U1PLV51Wpf7Zc7m6o6/iaM7QqcnRX8eHmoIzYs7LTsAjcFFqBaBS0vKx10ZvbAKpu5ie PnkzNLf3O4xt84xbIUYZX0qu9hyH2BkrjNyLw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QFEbvAI9S5YUoZQvSV61NYdQj/ZnYk6u2Y81umN20H8hWLnSPvJe0uLiZPfpwDv/e6 NZYjpKeMeTWByhvW6qruxCw70Xif/8xdyfLipExTvAaXjJM+GmkctC/K/QTHsZLpDxhz /6Eq6UmuE1GvM2ytdZ1pGvzNrijCM9/yK9vFk= MIME-Version: 1.0 Received: by 10.52.97.99 with SMTP id dz3mr2014986vdb.267.1302829169949; Thu, 14 Apr 2011 17:59:29 -0700 (PDT) Received: by 10.52.166.39 with HTTP; Thu, 14 Apr 2011 17:59:29 -0700 (PDT) In-Reply-To: <4DA7944F.4030302@cisco.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE216@INBANSXCHMBSA1.in.alcatel-lucent.com> <4DA7944F.4030302@cisco.com> Date: Fri, 15 Apr 2011 06:29:29 +0530 Message-ID: From: Venkatesh Sriram To: Michael Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] PIM-SM Gap Analysis 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, 15 Apr 2011 00:59:31 -0000 Yes, thats correct. I did not mean, as much as it appears from my mail, that IPsec will be entirely replaced by the new authentication mechanism. I am sure both will co-exist till there is enough motivation to move from one to the other. While there are several IPsec OSPFv3 deployments, i am not sure if you'll see the same number for PIM-SM. Sriram On Fri, Apr 15, 2011 at 6:11 AM, Michael Barnes wrote: > On 04/14/2011 05:28 PM, Venkatesh Sriram wrote: >> >> There has been work happening in OSPF WG on similar lines (replacing >> IPsec with some in-band mechanism) which has had significant support, > > Just a PoI regarding OSPFv3: I want to point out that IPsec will not be > *replaced* by the new authentication mechanism, it's just another option. > And folks *are* using IPsec to secure OSPFv3. > > Regards, > Michael > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From manav.bhatia@alcatel-lucent.com Thu Apr 14 21:00:08 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B77AE06AE for ; Thu, 14 Apr 2011 21:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-b99Q+Rme-A for ; Thu, 14 Apr 2011 21:00:07 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfc.amsl.com (Postfix) with ESMTP id C2A1EE06A6 for ; Thu, 14 Apr 2011 21:00:07 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p3F404Op004527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Apr 2011 23:00:06 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3F403jd027192 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 15 Apr 2011 09:30:03 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 15 Apr 2011 09:30:03 +0530 Message-ID: <4DA7C28C.5060406@alcatel-lucent.com> Date: Fri, 15 Apr 2011 09:29:08 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE216@INBANSXCHMBSA1.in.alcatel-lucent.com> <4DA7944F.4030302@cisco.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [karp] PIM-SM Gap Analysis 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, 15 Apr 2011 04:00:08 -0000 Hi Sriram, [clipped] > motivation to move from one to the other. While there are several > IPsec OSPFv3 deployments, i am not sure if you'll see the same number > for PIM-SM. That could probably be because RFC 5796 is just a year old, while RFC 4522 has been out there since almost 5+ years now. Cheers, Manav From Internet-Drafts@ietf.org Fri Apr 15 09:45:07 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 483F7130022; Fri, 15 Apr 2011 09:45:07 -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.152, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySSWN4VpyGns; Fri, 15 Apr 2011 09:45:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C7828130025; Fri, 15 Apr 2011 09:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110415164502.11592.74415.idtracker@ietfc.amsl.com> Date: Fri, 15 Apr 2011 09:45:02 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action:draft-ietf-karp-threats-reqs-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: Fri, 15 Apr 2011 16:45:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Keying and Authentication for Routing Protocols Working Group of the IETF. Title : The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports Author(s) : G. Lebovitz, et al. Filename : draft-ietf-karp-threats-reqs-02.txt Pages : 29 Date : 2011-04-15 Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document has two main parts - the first describes the threat analysis for attacks against routing protocols' transports and the second enumerates the requirements for addressing the described threats. This document, along with the KARP design guide and KARP framework documents, will be used by KARP design teams for specific protocol review and overhaul. This document reflects the input of both the IETF's Security Area and Routing Area in order to form a jointly agreed upon guidance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-karp-threats-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-15093937.I-D@ietf.org> --NextPart-- From manav.bhatia@alcatel-lucent.com Fri Apr 15 09:48:07 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AFB12130046 for ; Fri, 15 Apr 2011 09:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z69sk5p3-3IP for ; Fri, 15 Apr 2011 09:48:03 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id C7820130044 for ; Fri, 15 Apr 2011 09:48:03 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3FGlwrw017771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Apr 2011 11:48:01 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3FGlvIG007728 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 15 Apr 2011 22:17:57 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 15 Apr 2011 22:17:57 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Fri, 15 Apr 2011 22:17:57 +0530 Thread-Topic: draft-ietf-karp-threats-reqs updated Thread-Index: Acv7jN9HPSk8EEzQSCONMi4pWifn5A== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE777@INBANSXCHMBSA1.in.alcatel-lucent.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.35 Subject: [karp] draft-ietf-karp-threats-reqs updated 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, 15 Apr 2011 16:48:07 -0000 Hi, draft-ietf-karp-threats-reqs has been updated and can be found here: http://www.ietf.org/id/draft-ietf-karp-threats-reqs-02.txt Joel and Brian - This is ready to be handed off to the ADs. Design Guide too has been updated and is ready for the ADs: http://tools.ietf.org/html/draft-ietf-karp-design-guide-02 There is a nit on LDP pointed out by Mahesh in the design-guide that we are= planning to fix when we update the design guide based on the comments from= the ADs/IESG. Cheers, Manav -- Manav Bhatia, Service Router Product Group (SRPG) Alcatel-Lucent, India= From curtis@occnc.com Fri Apr 15 17:58:04 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8E16CE0680 for ; Fri, 15 Apr 2011 17:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHRPjSURv7oC for ; Fri, 15 Apr 2011 17:58:04 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 09309E061E for ; Fri, 15 Apr 2011 17:58:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G0vx2j079039; Fri, 15 Apr 2011 20:57:59 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160057.p3G0vx2j079039@harbor.orleans.occnc.com> To: "Dacheng Zhang(Dacheng)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 06:40:53 -0000." Date: Fri, 15 Apr 2011 20:57:59 -0400 Sender: curtis@occnc.com Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:58:04 -0000 In message "Dacheng Zhang(Dacheng)" writes: > > For a key rollover, the senders just have to choose > >> a new nonce value. This can be done as frequently as desired and requires no > >> manual intervention. > >> > [Dacheng Zhang] > > A very tiny comment here. Since OSPF provides Key ID, it may be > possible to use nonce values and psk to generate a list of keys in one > turn. So, two routers does not have to exchange nonce to update > session keys. That gives an attacker plenty of time to crack a session key since the exchange without a nonce can be replayed at any time and the old session key reused. > >> Does this sound as going in the right direction? > >> > >> Cheers, Manav > >> > >> -- > >> Manav Bhatia, > >> Service Router Product Group (SRPG) > >> Alcatel-Lucent, India From manav.bhatia@alcatel-lucent.com Sat Apr 16 17:44:23 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70DBEE0696 for ; Sat, 16 Apr 2011 17:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQWZ4zYeXpIs for ; Sat, 16 Apr 2011 17:44:22 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id BC27CE066C for ; Sat, 16 Apr 2011 17:44:22 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3H0iIh8026391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 16 Apr 2011 19:44:20 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3H0iFxl003945 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 17 Apr 2011 06:14:16 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sun, 17 Apr 2011 06:14:15 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Sun, 17 Apr 2011 06:12:58 +0530 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv6u8s9Ic+Vmh3kRWyLO+lfDI32uwB2tpow Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.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.37 Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 00:44:23 -0000 Hi, I have written the proposal in the draft format and its available here: http://www.ietf.org/id/draft-bhatia-karp-short-lived-keys-00.txt Would be great if folks can review and provide feedback on this. The propos= al in the draft is currently quite raw and I believe it requires quite a fe= w iterations before it becomes something that can be seriously considered a= s a direction that KARP should take wrt using short-lived keys for the rout= ing protocols (RPs). I am hoping that this will trigger some discussion whi= ch will provide more clarity on how RPs can make use of such keys. Cheers, Manav > -----Original Message----- > From: Venkatesh Sriram [mailto:vnktshsriram@gmail.com]=20 > Sent: Thursday, April 14, 2011 9.21 PM > To: Bhatia, Manav (Manav); Acee Lindem > Cc: karp@ietf.org > Subject: Re: [karp] Using dynamically derived Traffic Keys=20 > for Routing Protocols >=20 > It would be great if someone can draft this idea (in Manav's original > email) so that it becomes easier to track and follow. I believe this > will work for IS-IS as well where this additional information needs to > be passed in TLV 10. I like the idea of a KMP providing a long-lived > key (or a shared secret when using manual keying) and the routing > protocols deriving the short-term keys and using it internally > themselves. This imo is completely within the charter of KARP. I also > agree with what Curtis said earlier about this mechanism being > applicable for regular key rollover - something that operators have > been looking for since a long time now. >=20 > Sriram > = From mark.ietf@gmail.com Sun Apr 17 18:53:21 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 009EDE0757 for ; Sun, 17 Apr 2011 18:53:21 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfHLNXsFuMTq for ; Sun, 17 Apr 2011 18:53:20 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 34897E0665 for ; Sun, 17 Apr 2011 18:53:19 -0700 (PDT) Received: by iwn39 with SMTP id 39so4671888iwn.31 for ; Sun, 17 Apr 2011 18:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vrnEInz5YhR6kvk3dZ551A3CCRimGAiZmlhcefUJHvI=; b=I8glvjSjIG+rXVRfhKboUzGMjJfSzzUEezOGdKSS4Md/qH5N8xuDXjF5T+FL+NmPuW 4B3ANYWYy/GRWDyaVjTdIq4DplgaUi5Wn9B0UlXbmibBJIOjWDUYajPS1TdC96EE/mx3 0YR6sYnTzNHuw7zEgANZoWjP8t1BxFDvaEblI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oMh75vJbVHoXPDpgVaRY5HMWp7B2WjvONeQPg01zLYK6y75r8i2y/JDpvlTHrP8k6L NTXYYsbEIT4zLEY1i3AzwgBaSRpULUQ0SvJcr0vk7LyBNQ24nWl8b6NwrWBuNDXjqt5m hEYz8wA+SAqvXPKw89bCrfG5V1x5SZ5ibbRZY= MIME-Version: 1.0 Received: by 10.231.69.3 with SMTP id x3mr3321927ibi.125.1303091599501; Sun, 17 Apr 2011 18:53:19 -0700 (PDT) Received: by 10.231.199.67 with HTTP; Sun, 17 Apr 2011 18:53:19 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 18 Apr 2011 07:23:19 +0530 Message-ID: From: mark Brown To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 01:53:21 -0000 Hi Manav, The idea proposed in the short-lived-keys draft appears to be tenable. However, this draft is suggesting something very significant for the KARP almost under the hood - do we want the individual routing protocols to drive the key exchange or should it be left for a new automated key management protocol to do that? I understand that you assume that an AKM will do the long-lived key exchange and that you are only driving the traffic keys, however, just wanted to bring this up so that we have a consensus on this. I am not suggesting that i have an issue with your approach; am just trying to make it very explicit so that folks appreciate the design and the proposal before this is taken forward. My teeny-weeny nit with this idea is that it will require each routing protocol to individually do the traffic (or the short-lived key, as you put it) key exchange. I would rather see this offloaded to a new protocol that does just this. Ideally, the new protocol should exchange or negotiate a new session key that should be used by all routing and signaling protocols. BR, Mark On Sun, Apr 17, 2011 at 6:12 AM, Bhatia, Manav (Manav) wrote: > Hi, > > I have written the proposal in the draft format and its available here: > http://www.ietf.org/id/draft-bhatia-karp-short-lived-keys-00.txt > > Would be great if folks can review and provide feedback on this. The prop= osal in the draft is currently quite raw and I believe it requires quite a = few iterations before it becomes something that can be seriously considered= as a direction that KARP should take wrt using short-lived keys for the ro= uting protocols (RPs). I am hoping that this will trigger some discussion w= hich will provide more clarity on how RPs can make use of such keys. > > Cheers, Manav > >> -----Original Message----- >> From: Venkatesh Sriram [mailto:vnktshsriram@gmail.com] >> Sent: Thursday, April 14, 2011 9.21 PM >> To: Bhatia, Manav (Manav); Acee Lindem >> Cc: karp@ietf.org >> Subject: Re: [karp] Using dynamically derived Traffic Keys >> for Routing Protocols >> >> It would be great if someone can draft this idea (in Manav's original >> email) so that it becomes easier to track and follow. I believe this >> will work for IS-IS as well where this additional information needs to >> be passed in TLV 10. I like the idea of a KMP providing a long-lived >> key (or a shared secret when using manual keying) and the routing >> protocols deriving the short-term keys and using it internally >> themselves. This imo is completely within the charter of KARP. I also >> agree with what Curtis said earlier about this mechanism being >> applicable for regular key rollover - something that operators have >> been looking for since a long time now. >> >> Sriram >> > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From zhangdacheng@huawei.com Sun Apr 17 20:16:13 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F18D2E075E for ; Sun, 17 Apr 2011 20:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[AWL=2.899, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5bFZpH4YpFv for ; Sun, 17 Apr 2011 20:16:12 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 04476E06C1 for ; Sun, 17 Apr 2011 20:16:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJT00H6BVQL37@szxga03-in.huawei.com> for karp@ietf.org; Mon, 18 Apr 2011 11:15:57 +0800 (CST) Received: from szxeml204-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJT00K5KVQL02@szxga03-in.huawei.com> for karp@ietf.org; Mon, 18 Apr 2011 11:15:57 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 11:15:51 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 11:15:56 +0800 Date: Mon, 18 Apr 2011 03:15:55 +0000 From: "Dacheng Zhang(Dacheng)" In-reply-to: X-Originating-IP: [10.110.98.55] To: mark Brown , "Bhatia, Manav (Manav)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-index: AQHL/WutGN7h/5ghHkmAPGiIcnx8IpRi7wYA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 03:16:13 -0000 >> My teeny-weeny nit with this idea is that it will require each routing >> protocol to individually do the traffic (or the short-lived key, as >> you put it) key exchange. I would rather see this offloaded to a new >> protocol that does just this. Ideally, the new protocol should >> exchange or negotiate a new session key that should be used by all >> routing and signaling protocols. >> [Dacheng Zhang] In my previous emails, I showed a similar opinion with you. That is, it may be worthwhile for people to discuss which solution is more preferred: Designing a generic traffic key generating protocol or implement the correspondent functionality within different routing protocols respectively. We also need to decide is that whether the automatic key management system going to be proposed by Karp should deal with the traffic key generating issue or just leave it to routing protocols. Cheers Dacheng >> BR, >> Mark >> >> On Sun, Apr 17, 2011 at 6:12 AM, Bhatia, Manav (Manav) >> wrote: >> > Hi, >> > >> > I have written the proposal in the draft format and its available here: >> > http://www.ietf.org/id/draft-bhatia-karp-short-lived-keys-00.txt >> > >> > Would be great if folks can review and provide feedback on this. The proposal >> in the draft is currently quite raw and I believe it requires quite a few >> iterations before it becomes something that can be seriously considered as a >> direction that KARP should take wrt using short-lived keys for the routing >> protocols (RPs). I am hoping that this will trigger some discussion which will >> provide more clarity on how RPs can make use of such keys. >> > >> > Cheers, Manav >> > >> >> -----Original Message----- >> >> From: Venkatesh Sriram [mailto:vnktshsriram@gmail.com] >> >> Sent: Thursday, April 14, 2011 9.21 PM >> >> To: Bhatia, Manav (Manav); Acee Lindem >> >> Cc: karp@ietf.org >> >> Subject: Re: [karp] Using dynamically derived Traffic Keys >> >> for Routing Protocols >> >> >> >> It would be great if someone can draft this idea (in Manav's original >> >> email) so that it becomes easier to track and follow. I believe this >> >> will work for IS-IS as well where this additional information needs to >> >> be passed in TLV 10. I like the idea of a KMP providing a long-lived >> >> key (or a shared secret when using manual keying) and the routing >> >> protocols deriving the short-term keys and using it internally >> >> themselves. This imo is completely within the charter of KARP. I also >> >> agree with what Curtis said earlier about this mechanism being >> >> applicable for regular key rollover - something that operators have >> >> been looking for since a long time now. >> >> >> >> Sriram >> >> >> > _______________________________________________ >> > 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 uma.chunduri@ericsson.com Sun Apr 17 20:40:11 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00C66E067F for ; Sun, 17 Apr 2011 20:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXbtdKJsE+ew for ; Sun, 17 Apr 2011 20:40:10 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 100A9E0661 for ; Sun, 17 Apr 2011 20:40:09 -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 p3I3e49J015974; Sun, 17 Apr 2011 22:40:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 17 Apr 2011 23:40:03 -0400 From: Uma Chunduri To: mark Brown , "Bhatia, Manav (Manav)" Date: Sun, 17 Apr 2011 23:40:01 -0400 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv9a2e3t7t8V/3iTp6fz06kpjlfUgACrJqAAAEKvEA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.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 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 03:40:11 -0000 I fundamentally oppose this idea of deriving traffic keys with individual R= Ps.=20 I have to say this is not conceived well. Why? - All key derivation long/short should be function of AKMs and RP must no= t do this to keep clean separation for all security aspects while generating keys - One immediate thing comes to my mind is PFS (perfect forward secrecy) - think of extensibility (it's lost) I am not sure if this is part of KARP design guidelines, if not this should= be included. RP's should just focus on using keys (get these manually or through AKM). Regards, -Uma -----Original Message----- From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of mar= k Brown Sent: Sunday, April 17, 2011 6:53 PM To: Bhatia, Manav (Manav) Cc: karp@ietf.org Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Prot= ocols Hi Manav, The idea proposed in the short-lived-keys draft appears to be tenable. However, this draft is suggesting something very significant for the KARP a= lmost under the hood - do we want the individual routing protocols to driv= e the key exchange or should it be left for a new automated key management = protocol to do that? I understand that you assume that an AKM will do the l= ong-lived key exchange and that you are only driving the traffic keys, howe= ver, just wanted to bring this up so that we have a consensus on this. I am not suggesting that i have an issue with your approach; am just trying= to make it very explicit so that folks appreciate the design and the propo= sal before this is taken forward. My teeny-weeny nit with this idea is that it will require each routing prot= ocol to individually do the traffic (or the short-lived key, as you put it)= key exchange. I would rather see this offloaded to a new protocol that doe= s just this. Ideally, the new protocol should exchange or negotiate a new s= ession key that should be used by all routing and signaling protocols. BR, Mark On Sun, Apr 17, 2011 at 6:12 AM, Bhatia, Manav (Manav) wrote: > Hi, > > I have written the proposal in the draft format and its available here: > http://www.ietf.org/id/draft-bhatia-karp-short-lived-keys-00.txt > > Would be great if folks can review and provide feedback on this. The prop= osal in the draft is currently quite raw and I believe it requires quite a = few iterations before it becomes something that can be seriously considered= as a direction that KARP should take wrt using short-lived keys for the ro= uting protocols (RPs). I am hoping that this will trigger some discussion w= hich will provide more clarity on how RPs can make use of such keys. > > Cheers, Manav > >> -----Original Message----- >> From: Venkatesh Sriram [mailto:vnktshsriram@gmail.com] >> Sent: Thursday, April 14, 2011 9.21 PM >> To: Bhatia, Manav (Manav); Acee Lindem >> Cc: karp@ietf.org >> Subject: Re: [karp] Using dynamically derived Traffic Keys for=20 >> Routing Protocols >> >> It would be great if someone can draft this idea (in Manav's original >> email) so that it becomes easier to track and follow. I believe this=20 >> will work for IS-IS as well where this additional information needs=20 >> to be passed in TLV 10. I like the idea of a KMP providing a=20 >> long-lived key (or a shared secret when using manual keying) and the=20 >> routing protocols deriving the short-term keys and using it=20 >> internally themselves. This imo is completely within the charter of=20 >> KARP. I also agree with what Curtis said earlier about this mechanism=20 >> being applicable for regular key rollover - something that operators=20 >> have been looking for since a long time now. >> >> Sriram >> > _______________________________________________ > 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 uma.chunduri@ericsson.com Sun Apr 17 20:47:16 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 177BBE0661 for ; Sun, 17 Apr 2011 20:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFkvWTrwrHJJ for ; Sun, 17 Apr 2011 20:47:15 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 8E759E0660 for ; Sun, 17 Apr 2011 20:47:15 -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 p3I3l8DA016204; Sun, 17 Apr 2011 22:47:10 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 17 Apr 2011 23:47:02 -0400 From: Uma Chunduri To: "Dacheng Zhang(Dacheng)" , mark Brown , "Bhatia, Manav (Manav)" Date: Sun, 17 Apr 2011 23:47:01 -0400 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: AQHL/WutGN7h/5ghHkmAPGiIcnx8IpRi7wYAgAAL9MA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.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 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 03:47:16 -0000 =20 [Dacheng Zhang] In my previous emails, I showed a similar opinion with you. That is, it may= be worthwhile for people to discuss which solution is more preferred: Desi= gning a generic traffic key generating protocol or implement the correspond= ent functionality within different routing protocols respectively.=20 We also need to decide is that whether the automatic key management system = going to be proposed by Karp should deal with the traffic key generating is= sue or just leave it to routing protocols. [Uma] I strongly feel, AKM should also deal with traffic key generation and= RPs should not be involved. Regards, -Uma From vnktshsriram@gmail.com Mon Apr 18 06:29:04 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9C80AE07D9 for ; Mon, 18 Apr 2011 06:29:04 -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=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wvd-dI+AkP4 for ; Mon, 18 Apr 2011 06:29:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 278E1E07E4 for ; Mon, 18 Apr 2011 06:29:02 -0700 (PDT) Received: by vxg33 with SMTP id 33so4386899vxg.31 for ; Mon, 18 Apr 2011 06:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/Ppwr2l0C0nfwDSUTsEWWU1mdr54YFBdQAGrQR4vkxo=; b=qKUboeE/IfEiEhgjUX/siD1lXDxiZZmM/P7EJWG0TS81IZALXS4mZba5Zy5VVXOm6B 5ziJGuN/z8IUioVp1Y/V7T7fCmACluUglL/nfj21qk8dZzDjx9BD+wysl7C4/cM72I+a +8FwH+qWVjh/dCWgPmG22rvmzqlJ9Z4BhlzPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pzmq0qwI7LzcdT+gIB2d1uENR6QP68UYYEHDpygXb001f0KzNuAVL+/F/DlIfVXcuc R6Zw0Or2561v3DSV4zwVMvJZciDypgRUw2Y2MFxn5RbzxT5D3NZKh7+6dBqYE/FgZjzG 5nfLaofrDCopPo0VGON5EF6xGmb9JO/eFXgag= MIME-Version: 1.0 Received: by 10.52.178.196 with SMTP id da4mr6950064vdc.227.1303133341807; Mon, 18 Apr 2011 06:29:01 -0700 (PDT) Received: by 10.52.166.39 with HTTP; Mon, 18 Apr 2011 06:29:01 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 18 Apr 2011 18:59:01 +0530 Message-ID: From: Venkatesh Sriram To: Uma Chunduri Content-Type: text/plain; charset=ISO-8859-1 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 13:29:04 -0000 > I fundamentally oppose this idea of deriving traffic keys > with individual RPs. > I have to say this is not conceived well. > > Why? > - All key derivation long/short should be function of AKMs I am not sure I understand why you want the AKMs to exchange both the long-lived and the short-lived keys? Cant they just exchange the former and let a "KARP" module sitting on each router derive the short-lived keys? Alternately, if the AKM can exchange short-lived keys, why does it need to bother with exchanging the long-lived keys? > and RP must not do this > to keep clean separation for all security aspects while > generating keys I think we had envisaged this "KARP" module that would sit in each router that the routing protocols would interact with to derive the session keys. > - One immediate thing comes to my mind is PFS (perfect > forward secrecy) Isnt this true whenever you have a session key being derived from a long-lived key? > - think of extensibility (it's lost) Mind elaborating. > > I am not sure if this is part of KARP design guidelines, if > not this should be included. > RP's should just focus on using keys (get these manually or > through AKM). But pray, why? Sriram From hartmans@mit.edu Mon Apr 18 10:57:26 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71A12E066B for ; Mon, 18 Apr 2011 10:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8TljU-7U7Ip for ; Mon, 18 Apr 2011 10:57:25 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id D9A47E0669 for ; Mon, 18 Apr 2011 10:57: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 71668203B1; Mon, 18 Apr 2011 13:53:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2065F4541; Mon, 18 Apr 2011 13:57:16 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 18 Apr 2011 13:57:16 -0400 In-Reply-To: (Uma Chunduri's message of "Sun, 17 Apr 2011 23:40:01 -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] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 17:57:26 -0000 >>>>> "Uma" == Uma Chunduri writes: Uma> I fundamentally oppose this idea of deriving traffic keys with Uma> individual RPs. I have to say this is not conceived well. Uma> Why? - All key derivation long/short should be function of Uma> AKMs and RP must not do this to keep clean separation for all Uma> security aspects while generating keys - One immediate thing Uma> comes to my mind is PFS (perfect forward secrecy) - think of Uma> extensibility (it's lost) I'm sorry. I do agree that we need to think through the proposal of using a KDF to generate short-lived session keys more. At least some of the claims made about it don't make sense to me. However, it seems useful as good security design and as protection from related key attacks. Also, in cases where it works out, it may help with replay protection. The approach of using a key derivation function has been discussed at several meetings, as well as in section 4.1 of draft-ietf-karp-ops-model, Tim Polk's draft on how to use the crypto tables, and the crypto tables draft themselves. I believe that TCP AO assumes a key derivation function similar to what Manav proposes. so, while I agree we need to work through the ideas, I'm having trouble coming up with a justification for a response like "fundamentally broken." Can you help us all by working through your concerns in more detail? I'd like to take two concerns you have. First, the idea of PFS. PFS implies secrecy. Confidentiality is explicitly out of scope for KARP. So, I don't understand how PFS is valuable to us. There's something related to PFS that is valuable: known good key material absent an active attack. That argues for an AKM protocl and some sort of DH exchange in that protocol. However, that doesn't mean key derivation cannot be used. You argue that for design cleanlyness, key derivation should not be part of the integrity protocol. However, I think we have numerous examples of security protocols that seem to have reasonably clean separation and that perform this sort of key derivation. I'll put forward TCP AO, and the cryptographic primitives defined in RFC 3961 for Kerberos as specific examples. (I'm not proposing using RFC 3961 in KARP, simply arguing that we have lots of cases in the IETF where we've done this before.) From uma.chunduri@ericsson.com Mon Apr 18 14:33:44 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 264A6E079D for ; Mon, 18 Apr 2011 14:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1wefblVUwwE for ; Mon, 18 Apr 2011 14:33:43 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 46CA6E0786 for ; Mon, 18 Apr 2011 14:33:40 -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 p3ILCsc3031856; Mon, 18 Apr 2011 16:12:55 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 18 Apr 2011 17:12:48 -0400 From: Uma Chunduri To: Sam Hartman Date: Mon, 18 Apr 2011 17:12:48 -0400 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv98iPeW1G8Ldj/Sn2pB0M4jEuYTgAD/wcg Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.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 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 21:33:44 -0000 so, while I agree we need to work through the ideas, I'm having trouble com= ing up with a justification for a response like "fundamentally broken." Can you help us all by working through your concerns in more detail? I'd like to take two concerns you have. First, the idea of PFS. PFS implies secrecy. Confidentiality is explicitly out of scope for KARP. S= o, I don't understand how PFS is valuable to us. [Uma] No, PFS doesn't imply confidentiality. All It all imply, if it requir= ed is - one should not use not only long term keys derived from some=20 form of DH exchange but also should not use any keying material assoc= iated with it. =20 There's something related to PFS that is valuable: known good key material = absent an active attack. That argues for an AKM protocl and some sort of DH exchange in that protoco= l. However, that doesn't mean key derivation cannot be used. [Uma] I am not saying key derivation cannot be used. If PFS is required, no= w RPs should do DH exchange and this won't stop there. I definitely see this as a slippery-slope and PFS is only one example= . You argue that for design cleanlyness, key derivation should not be part of= the integrity protocol. [Uma] integrity protocol?? You mean Routing protocol? The last thing a routing protocol implementation has to worry about i= s randomness of pseudo-random numbers generated to=20 derive keys and if it is FIPS complaint/pass security audits. Well al= l this can be done my question is why to develop this redundancy? why not to use the AKM= that is being used to get long-term keys to start with and use key-tables = effectively=20 to select the traffic keys rather than building part of AKM job in al= l routing protocols. =20 =20 =20 =20 From vnktshsriram@gmail.com Mon Apr 18 14:39:34 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E9804E07F3 for ; Mon, 18 Apr 2011 14:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4YPTe7y0QkJ for ; Mon, 18 Apr 2011 14:39:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 54F34E07EA for ; Mon, 18 Apr 2011 14:39:34 -0700 (PDT) Received: by vws12 with SMTP id 12so4835808vws.31 for ; Mon, 18 Apr 2011 14:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K+bCYd5bbd3FZq90SBToKpQqy3dDHu2d0h9gMcaIeU0=; b=vjloj/kIrVbFOy+O/BdPLjmxTFk1wYf/CqUyrhRDEYde1iKouvrVPVqizx3l28S664 G/PCVm7Gr3+rYRRbUVFh0Z2uLtM8F21L6vED74PzLUqZ5OU6RjnWz0/nmge8HwKvGGbM FPw/VUm/P1iO9ro7fxVTMmpFxMM2JMKVMAYXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dj7La7wY5fT7H6uNkkRKtLYISnrblQdVrx5oUiSRK142LpQRds2ijLDEDnpv5zCJxW jnhrGVyvfQHyPI5vSKDOxsr3QG3bJa1OnUhI365+1e5CyLlZNoZ3JT0tPYuU4qBQiaAh PEoPCWqaLOA70srfh5/zb86+WvFb7RvHhSvVM= MIME-Version: 1.0 Received: by 10.52.95.196 with SMTP id dm4mr2561659vdb.147.1303162773805; Mon, 18 Apr 2011 14:39:33 -0700 (PDT) Received: by 10.52.166.39 with HTTP; Mon, 18 Apr 2011 14:39:33 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 19 Apr 2011 03:09:33 +0530 Message-ID: From: Venkatesh Sriram To: Uma Chunduri Content-Type: text/plain; charset=ISO-8859-1 Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 21:39:35 -0000 > [Uma] No, PFS doesn't imply confidentiality. All It all > imply, if it required is - one should not use not only long > term keys derived from some > form of DH exchange but also should not use any keying > material associated with it. Are you suggesting that we should not use short-lived keys from a long-lived key? > > You argue that for design cleanlyness, key derivation should > not be part of the integrity protocol. > > [Uma] integrity protocol?? You mean Routing protocol? > The last thing a routing protocol implementation has to > worry about is randomness of pseudo-random numbers generated to > derive keys and if it is FIPS complaint/pass security RPs can speak to the "KARP module" and get all that information - they dont need to do this themselves. This module can be written and owned by the security experts. There btw are already proposals for extending RPs to generate Nonces - You can look at draft-bhatia-karp-ospf-ip-layer-protection-03 for more details. > audits. Well all this can be done > my question is why to develop this redundancy? why not > to use the AKM that is being used to get long-term keys to > start with and use key-tables effectively > to select the traffic keys rather than building part of > AKM job in all routing protocols. The key tables draft mostly talks about associating a life time with keys so that a rollover can be implemented. I dont think it mentions anything about *how* the session keys can be derived. I think the essence of Manav's proposal is that we use a session key instead of a long-lived key to secure the routing protocols. Lets us first start by discussing whether we agree to this proposal or not. If we do agree, then we can look at how the session keys may be derived. However, if it turns out that people dont agree with using the session keys, then the whole discussion is moot. My vote is to use the session keys derived from the long-lived keys, simply because we shouldnt be using the long-lived key a lot. I would rather that peers exchange one long-lived key and then let different protocols derive different session keys and use that for their exchange instead of having every protocol use the same long-lived key. From hartmans@mit.edu Mon Apr 18 14:42:42 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7290BE07F3 for ; Mon, 18 Apr 2011 14:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlrYEGrTwkc8 for ; Mon, 18 Apr 2011 14:42:41 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id AF5B1E0718 for ; Mon, 18 Apr 2011 14:42:41 -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 A7D92204AB; Mon, 18 Apr 2011 17:39:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2F8664541; Mon, 18 Apr 2011 17:42:28 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 18 Apr 2011 17:42:28 -0400 In-Reply-To: (Uma Chunduri's message of "Mon, 18 Apr 2011 17:12:48 -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" , Sam Hartman Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 21:42:42 -0000 >>>>> "Uma" == Uma Chunduri writes: There are two reasons I think we need KDFs. 1) deal with related key attacks 2) Several issues that come up in deployments where there is no AKM. Uma> [Uma] I am not saying key derivation cannot be used. If PFS is Uma> required, now RPs should do DH exchange and this won't stop Uma> there. I definitely see this as a slippery-slope and PFS is Uma> only one example. I'm sorry, I'm not seeing the slope. I need to ask you to enumerate all the examples or at least enough of them to see a slope. Later, you talk about the quality of random numbers for a KDF. In this sort of case I'd expect the only input to the KDF that needs to be random is the key. Yes, we'll care about the cryptographic quality of the KDF, but that's not too hard to deal with. From glen.kent@gmail.com Mon Apr 18 14:56:41 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4FCA5E075C for ; Mon, 18 Apr 2011 14:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVd6+IdIVvLp for ; Mon, 18 Apr 2011 14:56:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id BDE12E071D for ; Mon, 18 Apr 2011 14:56:40 -0700 (PDT) Received: by vws12 with SMTP id 12so4846077vws.31 for ; Mon, 18 Apr 2011 14:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3dd1ZUzNgBa61eOoV3S2TKwmJWeqPLppXUsGOtYw95E=; b=nJiwiM+LqyJtrAwrVbiOL7lewMijpA+CuYraBLZ1jnRz7/dM8RCLg60GcofzbQ+jAL Y456AvpXs94uMfBhn4c8gvI3eVkmv2yXAnNWS3mQiyM12WM9yXxmh9I9pa7LOQjsaRrZ fEihCn03u69jDYE4uS5kQ69/psIBmJt1lBKS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kVPWFdrKBa/DeQrqkQposasJrDy2l5aUhXJX+5v+JrrrW6RDRWlSTURBgODBXvJ3eZ 9u39f7IdD3fDP6IOEogYCwGMK5QTYLBjCqKuMtnm69xupFS/mpNNjM66B/ZtqyomnEc6 JvDJofvP9BFWWUDYY05ctVuC+kWfHgt7kD9y0= MIME-Version: 1.0 Received: by 10.52.18.72 with SMTP id u8mr8038627vdd.290.1303163800406; Mon, 18 Apr 2011 14:56:40 -0700 (PDT) Received: by 10.52.166.193 with HTTP; Mon, 18 Apr 2011 14:56:40 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 19 Apr 2011 03:26:40 +0530 Message-ID: From: Glen Kent To: Venkatesh Sriram Content-Type: text/plain; charset=ISO-8859-1 Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 21:56:41 -0000 Hi Sriram, > I think the essence of Manav's proposal is that we use a session key > instead of a long-lived key to secure the routing protocols. Lets us > first start by discussing whether we agree to this proposal or not. If > we do agree, then we can look at how the session keys may be derived. > However, if it turns out that people dont agree with using the session > keys, then the whole discussion is moot. > I think this is briefly discussed in Section 2 and 3 of draft-bhatia-karp-short-lived-keys-00.txt and i would tend to agree with Manav there. > My vote is to use the session keys derived from the long-lived keys, > simply because we shouldnt be using the long-lived key a lot. I would > rather that peers exchange one long-lived key and then let different > protocols derive different session keys and use that for their > exchange instead of having every protocol use the same long-lived key. +1 Glen From glen.kent@gmail.com Mon Apr 18 15:01:18 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70CE0E082A for ; Mon, 18 Apr 2011 15:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6qOg+NGSCqq for ; Mon, 18 Apr 2011 15:01:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id F3445E06F7 for ; Mon, 18 Apr 2011 15:01:17 -0700 (PDT) Received: by vws12 with SMTP id 12so4849042vws.31 for ; Mon, 18 Apr 2011 15:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I+BCMtporoZvmiwtknrC2sv/fklcKUd5y/90r8V7Lj4=; b=V4kFa99bn549kJExan7k3nxgoHmPqbIcB1tr6pzdVCD3v0wAFAIeclEFR0lCo2qrAU ukcB8TU0HTbJz1qwx32zg6jXW5jrXAzFZQv1uF7OftR64IMN4MoWi+QQgOe1EOaBJ4Fi C0o7h1jugviSl2g+ejqkVAjvLwOgsCO9vRShY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yxl6cgnmVdUdK8z/9hWBhNwMriN1SltIoc0ghFbEmCVZbrLPY2Vzs1iY9d1LxNsTQ0 Zys5ILuFBW7yNa8ktmf2BNVEdMpnLpmWbMLVB3X12sosOmY6z32+nYTM98lao6fcraD/ lmtVE3rPHie7zJJZNGdHnDP4KziEgPS469IJM= MIME-Version: 1.0 Received: by 10.52.18.72 with SMTP id u8mr8044721vdd.290.1303164077591; Mon, 18 Apr 2011 15:01:17 -0700 (PDT) Received: by 10.52.166.193 with HTTP; Mon, 18 Apr 2011 15:01:17 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0DE777@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE777@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 19 Apr 2011 03:31:17 +0530 Message-ID: From: Glen Kent To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "karp@ietf.org" Subject: Re: [karp] draft-ietf-karp-threats-reqs updated 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, 18 Apr 2011 22:01:18 -0000 Manav, > > Design Guide too has been updated and is ready for the ADs: > http://tools.ietf.org/html/draft-ietf-karp-design-guide-02 The design-guide refers to draft-ietf-saag-crypto-key-table. I dont think its alive anymore and you need to change the references to point to the ietf-karp document. Further, since KARP chairs have decided to stop working on the framework document, do you still want to continue referring to ietf-karp-framework? Glen From glen.kent@gmail.com Mon Apr 18 15:10:03 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F00FCE070C for ; Mon, 18 Apr 2011 15:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLhsJ2C3Yf9o for ; Mon, 18 Apr 2011 15:10:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 5F80AE06F7 for ; Mon, 18 Apr 2011 15:10:03 -0700 (PDT) Received: by vxg33 with SMTP id 33so4836880vxg.31 for ; Mon, 18 Apr 2011 15:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vd2PGrTr9diWVW4WiaeZy7nphEI6+s5TFocsPY6g3+8=; b=kyRf0YigdebK5JG+mxRxcIacozFv2Vcot3oovgK50O1H0h7cv+bfOJkWsRRNZ3I/zB KkfGIigUpD+ON4UPk2WBF/LyP1h/BWtqDsaFGSdmODCV829o5oVrMcVt5xxTZ5543Fyl 9gUrFXTRizywNoETaj3L1HjVBKRWrtOjAND/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QK/egldaqhRaAmvYmNsBkuKpGXq203WTjTs9HCW56wdFRGEPbWVtFvprgvXNDh0fiH WHzmFkzDOk2ME4B1LTBFckMpSr2QNmXh/N5BC1TJEc3XGtWCruWFHH8fCkwazIn55cBB dpjOKUmIiU/cU1B23ALp0nscPIhEFzfEBD0/4= MIME-Version: 1.0 Received: by 10.52.172.2 with SMTP id ay2mr739542vdc.50.1303164602862; Mon, 18 Apr 2011 15:10:02 -0700 (PDT) Received: by 10.52.166.193 with HTTP; Mon, 18 Apr 2011 15:10:02 -0700 (PDT) In-Reply-To: <4DA7C28C.5060406@alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE216@INBANSXCHMBSA1.in.alcatel-lucent.com> <4DA7944F.4030302@cisco.com> <4DA7C28C.5060406@alcatel-lucent.com> Date: Tue, 19 Apr 2011 03:40:02 +0530 Message-ID: From: Glen Kent To: Manav Bhatia Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] PIM-SM Gap Analysis 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, 18 Apr 2011 22:10:04 -0000 Manav, >> motivation to move from one to the other. While there are several >> IPsec OSPFv3 deployments, i am not sure if you'll see the same number >> for PIM-SM. > > That could probably be because RFC 5796 is just a year old, while RFC 4522 > has been out there since almost 5+ years now. A very valid point about why IPsec may not be as pervasively used with PIM-SM as OSPFv3. However, this also means that its a lot easier for us to get rid of this and come out with an in-band security mechanism for PIM-SM or PIM-SSM. Its really the latter that i am more interested in. BTW, you should mention PIM-SSM in the design-guide as it may simplify the KMP requirements when compared to PIM-SM. Even if an in-band mechanism is developed then doing this for PIM-SSM is going to be much simpler as you will not need to add a digest to the notorious PIM register data packets. Glen From uma.chunduri@ericsson.com Mon Apr 18 16:16:20 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE7D7E08B2 for ; Mon, 18 Apr 2011 16:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQcc2Bpl4wV3 for ; Mon, 18 Apr 2011 16:16:20 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 212C7E073B for ; Mon, 18 Apr 2011 16:16:20 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3INGFOE014828; Mon, 18 Apr 2011 18:16:17 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 18 Apr 2011 19:16:11 -0400 From: Uma Chunduri To: Sam Hartman Date: Mon, 18 Apr 2011 19:16:10 -0400 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv+EYvxSNbbaEusTCSrGcy2HZ86jwACdjCg Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.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 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 23:16:21 -0000 Ok let me ask a simple question - Why this session key is required and why not use the long lived key itself? If these session keys are completely relied and derived from the Master ke= y (and some NONCE, which is being exchanged *plain* through http://www.ietf= .org/id/draft-bhatia-karp-short-lived-keys-00.txt) why bother deriving this= . If Master key is compromised (if it's manual it's possible and the one of t= he reasons for this work) =20 - I don't see the value of these secondary keys, here keying material i= s being exchanged plain from RPs With AKM almost eliminate as you would get those *securely* through *authen= ticated* party/peer and re-key of master key itself is possible - again, why any body wants to use these secondary keys, where keying m= aterial is being exchanged plain from RPs; use rather long-lived. Still, RPs only need to derive these keys - these should be capable of PRF (new DH exchange) - NONCE should be random enough (RFC 4086: http://www.ietf.org/rfc/rfc4= 086.txt) - Should use better KDF functions (consider AES and CMAC too) - above all any keying material exchanged should be protected the same = way as master key generation Regards, -Uma -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Monday, April 18, 2011 2:42 PM To: Uma Chunduri Cc: Sam Hartman; mark Brown; Bhatia, Manav (Manav); karp@ietf.org Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Prot= ocols >>>>> "Uma" =3D=3D Uma Chunduri writes: There are two reasons I think we need KDFs. 1) deal with related key attacks 2) Several issues that come up in deployments where there is no AKM. Uma> [Uma] I am not saying key derivation cannot be used. If PFS is Uma> required, now RPs should do DH exchange and this won't stop Uma> there. I definitely see this as a slippery-slope and PFS is Uma> only one example. I'm sorry, I'm not seeing the slope. I need to ask you to enumerate all the examples or at least enough of them = to see a slope. Later, you talk about the quality of random numbers for a KDF. In this sort of case I'd expect the only input to the KDF that needs to be = random is the key. Yes, we'll care about the cryptographic quality of the KDF, but that's not = too hard to deal with. From hartmans@mit.edu Mon Apr 18 16:36:36 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4B01E0755 for ; Mon, 18 Apr 2011 16:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZd+-PxMs4yL for ; Mon, 18 Apr 2011 16:36:36 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id 683FBE06AB for ; Mon, 18 Apr 2011 16:36:36 -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 2CADF20228; Mon, 18 Apr 2011 19:33:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2A6104541; Mon, 18 Apr 2011 19:36:23 -0400 (EDT) From: Sam Hartman To: Venkatesh Sriram References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 18 Apr 2011 19:36:23 -0400 In-Reply-To: (Venkatesh Sriram's message of "Tue, 19 Apr 2011 03:09:33 +0530") 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] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 23:36:37 -0000 >>>>> "Venkatesh" == Venkatesh Sriram writes: Venkatesh> The key tables draft mostly talks about associating a Venkatesh> life time with keys so that a rollover can be Venkatesh> implemented. I dont think it mentions anything about Venkatesh> *how* the session keys can be derived. It does. The KDF is one of the parameters of an entry. Venkatesh> I think the essence of Manav's proposal is that we use a Venkatesh> session key instead of a long-lived key to secure the Venkatesh> routing protocols. Lets us first start by discussing Venkatesh> whether we agree to this proposal or not. If we do agree, Venkatesh> then we can look at how the session keys may be derived. I don't like your ordering much, because I think whether the session keys have value depends entirely on how they are derived and what that derivation brings us. so I don't think the issues are seperable. I don't think we need to decide on the specific cryptographic function, but I do think we need to decide what parameters are inputs to the derivation. I'd certainly support proposals that did things like guarantee different routing protocols have different keys; guarantee different interfaces have different keys. Venkatesh> However, if it turns out that people dont agree with Venkatesh> using the session keys, then the whole discussion is Venkatesh> moot. Venkatesh> My vote is to use the session keys derived from the Venkatesh> long-lived keys, simply because we shouldnt be using the Venkatesh> long-lived key a lot. It has been claimed that we should not use a long-lived key a lot. Eric Rescorla argued against most rationales for why you would care about how many operations a key in a modern integrity protection protocol was used. I don't think there's a lot behind an argument that you should not use a key for a large number of operations from a security standpoint with our current understanding of cryptanalysis. Other than increased complexity, it probably cannot hurt. However, while my reasoning is different than yours, I do come to the conclusion that there are inputs to the derivation that would make a derivation very valuable. From uma.chunduri@ericsson.com Mon Apr 18 16:59:59 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1535AE070C for ; Mon, 18 Apr 2011 16:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxXk32-pAuZZ for ; Mon, 18 Apr 2011 16:59:58 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 67A36E0692 for ; Mon, 18 Apr 2011 16:59:58 -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 p3INxrv1017729; Mon, 18 Apr 2011 18:59:56 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 18 Apr 2011 19:59:50 -0400 From: Uma Chunduri To: Sam Hartman , Venkatesh Sriram Date: Mon, 18 Apr 2011 19:59:49 -0400 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv+IXf8ZhG+V0LORYSaI83qg1iZgQAAimZg Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.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 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 18 Apr 2011 23:59:59 -0000 Venkatesh> I think the essence of Manav's proposal is that we use a Venkatesh> session key instead of a long-lived key to secure the Venkatesh> routing protocols. Lets us first start by discussing Venkatesh> whether we agree to this proposal or not. If we do agree, Venkatesh> then we can look at how the session keys may be derived. I don't like your ordering much, because I think whether the session keys h= ave value depends entirely on how they are derived and what that derivation= brings us. so I don't think the issues are seperable. I don't think we need to decide on the specific cryptographic function, but= I do think we need to decide what parameters are inputs to the derivation.= I'd certainly support proposals that did things like guarantee different = routing protocols have different keys; guarantee different interfaces have = different keys. [Uma] I agree here, not only different routing protocols also say different= interfaces/links or areas may use different keys.=20 Venkatesh> However, if it turns out that people dont agree with Venkatesh> using the session keys, then the whole discussion is Venkatesh> moot. Venkatesh> My vote is to use the session keys derived from the Venkatesh> long-lived keys, simply because we shouldnt be using the Venkatesh> long-lived key a lot.=20 It has been claimed that we should not use a long-lived key a lot. Eric Rescorla argued against most rationales for why you would care about h= ow many operations a key in a modern integrity protection protocol was used= . I don't think there's a lot behind an argument that you should not use a ke= y for a large number of operations from a security standpoint with our curr= ent understanding of cryptanalysis. Other than increased complexity, it probably cannot hurt. However, while my reasoning is different than yours, I do come to the concl= usion that there are inputs to the derivation that would make a derivation = very valuable. [Uma] ..and these inputs should be passed to AKMs as opaque information, ge= t the keys exchanged securely in some repository and use the same (or) let = all RPs do the same/similar. =20 From dharkins@lounge.org Mon Apr 18 23:45:30 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B1134E05F5 for ; Mon, 18 Apr 2011 23:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpUsg7-05WKl for ; Mon, 18 Apr 2011 23:45:30 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id 0EE05E0665 for ; Mon, 18 Apr 2011 23:45:27 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6858B1022404C; Mon, 18 Apr 2011 23:45:26 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 18 Apr 2011 23:45:26 -0700 (PDT) Message-ID: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel- lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 18 Apr 2011 23:45:26 -0700 (PDT) From: "Dan Harkins" To: "Bhatia, Manav (Manav)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 19 Apr 2011 06:45:30 -0000 Hi, On Wed, April 13, 2011 4:47 pm, Bhatia, Manav (Manav) wrote: > Hi, > > Instead of using the pre shared key (PSK) in manual keying for all packets > the routing protocols could use a traffic key that's derived from the PSK > using some key derivation function. Each side could announce a random > number (a nonce) and the KDF could mix this with the PSK to derive the > traffic key per session. Benefits of this approach: > > o Key rollover becomes very easy as it's a local decision now requiring > now co-ordination with our peers. Each side can generate a new nonce and > all others recompute the traffic key based on the new nonce value. > Attackers cant inject packets with spurious nonces as this packet will be > protected using the traffic key based on the nonce that others have sent. > > o Avoids inter-session replay attacks without involving non volatile > memory as each router will use a different nonce upon booting up. Detriments to that approach: o Msuses KDF since "key" is not uniformly random. o Susceptible to passive (!) dictionary attack. o No PFS. Instead, it would be better to use the PSK as a CREDENTIAL for authentication of a strong, uniformly random key in a manner that is resistant to dictionary attack and that provides PFS. Like so: PSK | V KMP | V strong, uniformly random key | V keytable (w/KDF) | | | | | | | V V V V V V V session keys regards, Dan. From curtis@occnc.com Tue Apr 19 13:23:39 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DCC63E0678 for ; Tue, 19 Apr 2011 13:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6su2n7vSkPl for ; Tue, 19 Apr 2011 13:23:39 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id C37D4E0670 for ; Tue, 19 Apr 2011 13:23:38 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3JKNanQ051318; Tue, 19 Apr 2011 16:23:36 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104192023.p3JKNanQ051318@harbor.orleans.occnc.com> To: "Bhatia, Manav (Manav)" From: Curtis Villamizar In-reply-to: Your message of "Sun, 17 Apr 2011 06:12:58 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 19 Apr 2011 16:23:36 -0400 Sender: curtis@occnc.com Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com 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, 19 Apr 2011 20:23:40 -0000 In message <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > Hi, > > I have written the proposal in the draft format and its available here: > http://www.ietf.org/id/draft-bhatia-karp-short-lived-keys-00.txt > > Would be great if folks can review and provide feedback on this. The > proposal in the draft is currently quite raw and I believe it requires > quite a few iterations before it becomes something that can be > seriously considered as a direction that KARP should take wrt using > short-lived keys for the routing protocols (RPs). I am hoping that > this will trigger some discussion which will provide more clarity on > how RPs can make use of such keys. > > Cheers, Manav Manav, Router A must always use a key that is based on information provided by router B. If not, then a third party can replay a nonce exchange that was captured. Therefore section 4.2 has a security weakness. Section 4.1 is fine. To bootstrap, router A may have no information from router B. Therefore a request for a nonce from A can come without key information based in a nonce from B. B should rate limit the replies to avoid DOS. Remebering the set of bootstrap nonce provided in the recent past and rejecting those will also help. Nice work. Curtis > > -----Original Message----- > > From: Venkatesh Sriram [mailto:vnktshsriram@gmail.com] > > Sent: Thursday, April 14, 2011 9.21 PM > > To: Bhatia, Manav (Manav); Acee Lindem > > Cc: karp@ietf.org > > Subject: Re: [karp] Using dynamically derived Traffic Keys > > for Routing Protocols > > > > It would be great if someone can draft this idea (in Manav's original > > email) so that it becomes easier to track and follow. I believe this > > will work for IS-IS as well where this additional information needs to > > be passed in TLV 10. I like the idea of a KMP providing a long-lived > > key (or a shared secret when using manual keying) and the routing > > protocols deriving the short-term keys and using it internally > > themselves. This imo is completely within the charter of KARP. I also > > agree with what Curtis said earlier about this mechanism being > > applicable for regular key rollover - something that operators have > > been looking for since a long time now. > > > > Sriram From manav.bhatia@alcatel-lucent.com Tue Apr 19 17:51:37 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3FCAEE0689 for ; Tue, 19 Apr 2011 17:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj1p14LTwV5d for ; Tue, 19 Apr 2011 17:51:36 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id 94272E0670 for ; Tue, 19 Apr 2011 17:51:36 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3K0pW1a012903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2011 19:51:35 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3K0pV3C009407 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Apr 2011 06:21:32 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 20 Apr 2011 06:21:31 +0530 From: "Bhatia, Manav (Manav)" To: "curtis@occnc.com" Date: Wed, 20 Apr 2011 06:21:36 +0530 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv+z60/ThGv759sQ+2DlNdjUmeuIAAJOCSA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of "Sun, 17 Apr 2011 06:12:58 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104192023.p3JKNanQ051318@harbor.orleans.occnc.com> In-Reply-To: <201104192023.p3JKNanQ051318@harbor.orleans.occnc.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.35 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 20 Apr 2011 00:51:37 -0000 Hi Curtis, =20 > Router A must always use a key that is based on information provided > by router B. If not, then a third party can replay a nonce exchange > that was captured. =20 This cannot happen as the third patry will not be aware of the long-lived k= ey. Or are you suggesting that someone could do this *if* they are aware of= the long-lived key? > Therefore section 4.2 has a security weakness. > Section 4.1 is fine. Multicast is an issue with Section 4.1 If I am on a LAN and I am speaking to 2 routers A and B, then which nonce s= hould I use when sending out a multicast Hello? Should I use nonceA or nonc= eB?=20 >=20 > To bootstrap, router A may have no information from router B. > Therefore a request for a nonce from A can come without key > information based in a nonce from B. B should rate limit the replies > to avoid DOS. Remebering the set of bootstrap nonce provided in the > recent past and rejecting those will also help. >=20 > Nice work. Thanks!=20 Cheers, Manav > = From uma.chunduri@ericsson.com Tue Apr 19 19:50:23 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4AA11E0690 for ; Tue, 19 Apr 2011 19:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTKtoMlsCX5w for ; Tue, 19 Apr 2011 19:50:20 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id D1A31E0670 for ; Tue, 19 Apr 2011 19:50: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 p3K2oHPx002890; Tue, 19 Apr 2011 21:50:19 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 19 Apr 2011 22:50:11 -0400 From: Uma Chunduri To: Venkatesh Sriram Date: Tue, 19 Apr 2011 22:50:10 -0400 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv+ER8JEACwK7cyQha8gD8RHUS8TwA70lWw Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.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 Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 20 Apr 2011 02:50:23 -0000 =20 > [Uma] No, PFS doesn't imply confidentiality. All It all imply, if it=20 > required is - one should not use not only long term keys derived from=20 > some > form of DH exchange but also should not use any keying material=20 > associated with it. Are you suggesting that we should not use short-lived keys from a long-live= d key? [Uma] I am not suggesting this. But RPs should not involve in exchanging ke= ying material (NONCE) as proposed in here http://www.ietf.org/id/draft-bhatia-karp-short-lived-keys-00.txt. It can simply weakens the master key (which is cryptographically sound= ) by not being random enough.=20 Any key/key material exchange should be left to AKMs and maintain clea= n separation. This way you also will be guaranteed to get securely exchanged and pro= perly authenticated keys (original or re-keying with PFS).=20 > > You argue that for design cleanlyness, key derivation should not be=20 > part of the integrity protocol. > > [Uma] integrity protocol?? You mean Routing protocol? > The last thing a routing protocol implementation has to worry=20 > about is randomness of pseudo-random numbers generated to > derive keys and if it is FIPS complaint/pass security RPs can speak to the "KARP module" and get all that information - they dont= need to do this themselves. [Uma] What information? This module can be written and owned by the security experts. There btw ar= e already proposals for extending RPs to generate Nonces - You can look at draft-bhatia-karp-ospf-ip-layer-protection-03 for more details. [Uma] Again, being RP, let's not exchange in keying material, until =20 - you have the capability to for PFS (new DH exchange) - you can generate crypto quality NONCE=20 - above all any keying material exchanged should be protected the same = way as master key generation But, using KDFs with master key and other protocol/peer/area/interface spec= ific parameters should be fine.=20 Still, if manual keying is used and master key itself gets compromised (out= of band usage etc..)=20 - these session keys can't bring any value If, AKM is used of course, all these session keys should be *invalidated* w= hen master key change=20 - if peer session closes or re-key happens (PFS could be in-built = there and let AKMs deal with it). Regards, -Uma From manav.bhatia@alcatel-lucent.com Tue Apr 19 20:00:54 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F152EE0747 for ; Tue, 19 Apr 2011 20:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ry-fvcowac8 for ; Tue, 19 Apr 2011 20:00:54 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id 11623E0690 for ; Tue, 19 Apr 2011 20:00:54 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3K30mRc002166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2011 22:00:51 -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 p3K30l3f016803 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Apr 2011 08:30:47 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 20 Apr 2011 08:30:47 +0530 From: "Bhatia, Manav (Manav)" To: Uma Chunduri Date: Wed, 20 Apr 2011 08:30:47 +0530 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv+ER8JEACwK7cyQha8gD8RHUS8TwA70lWwAAFnrVA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DED3A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.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.37 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 20 Apr 2011 03:00:55 -0000 Hi Uma, > It can simply weakens the master key (which is=20 > cryptographically sound) by not being random enough.=20 I am afraid I don't understand how the mechanism described in this draft "w= eakens the master key". You have a master key. Now, you put this through a KDF and you derive a key= . How can this derived key be any less secure than the master key is someth= ing that I am unable to comprehend. > Any key/key material exchange should be left to AKMs and=20 > maintain clean separation. [clipped] =20 > [Uma] Again, being RP, let's not exchange in keying material, until =20 > - you have the capability to for PFS (new DH exchange) > - you can generate crypto quality NONCE=20 What makes you think that the security module running in a router can gener= ate a crypto quality nonce and an RP running on that same router cant. Fina= lly its some source code that would generate that. Why cant an RP access th= at same code via some interfacing module (a la the KARP module) I agree that if the long-lived key is compromised then the session keys as = proposed in this draft wouldn't help. Cheers, Manav= From uma.chunduri@ericsson.com Tue Apr 19 20:12:46 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E3319E071C for ; Tue, 19 Apr 2011 20:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg+vhrBvHp-C for ; Tue, 19 Apr 2011 20:12:46 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 545E2E067E for ; Tue, 19 Apr 2011 20:12:46 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3K3CjLG031988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Apr 2011 22:12:45 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 19 Apr 2011 23:12:44 -0400 From: Uma Chunduri To: "Bhatia, Manav (Manav)" Date: Tue, 19 Apr 2011 23:12:42 -0400 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv+ER8JEACwK7cyQha8gD8RHUS8TwA70lWwAAFnrVAAAH660A== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DED3A@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD0DED3A@INBANSXCHMBSA1.in.alcatel-lucent.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 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 20 Apr 2011 03:12:47 -0000 Hi Manav, In-line - -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Tuesday, April 19, 2011 8:01 PM To: Uma Chunduri Cc: karp@ietf.org Subject: RE: [karp] Using dynamically derived Traffic Keys for Routing Prot= ocols Hi Uma, > It can simply weakens the master key (which is cryptographically=20 > sound) by not being random enough. I am afraid I don't understand how the mechanism described in this draft "w= eakens the master key". [Uma] It can, if exchanged NONCE is not appropriate enough You have a master key. Now, you put this through a KDF and you derive a key= . How can this derived key be any less secure than the master key is someth= ing that I am unable to comprehend. [Uma] draft suggests RPs exchanged NONCE.. Leave this keying material and proceed with KDF with master key alone= + other params From curtis@occnc.com Tue Apr 19 20:54:03 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F1F26E069C for ; Tue, 19 Apr 2011 20:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvKeyF2dsfQy for ; Tue, 19 Apr 2011 20:54:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 531DFE0660 for ; Tue, 19 Apr 2011 20:54:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3K3s1a4074026; Tue, 19 Apr 2011 23:54:01 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> To: "Bhatia, Manav (Manav)" From: Curtis Villamizar In-reply-to: Your message of "Wed, 20 Apr 2011 06:21:36 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 19 Apr 2011 23:54:01 -0400 Sender: curtis@occnc.com Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com 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, 20 Apr 2011 03:54:04 -0000 In message <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > Hi Curtis, > > > Router A must always use a key that is based on information provided > > by router B. If not, then a third party can replay a nonce exchange > > that was captured. > > This cannot happen as the third patry will not be aware of the > long-lived key. Or are you suggesting that someone could do this *if* > they are aware of the long-lived key? If there is a way to say "I will use this nonce and key" then a third party can capture such a packet and play it back later. > > Therefore section 4.2 has a security weakness. > > Section 4.1 is fine. > > Multicast is an issue with Section 4.1 Good point but what you have in 4.1 isn't replay proof. > If I am on a LAN and I am speaking to 2 routers A and B, then which > nonce should I use when sending out a multicast Hello? Should I > use nonceA or nonceB? In that case the DR has to be trusted, but there needs to be an exchange with the DR to validate that the key being used is fresh. This amounts to a "I heard your suggestion to use key K, now please validate the liveness of the key selection with this random value". This one exchange would be needed for each router talking to the DR. Do real networks use anything but point to point links? :-) > > To bootstrap, router A may have no information from router B. > > Therefore a request for a nonce from A can come without key > > information based in a nonce from B. B should rate limit the replies > > to avoid DOS. Remebering the set of bootstrap nonce provided in the > > recent past and rejecting those will also help. > > > > Nice work. > > Thanks! > > Cheers, Manav Curtis From manav.bhatia@alcatel-lucent.com Tue Apr 19 22:39:56 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2ABAE06FC for ; Tue, 19 Apr 2011 22:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvVDgH6Qi59E for ; Tue, 19 Apr 2011 22:39:55 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id 2B4C4E06ED for ; Tue, 19 Apr 2011 22:39:55 -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 p3K5dm3m017096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2011 00:39:51 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3K5diUo002567 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Apr 2011 11:09:44 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 20 Apr 2011 11:09:44 +0530 From: "Bhatia, Manav (Manav)" To: "curtis@occnc.com" Date: Wed, 20 Apr 2011 11:10:55 +0530 Thread-Topic: [karp] Using dynamically derived Traffic Keys for Routing Protocols Thread-Index: Acv/DpkUPu03MBuPTVaujzS7w7/a5QADgvvQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFD0DEDA8@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of "Wed, 20 Apr 2011 06:21:36 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> In-Reply-To: <201104200354.p3K3s1a4074026@harbor.orleans.occnc.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: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 20 Apr 2011 05:39:56 -0000 > > =20 > > This cannot happen as the third patry will not be aware of the > > long-lived key. Or are you suggesting that someone could do=20 > this *if* > > they are aware of the long-lived key? >=20 >=20 > If there is a way to say "I will use this nonce and key" then a third > party can capture such a packet and play it back later. Yes, it can and this is precisely why sec 4.2 requires implementations to s= upport the challenge/response mechanism described in draft-bhatia-karp-ospf= -ip-layer-protection. With this the third party will not be able to replay old packets as the rec= iever will change its current nonce and would expect the third party to sen= d a packet reflecting the updated nonce. Since it wouldn't be able to do th= at, the attack would thus not be successful. >=20 >=20 > > > Therefore section 4.2 has a security weakness. > > > Section 4.1 is fine. > > =20 > > Multicast is an issue with Section 4.1 >=20 > Good point but what you have in 4.1 isn't replay proof. >=20 > > If I am on a LAN and I am speaking to 2 routers A and B, then which > > nonce should I use when sending out a multicast Hello? Should I > > use nonceA or nonceB?=20 >=20 >=20 > In that case the DR has to be trusted, but there needs to be an > exchange with the DR to validate that the key being used is fresh. .. and I do discuss this as well in sec 4.1. I think it brings in too much = of complexity which can be completely avoided if we go by approach describe= d in sec 4.2 >=20 > This amounts to a "I heard your suggestion to use key K, now please > validate the liveness of the key selection with this random value". > This one exchange would be needed for each router talking to the DR. >=20 > Do real networks use anything but point to point links? :-) In service provider networks, Yes. However a solution that precludes the po= ssibility of supporting LANs may not be acceptable. BTW, I have been told that we can expect multiple routers on a LAN in the d= ata center environments. Cheers, Manav= From bill@cse.concordia.ca Wed Apr 20 07:00:27 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 61DC6E067D for ; Wed, 20 Apr 2011 07:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBMilMSmP29X for ; Wed, 20 Apr 2011 07:00:26 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by ietfc.amsl.com (Postfix) with ESMTP id 73FF3E0613 for ; Wed, 20 Apr 2011 07:00:26 -0700 (PDT) Received: from [132.205.44.76] (bill@cedar.cs.concordia.ca [132.205.44.76]) by oldperseverance.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id p3KE0PpX017308 for ; Wed, 20 Apr 2011 10:00:25 -0400 Message-ID: <4DAEE6F8.1000305@cse.concordia.ca> Date: Wed, 20 Apr 2011 10:00:24 -0400 From: Bill Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: karp@ietf.org References: <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> In-Reply-To: <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2011/04/20 10:00:25 EDT Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 20 Apr 2011 14:00:27 -0000 On 4/19/2011 11:54 PM, Curtis Villamizar wrote: > > --snip-- > >> If I am on a LAN and I am speaking to 2 routers A and B, then which >> nonce should I use when sending out a multicast Hello? Should I >> use nonceA or nonceB? > > > In that case the DR has to be trusted, but there needs to be an > exchange with the DR to validate that the key being used is fresh. Or something, not necessarily the DR. The key used by a speaker can be common to the routers seen through an interface, or to all of the routers that are "neighbors" of the speaking router (which fits best with the way the "Hello" packet is defined, at least in PIM), or (if lesser security is acceptable) to a whole administrative region. > > This amounts to a "I heard your suggestion to use key K, now please > validate the liveness of the key selection with this random value". > This one exchange would be needed for each router talking to the DR. > > Do real networks use anything but point to point links? :-) Yes :-) In particular, multicast routing protocols multicast their hello messages on the LANs that they are connected to. Therefore, since the SPI (to use the IPsec name) _cannot_ be determined by the incoming router (as it normally would be for a unicast IPsec SA), the various SPIs used by the routers in an "administrative region" must be coordinated by a "group owner" for that administrative region. This is one reason why multicast protocols are classified separately in the karp documentation. My own working assumption is that control over "who is my neighbor" will also reside with this "group owner", i.e., a router's willingness to exchange hello messages with its neighbor(s) will be determined by someone with larger scope than one LAN. (Of course, this "permitted adjacency" information has to be retained over re-boots, so that the "group owner" need not be consulted at the time of the re-boot, to avoid an avalanche of requests at start-up time.) Bill -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From hartmans@mit.edu Mon Apr 25 03:38:24 2011 Return-Path: X-Original-To: karp@ietfc.amsl.com Delivered-To: karp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8EB75E071F for ; Mon, 25 Apr 2011 03:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.807 X-Spam-Level: X-Spam-Status: No, score=-102.807 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vMBRu+WJKZs for ; Mon, 25 Apr 2011 03:38:24 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id 34211E0693 for ; Mon, 25 Apr 2011 03:38:24 -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 BB27920378; Mon, 25 Apr 2011 06:34:46 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 61CE74543; Mon, 25 Apr 2011 06:38:12 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: <7C362EEF9C7896468B36C9B79200D8350CFD0DE243@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DE7ED@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DED3A@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 25 Apr 2011 06:38:12 -0400 In-Reply-To: (Uma Chunduri's message of "Tue, 19 Apr 2011 23:12: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: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 25 Apr 2011 10:38:24 -0000 I agree with Manav that I see no way to weaken the master key with a well defined KDF and with inputs independent of the master key. From manav.bhatia@alcatel-lucent.com Thu Apr 28 00:59:46 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 D4058E06C0 for ; Thu, 28 Apr 2011 00:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.553 X-Spam-Level: X-Spam-Status: No, score=-4.553 tagged_above=-999 required=5 tests=[AWL=0.806, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 WEXt+WifJsUx for ; Thu, 28 Apr 2011 00:59:46 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4246EE06A6 for ; Thu, 28 Apr 2011 00:59:46 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3S7xbZd019660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2011 02:59:41 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3S7xaj9016667 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Apr 2011 13:29:37 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 28 Apr 2011 13:29:36 +0530 Message-ID: <4DB91E2C.2020205@alcatel-lucent.com> Date: Thu, 28 Apr 2011 13:28:36 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: "shraddha.hegde@huawei.com" References: "Your message of Wed, 20 Apr 2011 06:21:36 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DEDA8@INBANSXCHMBSA1.in.alcatel-lucent.com> <97E2B27346F84114B09AA21B678F3C05@china.huawei.com> In-Reply-To: <97E2B27346F84114B09AA21B678F3C05@china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 28 Apr 2011 07:59:46 -0000 Hi Shraddha, > In the design consideration section > It is mentioned that "if an attacker is aware of long-lived keys, guessing > the short-lived traffic key that will be generated next should not be > possible." While the nonce is being sent in clear, the attacker cannot "guess" what the Nonce will be since thats really a random number so cannot "guess" the short-lived key that will be used next. > > Since the short term keys are derived based on nonce which is carried in > plain in OSPF messages, attacker who is aware of long-lived keys can easily > Derive the short-term keys and mount man-in-the-middle attacks. Only once the routers have moved to a shorted lived key. The attacker cannot know this in advance. CHeers, Manav From manav.bhatia@alcatel-lucent.com Thu Apr 28 02:18:02 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 62ED4E070F for ; Thu, 28 Apr 2011 02:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.615 X-Spam-Level: X-Spam-Status: No, score=-4.615 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 zomFz8YYnPIn for ; Thu, 28 Apr 2011 02:18:01 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A8A45E06F8 for ; Thu, 28 Apr 2011 02:18:01 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3S9HmBq018285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2011 04:17:55 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3S9HmHG025069 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Apr 2011 14:47:48 +0530 Received: from [135.250.26.32] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 28 Apr 2011 14:47:48 +0530 Message-ID: <4DB93080.8040106@alcatel-lucent.com> Date: Thu, 28 Apr 2011 14:46:48 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: "shraddha.hegde@huawei.com" References: "Your message of Wed, 20 Apr 2011 06:21:36 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DEDA8@INBANSXCHMBSA1.in.alcatel-lucent.com> <97E2B27346F84114B09AA21B678F3C05@china.huawei.com> <4DB91E2C.2020205@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 28 Apr 2011 09:18:02 -0000 Hi Shraddha, The document does not even claim to provide protection when your long-lived key is *compromised*. Its meant to derive different session keys (for different routing protocols) using the same long-lived key. It also helps where you dont use the same key over and over again which increases the possibility of inter-session replay attacks. If you keep changing the keys then you can prevent that from happening. Cheers, Manav On 4/28/2011 2:42 PM, shraddha wrote: >> >> Since the short term keys are derived based on nonce which is carried in >> plain in OSPF messages, attacker who is aware of long-lived keys can > easily >> Derive the short-term keys and mount man-in-the-middle attacks. > > ---Only once the routers have moved to a shorted lived key. The attacker > ---cannot know this in advance. > > Yes. The attacker cannot know in advance about the short lived-key. But once > Short lived key is derived, same key will be used till the nonce changes. > This period is good enough for an attacker having long-lived key to mount > man-in-the-middle. > > The point I am making here is that the short lived key derivation method > described in the draft cannot provide protection against the compromised > long-lived keys. > > Such a protection is possible only mechanisms such as DH algorithm is used > for the key derivation. > > Rgds > Shraddha > > **************************************************************************** > *********** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > > > -----Original Message----- > From: Manav Bhatia [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Thursday, April 28, 2011 1:29 PM > To: shraddha.hegde@huawei.com > Cc: karp@ietf.org > Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing > Protocols > > Hi Shraddha, > >> In the design consideration section >> It is mentioned that "if an attacker is aware of long-lived keys, guessing >> the short-lived traffic key that will be generated next should not be >> possible." > > While the nonce is being sent in clear, the attacker cannot "guess" what > the Nonce will be since thats really a random number so cannot "guess" > the short-lived key that will be used next. > >> >> Since the short term keys are derived based on nonce which is carried in >> plain in OSPF messages, attacker who is aware of long-lived keys can > easily >> Derive the short-term keys and mount man-in-the-middle attacks. > > Only once the routers have moved to a shorted lived key. The attacker > cannot know this in advance. > > CHeers, Manav > From shraddha.hegde@huawei.com Thu Apr 28 00:11:49 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 B8DFAE064B for ; Thu, 28 Apr 2011 00:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.359 X-Spam-Level: X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 nPi8UIGWT7f4 for ; Thu, 28 Apr 2011 00:11:48 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1ABE06C0 for ; Thu, 28 Apr 2011 00:11:47 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKC00LRVP9KAI@szxga03-in.huawei.com> for karp@ietf.org; Thu, 28 Apr 2011 15:10:32 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKC007QGP9KMY@szxga03-in.huawei.com> for karp@ietf.org; Thu, 28 Apr 2011 15:10:32 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Apr 2011 15:10:30 +0800 Received: from BLRNSHTIPL1NC (10.18.1.31) by SZXEML401-HUB.china.huawei.com (10.82.67.31) with Microsoft SMTP Server id 14.1.270.1; Thu, 28 Apr 2011 15:10:31 +0800 Date: Thu, 28 Apr 2011 12:40:20 +0530 From: shraddha In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFD0DEDA8@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Originating-IP: [10.18.1.31] To: "'Bhatia, Manav (Manav)'" Message-id: <97E2B27346F84114B09AA21B678F3C05@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acv/DpkUPu03MBuPTVaujzS7w7/a5QADgvvQAZU47iA= References: "Your message of Wed, 20 Apr 2011 06:21:36 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DEDA8@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailman-Approved-At: Thu, 28 Apr 2011 06:05:10 -0700 Cc: karp@ietf.org Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: shraddha.hegde@huawei.com 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, 28 Apr 2011 09:02:48 -0000 Hi Manav, I have one comment on the draft. In the design consideration section It is mentioned that "if an attacker is aware of long-lived keys, guessing the short-lived traffic key that will be generated next should not be possible." Since the short term keys are derived based on nonce which is carried in plain in OSPF messages, attacker who is aware of long-lived keys can easily Derive the short-term keys and mount man-in-the-middle attacks. I am not able o understand the significance of "not being able to guess next short lived-key" when attacker (having access to long lived key) can easily play around with present short lived-key. The advantage of the short term key could be that it gives less time for the brute force algorithm to run and hence is more secure. I feel this should be the design consideration rather than protection against the compromised long-lived keys. Rgds Shraddha **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav) Sent: Wednesday, April 20, 2011 11:11 AM To: curtis@occnc.com Cc: karp@ietf.org Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols > > > > This cannot happen as the third patry will not be aware of the > > long-lived key. Or are you suggesting that someone could do > this *if* > > they are aware of the long-lived key? > > > If there is a way to say "I will use this nonce and key" then a third > party can capture such a packet and play it back later. Yes, it can and this is precisely why sec 4.2 requires implementations to support the challenge/response mechanism described in draft-bhatia-karp-ospf-ip-layer-protection. With this the third party will not be able to replay old packets as the reciever will change its current nonce and would expect the third party to send a packet reflecting the updated nonce. Since it wouldn't be able to do that, the attack would thus not be successful. > > > > > Therefore section 4.2 has a security weakness. > > > Section 4.1 is fine. > > > > Multicast is an issue with Section 4.1 > > Good point but what you have in 4.1 isn't replay proof. > > > If I am on a LAN and I am speaking to 2 routers A and B, then which > > nonce should I use when sending out a multicast Hello? Should I > > use nonceA or nonceB? > > > In that case the DR has to be trusted, but there needs to be an > exchange with the DR to validate that the key being used is fresh. .. and I do discuss this as well in sec 4.1. I think it brings in too much of complexity which can be completely avoided if we go by approach described in sec 4.2 > > This amounts to a "I heard your suggestion to use key K, now please > validate the liveness of the key selection with this random value". > This one exchange would be needed for each router talking to the DR. > > Do real networks use anything but point to point links? :-) In service provider networks, Yes. However a solution that precludes the possibility of supporting LANs may not be acceptable. BTW, I have been told that we can expect multiple routers on a LAN in the data center environments. Cheers, Manav _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From shraddha.hegde@huawei.com Thu Apr 28 02:14:10 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 3DD75E06F4 for ; Thu, 28 Apr 2011 02:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-1.310, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 whGy1RGZhPxa for ; Thu, 28 Apr 2011 02:14:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 758A9E06B8 for ; Thu, 28 Apr 2011 02:14:09 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKC00K0ZUXKW4@szxga05-in.huawei.com> for karp@ietf.org; Thu, 28 Apr 2011 17:12:56 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKC00F81UX911@szxga05-in.huawei.com> for karp@ietf.org; Thu, 28 Apr 2011 17:12:56 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Apr 2011 17:12:47 +0800 Received: from BLRNSHTIPL1NC (10.18.1.31) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server id 14.1.270.1; Thu, 28 Apr 2011 17:12:44 +0800 Date: Thu, 28 Apr 2011 14:42:44 +0530 From: shraddha In-reply-to: <4DB91E2C.2020205@alcatel-lucent.com> X-Originating-IP: [10.18.1.31] To: 'Manav Bhatia' Message-id: Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcwFek4EfrooUYbgQiCtPYhxryTZ9gACQC6A References: "Your message of Wed, 20 Apr 2011 06:21:36 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DEDA8@INBANSXCHMBSA1.in.alcatel-lucent.com> <97E2B27346F84114B09AA21B678F3C05@china.huawei.com> <4DB91E2C.2020205@alcatel-lucent.com> X-Mailman-Approved-At: Thu, 28 Apr 2011 06:05:53 -0700 Cc: karp@ietf.org Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: shraddha.hegde@huawei.com 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, 28 Apr 2011 09:14:10 -0000 > > Since the short term keys are derived based on nonce which is carried in > plain in OSPF messages, attacker who is aware of long-lived keys can easily > Derive the short-term keys and mount man-in-the-middle attacks. ---Only once the routers have moved to a shorted lived key. The attacker ---cannot know this in advance. Yes. The attacker cannot know in advance about the short lived-key. But once Short lived key is derived, same key will be used till the nonce changes. This period is good enough for an attacker having long-lived key to mount man-in-the-middle. The point I am making here is that the short lived key derivation method described in the draft cannot provide protection against the compromised long-lived keys. Such a protection is possible only mechanisms such as DH algorithm is used for the key derivation. Rgds Shraddha **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Manav Bhatia [mailto:manav.bhatia@alcatel-lucent.com] Sent: Thursday, April 28, 2011 1:29 PM To: shraddha.hegde@huawei.com Cc: karp@ietf.org Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols Hi Shraddha, > In the design consideration section > It is mentioned that "if an attacker is aware of long-lived keys, guessing > the short-lived traffic key that will be generated next should not be > possible." While the nonce is being sent in clear, the attacker cannot "guess" what the Nonce will be since thats really a random number so cannot "guess" the short-lived key that will be used next. > > Since the short term keys are derived based on nonce which is carried in > plain in OSPF messages, attacker who is aware of long-lived keys can easily > Derive the short-term keys and mount man-in-the-middle attacks. Only once the routers have moved to a shorted lived key. The attacker cannot know this in advance. CHeers, Manav From jmh@joelhalpern.com Thu Apr 28 06:08: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 38D01E0669 for ; Thu, 28 Apr 2011 06:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.109 X-Spam-Level: X-Spam-Status: No, score=-102.109 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 i3IXF7KncIOl for ; Thu, 28 Apr 2011 06:08:38 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id B76B2E0663 for ; Thu, 28 Apr 2011 06:08:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B1163430370; Thu, 28 Apr 2011 06:08:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-76.clppva.btas.verizon.net [71.161.52.76]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id B5A6B43036C; Thu, 28 Apr 2011 06:08:37 -0700 (PDT) Message-ID: <4DB966D5.6080304@joelhalpern.com> Date: Thu, 28 Apr 2011 09:08:37 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Manav Bhatia References: "Your message of Wed, 20 Apr 2011 06:21:36 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DEDA8@INBANSXCHMBSA1.in.alcatel-lucent.com> <97E2B27346F84114B09AA21B678F3C05@china.huawei.com> <4DB91E2C.2020205@alcatel-lucent.com> <4DB93080.8040106@alcatel-lucent.com> In-Reply-To: <4DB93080.8040106@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "karp@ietf.org" , "shraddha.hegde@huawei.com" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 28 Apr 2011 13:08:39 -0000 At least some of the discussion on the list was that folks saw significant advantage in providing better resiliency in the face of the compromise of long-lived keys. As I understand it, if we use an AKM for the session key derivation, there are ways to get such protection. And then we can use keytables to let the routing protocol know what the session key is. Which means that we don't have to modify the routing protocols, which is a significant benefit. Yours, Joel On 4/28/2011 5:16 AM, Manav Bhatia wrote: > Hi Shraddha, > > The document does not even claim to provide protection when your > long-lived key is *compromised*. Its meant to derive different session > keys (for different routing protocols) using the same long-lived key. It > also helps where you dont use the same key over and over again which > increases the possibility of inter-session replay attacks. If you keep > changing the keys then you can prevent that from happening. > > Cheers, Manav > > On 4/28/2011 2:42 PM, shraddha wrote: >>> >>> Since the short term keys are derived based on nonce which is carried in >>> plain in OSPF messages, attacker who is aware of long-lived keys can >> easily >>> Derive the short-term keys and mount man-in-the-middle attacks. >> >> ---Only once the routers have moved to a shorted lived key. The attacker >> ---cannot know this in advance. >> >> Yes. The attacker cannot know in advance about the short lived-key. >> But once >> Short lived key is derived, same key will be used till the nonce changes. >> This period is good enough for an attacker having long-lived key to mount >> man-in-the-middle. >> >> The point I am making here is that the short lived key derivation method >> described in the draft cannot provide protection against the compromised >> long-lived keys. >> >> Such a protection is possible only mechanisms such as DH algorithm is >> used >> for the key derivation. >> >> Rgds >> Shraddha >> >> **************************************************************************** >> >> *********** >> This e-mail and attachments contain confidential information from HUAWEI, >> which is intended only for the person or entity whose address is listed >> above. Any use of the information contained herein in any way (including, >> but not limited to, total or partial disclosure, reproduction, or >> dissemination) by persons other than the intended recipient's) is >> prohibited. If you receive this e-mail in error, please notify the >> sender by >> phone or email immediately and delete it! >> >> >> -----Original Message----- >> From: Manav Bhatia [mailto:manav.bhatia@alcatel-lucent.com] >> Sent: Thursday, April 28, 2011 1:29 PM >> To: shraddha.hegde@huawei.com >> Cc: karp@ietf.org >> Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing >> Protocols >> >> Hi Shraddha, >> >>> In the design consideration section >>> It is mentioned that "if an attacker is aware of long-lived keys, >>> guessing >>> the short-lived traffic key that will be generated next should not be >>> possible." >> >> While the nonce is being sent in clear, the attacker cannot "guess" what >> the Nonce will be since thats really a random number so cannot "guess" >> the short-lived key that will be used next. >> >>> >>> Since the short term keys are derived based on nonce which is carried in >>> plain in OSPF messages, attacker who is aware of long-lived keys can >> easily >>> Derive the short-term keys and mount man-in-the-middle attacks. >> >> Only once the routers have moved to a shorted lived key. The attacker >> cannot know this in advance. >> >> CHeers, Manav >> > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From touch@isi.edu Thu Apr 28 10:02:48 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 4DD97E06D7 for ; Thu, 28 Apr 2011 10:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 NSiNXKPIW6In for ; Thu, 28 Apr 2011 10:02:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 30B00E0670 for ; Thu, 28 Apr 2011 10:02:47 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p3SH1Z2F019421 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2011 10:01:35 -0700 (PDT) Message-ID: <4DB99D6F.6020205@isi.edu> Date: Thu, 28 Apr 2011 10:01:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Joel M. Halpern" References: "Your message of Wed, 20 Apr 2011 06:21:36 +0530." <7C362EEF9C7896468B36C9B79200D8350CFD0DED25@INBANSXCHMBSA1.in.alcatel-lucent.com> <201104200354.p3K3s1a4074026@harbor.orleans.occnc.com> <7C362EEF9C7896468B36C9B79200D8350CFD0DEDA8@INBANSXCHMBSA1.in.alcatel-lucent.com> <97E2B27346F84114B09AA21B678F3C05@china.huawei.com> <4DB91E2C.2020205@alcatel-lucent.com> <4DB93080.8040106@alcatel-lucent.com> <4DB966D5.6080304@joelhalpern.com> In-Reply-To: <4DB966D5.6080304@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "shraddha.hegde@huawei.com" , "karp@ietf.org" Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols 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, 28 Apr 2011 17:02:48 -0000 Hi, all, I'm wondering whether the KARP docs talk about the assumptions behind short-term keys, notably that any long-term session is either restarted or can support rekeying. This isn't an issue for TCP-AO, but there are other protocols (legacy TCP MD5, and SSH which is being advocated for use for route caches in the new SIDR docs) that may not be as friendly to short-lived keys. FWIW. Joe From manav.bhatia@alcatel-lucent.com Fri Apr 29 18:46:29 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 38245E06C3; Fri, 29 Apr 2011 18:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.288 X-Spam-Level: X-Spam-Status: No, score=-5.288 tagged_above=-999 required=5 tests=[AWL=1.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IYD9OfBX2sI8; Fri, 29 Apr 2011 18:46:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A143FE06AD; Fri, 29 Apr 2011 18:46:22 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3U1kIff004615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2011 20:46:21 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3U1kHdi027677 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 30 Apr 2011 07:16:17 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 30 Apr 2011 07:16:17 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Sat, 30 Apr 2011 07:16:13 +0530 Thread-Topic: BFD Security Gap Analysis Thread-Index: Acv4+oILfEeuQaBtTK2B2k1+obeqCQN3aQ6Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFDBA5810@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD037C81@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD037C81@INBANSXCHMBSA1.in.alcatel-lucent.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.35 Cc: "rtg-bfd@ietf.org" Subject: Re: [karp] BFD Security Gap Analysis X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 01:46:29 -0000 Hi, Based on the comments that we received from the BFD WG we have updated the = KARP BFD security analysis draft and the latest version can be found here: http://tools.ietf.org/html/draft-bhatia-zhang-karp-bfd-analysis-01 The diffs from the last version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-bhatia-zhang-karp-bfd-analysis-0= 1.txt Cross posting this to BFD since this is relevant there as well. Cheers, Manav > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Tuesday, April 12, 2011 3.45 PM > To: karp@ietf.org > Subject: [karp] BFD Security Gap Analysis >=20 > Hi, >=20 > Dacheng and I have posted a draft that does BFD securtity gap=20 > analysis. Would be great if the WG can review this and=20 > provide some feedback. >=20 > http://www.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-00.txt >=20 > Cheers, Manav >=20 > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > =