From uma.chunduri@ericsson.com Thu Sep 1 13:45:27 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD9321F9998 for ; Thu, 1 Sep 2011 13:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoqZv0Zj06zt for ; Thu, 1 Sep 2011 13:45:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E11421F9992 for ; Thu, 1 Sep 2011 13:45:27 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p81Kkchi023828; Thu, 1 Sep 2011 15:46:58 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 1 Sep 2011 16:46:32 -0400 From: Uma Chunduri To: Sam Hartman , Acee Lindem , "housley@vigilsec.com" , "tim.polk@nist.gov" Date: Thu, 1 Sep 2011 16:46:30 -0400 Thread-Topic: [karp] Mapping of OSPFv2 Key to "Database of Long-Lived Symmetric Cryptographic Keys" () - Resending with Tim's Email Address Corrected Thread-Index: AcxQcZwO6bzU6oIQRaedMmZNTHGSQgYdWU6A Message-ID: References: <287369F0-D8A2-44D3-9C17-BD1F32C64797@lindem.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] Mapping of OSPFv2 Key to "Database of Long-Lived Symmetric Cryptographic Keys" () - Resending with Tim's Email Address Corrected X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 20:45:27 -0000 >>>>> "Acee" =3D=3D Acee Lindem writes: Acee> You are correct that it is the same pair of routers Acee> communicating. However, you can have multiple virtual links Acee> through different transit areas. Today, these can be the same Acee> or different keys/key chains. I guess one could argue that Acee> they do not need to differ. However, we allow different keys Acee> on different interfaces for unicast transmission over Acee> non-virtual links given the key existing key database keys (or Acee> should I call them indices to avoid confusion). OK. so, we either need to accept these will be the same keys or we need to incl= ude some rather protocol-specific details in the key table. If you're using a per-peer keying strategy, then there's not a lot of reaso= n to use different keys. If you're using a per-area keying strategy and us= ing the same key across an area then I'm not sure how we should represent t= his in the crypto draft. [Uma] Isn't it already represented as in the crypto draft - group key? - Generally group key could be per one area (i.e, all interfaces in = that area uses the same key) - but, in virtual link scenario if area key is being used today this= has to be same for=20 - backbone area - transit area - non-backbone area =20 =20 From uma.chunduri@ericsson.com Fri Sep 2 16:20:33 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3675021F8D16 for ; Fri, 2 Sep 2011 16:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cm9Se3S2EPlw for ; Fri, 2 Sep 2011 16:20:31 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3528D21F8CFF for ; Fri, 2 Sep 2011 16:20:26 -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 p82NK1sA022832 for ; Fri, 2 Sep 2011 18:22:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 2 Sep 2011 19:20:14 -0400 From: Uma Chunduri To: "karp@ietf.org" Date: Fri, 2 Sep 2011 19:20:13 -0400 Thread-Topic: KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: Acxpxt2lJwFaVd55Q/CskUSyq7Vraw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D107912E8635F0CEUSAACMS0701e_" MIME-Version: 1.0 Subject: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 02 Sep 2011 23:20:33 -0000 --_000_D1D8138DDF34B34B8BC68A11262D107912E8635F0CEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was a discussion on traffic selectors needed or not during the last i= etf meeting (IETF81). Recap on the discussion: =3D=3D=3D SH: May have multiple SAs for, say, multiple protocols. Share IKE SAs. Steve Kent (SK): Asked about more values in the SA. Suggested traffic selec= tors. SH: Only Protocol ID is needed. SK: Disagrees. Before you throw something away, traffic selectors were desi= gned to do this. Code reuse. SH: The traffic selectors would be different at the bit-level. Ports. TK: Encouraged keeping existing SA payload structures-complicated to change= . --- Uma Chunduri (UC): Need source port numbers. SH: Disagrees. Will you have multiple BGP SAs between the same two endpoint= s? Not clear this needs to be negotiated at the IKE layer. =3D=3D=3D=3D=3D Apart from the protocol ID to differentiate multiple child SA's (BGP, LDP) = between the same peers, it's possible there could be multiple TCP connectio= ns between the same peers for the same routing protocol. Please refer IDR WG draft: http://datatracker.ietf.org/doc/draft-ietf-idr-b= gp-multisession/ So all these BGP connections between same peers can be differentiated by so= urce port, which is part of the traffic selectors. If it is not already considered, probably traffic selectors need to be cons= idered in the next revision of the combined IKEv2 based KMP draft. -Uma --_000_D1D8138DDF34B34B8BC68A11262D107912E8635F0CEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There was a discussion on traffic selectors needed or not during the l= ast ietf meeting (IETF81).
 
Recap on the discussion:
 
=3D=3D=3D
SH: May have multiple SAs for, say, multiple protocol= s. Share IKE SAs.
 
Steve Kent (SK): Asked about more values in the SA. S= uggested traffic selectors.
 
SH: Only Protocol ID is needed.
 
SK: Disagrees. Before you throw something away, traff= ic selectors were designed to do this. Code reuse.
 
SH: The traffic selectors would be different at the b= it-level. Ports.
 
TK: Encouraged keeping existing SA payload structures= —complicated to change.
 
---
 
Uma Chunduri (UC): Need source port numbers. <= /div>
 
SH: Disagrees. Will you have multiple BGP SAs between= the same two endpoints? Not clear this needs to be negotiated at the IKE l= ayer.
 
=3D=3D=3D=3D=3D
 
 
Apart from the protocol ID to differentiate multiple child SA's (BGP, = LDP) between the same peers, it's possible there could be multiple TCP conn= ections  between the same peers for the same routing protocol.
So all these BGP connections between same peers can be differentiated = by source port, which is part of the traffic selectors.
 
If it is not already considered, probably traffic selectors need to be= considered in the next revision of the combined IKEv2 based  KMP draf= t.
 
-Uma
 
 
 
 --_000_D1D8138DDF34B34B8BC68A11262D107912E8635F0CEUSAACMS0701e_-- From jmh@joelhalpern.com Mon Sep 12 11:34:09 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8B21F8C46 for ; Mon, 12 Sep 2011 11:34:09 -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.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek0KaJoWw8-R for ; Mon, 12 Sep 2011 11:34:08 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 8C94321F8C56 for ; Mon, 12 Sep 2011 11:34:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2870F43B314 for ; Mon, 12 Sep 2011 11:36:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-124.clppva.btas.verizon.net [71.161.50.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 863A043B311 for ; Mon, 12 Sep 2011 11:36:11 -0700 (PDT) Message-ID: <4E6E5119.4060902@joelhalpern.com> Date: Mon, 12 Sep 2011 14:36:09 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "karp@ietf.org" References: <20110912182724.26813.11921.idtracker@ietfa.amsl.com> In-Reply-To: <20110912182724.26813.11921.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110912182724.26813.11921.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: Document Action: 'Applicability of Keying Methods for RSVP Security' to Informational RFC (draft-ietf-tsvwg-rsvp-security-groupkeying-11.txt) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 18:34:09 -0000 For our RSVP-TE Work. Yours, Joel -------- Original Message -------- Subject: Document Action: 'Applicability of Keying Methods for RSVP Security' to Informational RFC (draft-ietf-tsvwg-rsvp-security-groupkeying-11.txt) Date: Mon, 12 Sep 2011 11:27:24 -0700 From: The IESG To: IETF-Announce CC: RFC Editor The IESG has approved the following document: - 'Applicability of Keying Methods for RSVP Security' (draft-ietf-tsvwg-rsvp-security-groupkeying-11.txt) as an Informational RFC This document is the product of the Transport Area Working Group. The IESG contact persons are David Harrington and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/ Technical Summary The Resource reSerVation Protocol [RFC2205] allows hop-by-hop authentication of RSVP neighbors, as specified in [RFC2747]. In this mode, an integrity object is attached to each RSVP message to transmit a keyed message digest. This message digest allows the recipient to verify the identity of the RSVP node that sent the message, and to validate the integrity of the message. Through the inclusion of a sequence number in the scope of the digest, the digest also offers replay protection. This document discusses a variety of keying methods and their applicability to different RSVP deployment environments, for both message integrity and encryption. It is meant as a comparative guide to understand where each RSVP keying method is best deployed, and the limitations of each method. Furthermore, it discusses how RSVP hop by hop authentication is impacted in the presence of non-RSVP nodes, or subverted nodes, in the reservation path. The document "RSVP Security Properties" ([RFC4230]) provides an overview of RSVP security, including RSVP Cryptographic Authentication [RFC2747], but does not discuss key management. It states that "RFC 2205 assumes that security associations are already available". The present document focuses specifically on key management with different key types, including group keys. Therefore this document complements [RFC4230]. Working Group Summary Understanding that 'strong' consensus is nearly impossible in an open area WG such as TSVWG, with 5-6 sub-groups within this WG divided along technology focuses -- there is unwavering consensus in the WG amongst interested parties to publish this document. It has been reviewed by several people in the WG last call. Comments raised have been addressed, including those from the Sec-dir. A question was raised by the AD about the wording in the IPR declaration (does the non-assert include Informational documents?) The WG discussed this IPR declaration and have no objection to publishing. Document Quality Key members of the WG have reviewed this document. This was reviewed by the RSVP Directorate. Stephen Kent provided a detailed secdir review. Personnel Document Shepherd: James Polk. Responsible Area Director: David Harrington There are no IANA registrations specified by this document. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From jmh@joelhalpern.com Mon Sep 19 08:33:38 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28F521F8BF4; Mon, 19 Sep 2011 08:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nADAf1Nn2Vyc; Mon, 19 Sep 2011 08:33:38 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 45BE021F8B8C; Mon, 19 Sep 2011 08:33:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C12E4300FC; Mon, 19 Sep 2011 08:36:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-99.clppva.btas.verizon.net [71.161.52.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id D079D4300C4; Mon, 19 Sep 2011 08:35:59 -0700 (PDT) Message-ID: <4E77615D.80700@joelhalpern.com> Date: Mon, 19 Sep 2011 11:35:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" References: <20110918020538.C7C5821F86EC@ietfa.amsl.com> In-Reply-To: <20110918020538.C7C5821F86EC@ietfa.amsl.com> X-Forwarded-Message-Id: <20110918020538.C7C5821F86EC@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------060105010908010501040304" Subject: [karp] Fwd: Nomcom 2011-2012: Second Call for Nominations X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 15:33:38 -0000 This is a multi-part message in MIME format. --------------060105010908010501040304 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Please help by nominating folks (yourself, or other people you beleive can do the job well.) Thank you, Joel -------- Original Message -------- Subject: Nomcom 2011-2012: Second Call for Nominations Date: Sat, 17 Sep 2011 19:05:38 -0700 (PDT) From: NomCom Chair To: IETF Announcement list CC: ietf@ietf.org Hi All, We are halfway through the nomination period (it ends on October 2, 2011) and we need more nominees than we have received so far. We appreciate the folks that have taken the time to nominate people and those who have accepted so far. But the fact remains that the number of nominations have been below average and the acceptance rates of those nominated has also been low. We need **YOUR** input and participation! We cannot properly execute the task of selecting the best candidates for these positions with so few nominations and acceptances. So, please consider making nominations for the open positions, in particular those for which we have so few nominations – it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? Well, even if you think a willing incumbent is doing a very good job and should be returned, his or her ability to serve again might be impacted by unforeseen circumstances between now and March. NomCom needs to consider multiple nominees to be prepared in the event one or more candidates is unable to serve come next March and to ensure we have chosen the best candidate. There are several ways you can help the Nomcom - You can nominate yourself. - You can nominate someone you know whom you think would do a good job. Don't worry about whether they might already be nominated. We would much prefer to receive the same nomination several times rather than miss a good person we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, and forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/3049/ You can enter a nomination by going to the following URL: https://www.ietf.org/group/nomcom/2011/nominate You can also nominate someone by sending an email to nomcom11@ietf.org and giving us their name, email address and the open position you are nominating them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf login and password. If you need a login and password, request one from the following URL: https://datatracker.ietf.org/accounts/create/ Open List: ---------- As you already know, NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- The open list is currently available on the Nomcom page and the entire community is invited to provide feedback on all nominees. You can provide your comments on all willing nominees at the following URL: https://www.ietf.org/group/nomcom/2011/input/ Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com --------------060105010908010501040304 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklldGYg bWFpbGluZyBsaXN0DQpJZXRmQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lldGYNCg0K --------------060105010908010501040304-- From jmh@joelhalpern.com Wed Sep 21 08:40:09 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E711F0C91 for ; Wed, 21 Sep 2011 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49biZsjyKDYu for ; Wed, 21 Sep 2011 08:40:09 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 29F6B1F0C90 for ; Wed, 21 Sep 2011 08:40:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 474404300FC for ; Wed, 21 Sep 2011 08:42:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-175.clppva.btas.verizon.net [71.161.51.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id DA0644300F7 for ; Wed, 21 Sep 2011 08:42:37 -0700 (PDT) Message-ID: <4E7A05EE.3070902@joelhalpern.com> Date: Wed, 21 Sep 2011 11:42:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Question fro Security AD review 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, 21 Sep 2011 15:40:09 -0000 Stephen noted that section 3.2 says taht keys "must" be changed when an operator who has access to them leaves. It seems to me that such a a change is an operational matter, subject to operational trade-offs. (Stephens reaction was stronger.) Do we really want a "must" for this? Thank you, Joel From jmh@joelhalpern.com Wed Sep 21 08:45:32 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 702741F0C65 for ; Wed, 21 Sep 2011 08:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBZEEEIXdYVb for ; Wed, 21 Sep 2011 08:45:31 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id C67471F0C84 for ; Wed, 21 Sep 2011 08:45:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EE072430104 for ; Wed, 21 Sep 2011 08:48:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-175.clppva.btas.verizon.net [71.161.51.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 646894300FE for ; Wed, 21 Sep 2011 08:48:00 -0700 (PDT) Message-ID: <4E7A0731.8030301@joelhalpern.com> Date: Wed, 21 Sep 2011 11:48:01 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] design guidelines document editorial comments 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, 21 Sep 2011 15:45:32 -0000 Stephen noted that Section two refers to phase 2 of the work, but the first description of the phases is later. We should have a description of the phases in the introduction. The remaining comments he has also need action: - Section 3.1: "will be very secret" seems optimistic (and is presumably referring only to the private component of the key pair). "will not be subject to change" seems to make a lot of assumptions. I've never heard tell of a dictionary attack on an asymmetric key pair - why even mention it? - Section 3.1: asymmetric algorithm key lengths are discussed in rfc 3766 and in the literature, some references would be good here (and maybe better than the current text) in particular to the "NIST guidlines" cited but not referenced. - 3.1: s/Once asymmetric key pair/Once an asymmetric key pair/ - 3.1 is missing references to rfcs related to PKI (5280 etc.) - 3.2 says "using the key chains" - what are those? There is at least a missing reference. And use "key chain" or "keychain" but not both. - 4.1: The first paragraph here is confusing. I don't get what "KARP parameters" might mean. - 4.1: References for "inter-connection replay" and "two time pads" would be good. - Section 6 says: "Design teams while defining the new authentication and security mechanisms MUST design in such a manner that the routing protocol authentication mechanism remains oblivious of how the keying material is derived." What does that mean? How does one validate the MUST there? Does it really mean that a 'pluggable' KDF must be used to generate keying material? If so, why not say so? - There are many typos. Too many to identify. - Section 7.1 says "...use of a KMP network-wide increases peer-wise security so greatly." I don't think that can be justified in the absence of a specific KMP. - Section 7.3 says: "In this context, the attack target size represents the number of unique routing exchanges across a network that an attacker may be able to observe in order to gain security association credentials, i.e. crack the keys." I disagree with that. I don't know how "attack size" is defined, but it sounds like you should be discussing the impact of a successful attack. Also, "cracking" keys by observing routing exchanges should really not be possible and doesn't distinguish between key management schemes - if that's possible, the routing protocol's security mechanism is just broken at least for any sensible number of (pairs of) nodes, or else a weak key has been chosen. - Section 7.4: I've no idea what "one routing peer-to-peer key management protocol exchanges" means. - Section 7.4: I think peer-to-peer isn't a great term here. Maybe router-to-router would be better? - Section 7.4: " The desired end goal for KARP WG is develop a strong peer-to- peer KMP as an Out-of-and external Key Management protocol is out of scope." Huh? From jmh@joelhalpern.com Wed Sep 21 08:58:37 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 EB46B1F0CA9 for ; Wed, 21 Sep 2011 08:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3ju+n5roc0C for ; Wed, 21 Sep 2011 08:58:37 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 9560D1F0C99 for ; Wed, 21 Sep 2011 08:58:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BFDA6430104 for ; Wed, 21 Sep 2011 09:01:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-175.clppva.btas.verizon.net [71.161.51.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 592624300FD for ; Wed, 21 Sep 2011 09:01:06 -0700 (PDT) Message-ID: <4E7A0A43.9030009@joelhalpern.com> Date: Wed, 21 Sep 2011 12:01:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "karp@ietf.org" References: <4E7A05EE.3070902@joelhalpern.com> In-Reply-To: <4E7A05EE.3070902@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [karp] Question fro Security AD review 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, 21 Sep 2011 15:58:38 -0000 Since I managed to sloppily leave out the document title, this is about the design guidelines document. Joel On 9/21/2011 11:42 AM, Joel M. Halpern wrote: > Stephen noted that section 3.2 says taht keys "must" be changed when an > operator who has access to them leaves. > It seems to me that such a a change is an operational matter, subject to > operational trade-offs. (Stephens reaction was stronger.) > > Do we really want a "must" for this? > > Thank you, > Joel > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From jmh@joelhalpern.com Wed Sep 21 10:38:24 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 13B9A1F0CB0; Wed, 21 Sep 2011 10:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doZRwjYbbIFY; Wed, 21 Sep 2011 10:38:23 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2721F0CA0; Wed, 21 Sep 2011 10:38:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CE88E4300FA; Wed, 21 Sep 2011 10:40:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-175.clppva.btas.verizon.net [71.161.51.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id D616A4300A4; Wed, 21 Sep 2011 10:40:50 -0700 (PDT) Message-ID: <4E7A21A3.1040600@joelhalpern.com> Date: Wed, 21 Sep 2011 13:40:51 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "karp@ietf.org" References: , <7C362EEF9C7896468B36C9B79200D8350D0052824D@INBANSXCHMBSA1.in.alcatel-lucent.com> , <4E79FB39.1020802@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ops-dir@ietf.org, Michael Sneed Subject: Re: [karp] Operations Directorate Review of draft-ietf-karp-design-guide-03 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, 21 Sep 2011 17:38:24 -0000 Well, changing hats, this appears to be a new requirement. It does not appear in the requirements document. It has not, up till now, been agreed by the working groups. And we are a bit short of time. If other folks in the WG think Michael is right about this issue, and that it should appear in the design guidelines document, please speak up now. Yours, Joel M. Halpern PS: Getting the security right for such a verification capability strikes me personally as rather challenging. On 9/21/2011 1:11 PM, Michael Sneed wrote: > I think you can argue that it is out of scope, and that such concerns > belong at the implementation level or in a management document. But I > also think that operations folks need to be able to confirm that key > management is functioning as expected, apart from whether or not the > endpoints are able to communicate. If authentication fails, why? Can it > be verified that fresh keys are in use after a key employee leaves? etc. > > > Date: Wed, 21 Sep 2011 10:56:57 -0400 > > From: jmh@joelhalpern.com > > To: sneedmike@hotmail.com > > CC: manav.bhatia@alcatel-lucent.com; ops-dir@ietf.org; > gregory.ietf@gmail.com; karp-chairs@tools.ietf.org > > Subject: Re: Operations Directorate Review of > draft-ietf-karp-design-guide-03 > > > > Speaking personally, I am not sure that what you describe is desirable > > or falls within KARP scope. > > > > For example, one can easily argue that the problem is "detectable" if > > the devices log authentication failures on association attempts. Which > > they do. > > Presumably, the KMPs themselves will detect actual protocol violations > > of those protocols. I would not call such detection out as a separate > > work item. > > > > And I certainly would not want a mechanism that reported the actual keys > > back for validation, since that would induce weaknesses in the system. > > > > So I am not at all clear on what can be added to the design guidelines > > document. > > > > Yours, > > Joel > > > > On 9/21/2011 7:30 AM, Michael Sneed wrote: > > > Hi Manav, > > > > > > That is largely my concern. If keying doesn't work, then the part > of the > > > protocol protected by the key either doesn't work (eg. the peers are > > > operating with different key generations), or possibly isn't secure > (eg. > > > a rekey did not take place on schedule). Depending on the KMP in use > > > there might be a number of ways this could happen, and it just > seemed to > > > me that it would be worthwhile to address that this should be > > > recoverable, detectable, and debuggable. > > > > > > > > > From: manav.bhatia@alcatel-lucent.com > > > To: sneedmike@hotmail.com; ops-dir@ietf.org > > > CC: gregory.ietf@gmail.com; karp-chairs@tools.ietf.org > > > Date: Wed, 21 Sep 2011 09:57:57 +0530 > > > Subject: RE: Operations Directorate Review of > > > draft-ietf-karp-design-guide-03 > > > > > > Hi Michael, > > > Can you elaborate on what you mean by "wrong key can have negative > > > consequences"? For a routing protocol, a wrong key would simply result > > > in the adjacency not coming up. Besides this, i cant see what else can > > > go wrong. > > > Cheers, Manav > > > > > > *From:* Michael Sneed [mailto:sneedmike@hotmail.com] > > > *Sent:* Tuesday, September 20, 2011 5:03 PM > > > *To:* ops-dir > > > *Cc:* gregory.ietf@gmail.com; Bhatia, Manav (Manav) > > > *Subject:* Operations Directorate Review of > > > draft-ietf-karp-design-guide-03 > > > > > > I have performed a review of draft-ietf-karp-design-guide-03 on > > > behalf of the Operations Directorate. > > > The document is intended for Informational status, and describes a > > > framework and design guidelines for key management targeted at > > > protection of routing protocols. > > > > > > The document does a good job of covering most of the areas of > > > operational concern in this area. The only subject that I did not > > > see mentioned was prevention and recovery from miskeys. > > > Since a failed key delivery or delivery of the wrong key can have > > > negative consequences for the protected protocol this could be an > > > important concern. > > > > > > Other than this point I found no operational issues with this document. > > > From jmh@joelhalpern.com Wed Sep 21 15:25:56 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 327521F0CF6 for ; Wed, 21 Sep 2011 15:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufmShDpRgMpE for ; Wed, 21 Sep 2011 15:25:51 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 03DB91F0CF1 for ; Wed, 21 Sep 2011 15:25:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9AD3143010E for ; Wed, 21 Sep 2011 15:28:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-29.clppva.btas.verizon.net [71.161.52.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id DD4094300FD for ; Wed, 21 Sep 2011 15:28:19 -0700 (PDT) Message-ID: <4E7A6503.4050700@joelhalpern.com> Date: Wed, 21 Sep 2011 18:28:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "karp@ietf.org" References: <20110921221157.28047.23606.idtracker@ietfa.amsl.com> In-Reply-To: <20110921221157.28047.23606.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110921221157.28047.23606.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: Adrian Farrel's Yes on draft-ietf-karp-design-guide-03: (with COMMENT) 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, 21 Sep 2011 22:25:56 -0000 Authors, please respond to the comments promptly. Thank you, Joel -------- Original Message -------- Subject: Adrian Farrel's Yes on draft-ietf-karp-design-guide-03: (with COMMENT) Date: Wed, 21 Sep 2011 15:11:57 -0700 From: Adrian Farrel To: The IESG CC: karp-chairs@tools.ietf.org, draft-ietf-karp-design-guide@tools.ietf.org Adrian Farrel has entered the following ballot position for draft-ietf-karp-design-guide-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for your work on this important document. I am balloting "Yes", but I have a small raft of comments that you should look through. --- There is no need to include a reference to RFC 3036. That has been obsoleted and is no more. --- Section 1 o More secure mechanisms and practices for operating routers. This work is being addressed in the OPSEC Working Group. Increased security or increased number? Please clarify. --- Section 2 and have design teams focus on the specification work within those groupings. I think you can leave out this piece of IETF process that may or may not be executed as it is not really relevant to the discussion of how the protocols are split up on the road map or in this document. Similarly OLD so that the work can be easily leveraged by the various Routing Protocol teams. NEW so that the work can be easily leveraged by for use in the various Routing Protocol groupings. --- Section 2 It is believed that the groupings will have like requirements for their authentication mechanisms, and that reuse of authentication mechanisms will be greatest within these grouping. Yeah I know what you mean :-) How about: The protocols will be grouped according to the requirements for authentication mechanisms that they are believed to have, and it is assumed that reuse of authentication mechanisms will be possible and deisrable within each group. --- Section 2.1 s/some mechanism for some protocols/some mechanisms for some protocols/ --- Section 2.1 The first categorization defines four types of messaging transactions used on the wire by the base Routing Protocol. You go on to list only three mechanisms under sub-headings. It is possible that you intend "Mixed" to be the fourth type. --- Section 2.2 OLD The second axis of categorization groups protocols by the NEW The second axis of categorization groups protocols is by the --- Section 2.2 Peer keying One router sends the keying messages directly and only to one other router, such that a one-to-one, unique keying security association (SA) is established between the two routers. This would be employed by protocols like BGP, BFD, LDP, etc. How "direct" does the sending have to be? For example, can't it be via a trusted proxy or key server? I am not sure that "directly" is relevant to the distinction that needs to be drawn between "peer keying" and "group keying". (And, for what it is worth, "directly" means in time, and "direct" means in space - except in some US usage where meaning has become confusnicatified.) --- Section 2.2 Peer keying This would be employed by protocols like BGP, BFD, LDP, etc. The "etc." is very ambiguous in this case because the last time protocols were mentioned in groupings they included other protocols along with BGP, BFD, and LDP. One was RSVP-TE and we know that group keys are potentially applicable to RSVP-TE. Maybe just strike "etc." as it is bad style to say "such as" (which you mean in place of "like") and "etc." in the same clause. --- Section 3.1 The form of the identity proof could be either raw keys, the more easily administrable self-signed certificate format, or a PKI issued certificate credential. I think you intend there to be a choice of three options here, in which case delete "either" to avoid confusion. --- Section 3.2 This one is almost at the level of a Discuss... Additionally, key chains will not help if the routing transport subsystem does not support rolling over to the new keys without bouncing the adjacencies. So the first step is to fix all routing protocols so that they can change keys without breaking or bouncing the adjacencies. It is not clear that the conclusion is correct. This is certainly an option, but so are: - changing usage such that the routing protocol uses a different routing transport subsystem that does not bounce the adjacency - changing (fixing?) the preferred routing tansport subsystem such that it does not bounce the adjacensy --- Section 5 Would it be OK to add PCEP [RFC5440] to the category "BGP, LDP and MSDP" as it runs over TCP, is peer-based, and would simply pick up TCP-AO in the same way as BGP? --- Section 5 I find no fault with the discussion of "RSVP and RSVP-TE", but I note that other categories in this section describe the categroy in a brief(ish) paragraph while for RSVP we have a lecture. This also seems to make use of RFC2119 language in earnest. Is that right? Does this text actually belong in one of the later, protocol- specific documents? From jmh@joelhalpern.com Thu Sep 22 07:33:34 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C4321F8C2D for ; Thu, 22 Sep 2011 07:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwUY6hJ0ES-I for ; Thu, 22 Sep 2011 07:33:32 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6A421F8C1F for ; Thu, 22 Sep 2011 07:33:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4CA604300D2; Thu, 22 Sep 2011 07:36:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-29.clppva.btas.verizon.net [71.161.52.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 631F34300EF; Thu, 22 Sep 2011 07:36:01 -0700 (PDT) Message-ID: <4E7B47D0.7090703@joelhalpern.com> Date: Thu, 22 Sep 2011 10:36:00 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: draft-ietf-karp-design-guide@tools.ietf.org References: <20110921121722.15062.8624.idtracker@ietfa.amsl.com> <4E7A0724.8040504@joelhalpern.com> <4E7B263D.3020001@cs.tcd.ie> In-Reply-To: <4E7B263D.3020001@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "karp@ietf.org" , Stephen Farrell Subject: Re: [karp] Stephen Farrell's Discuss on draft-ietf-karp-design-guide-03: (with DISCUSS and COMMENT) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 14:33:35 -0000 Additional follow ups, based on clarifications from Stephen, which are I believe now actionable for the authors. On 9/22/2011 8:12 AM, Stephen Farrell wrote: > > Hi Joel, ... >>> (3) Section 2 calls out "several" categories (though only two are >>> identified?) and says that the hope is to have one design team per >>> category, and "down the road," one KMP per category. I don't >>> understand what's being presented here, e.g. how many KMPs are >>> envisaged - just two (mapping to sections 2.1 and 2.2) or something >>> else? >> >> The "several" I believe is because in earlier versions there were moe >> branches, and it got pruned. In terms of gap analysis, it is varying >> whether we have a design team for the category, or for the individual >> protocol. In part this is because there is more variation among some >> subsets than others. >> With regard to the number of KMPs, the effort was to write this to >> reinforce that fewer distinct protocols is better, but not to decide the >> question of whether we have 1 or 2. >> Can you suggest modifications that would make this clearer? > > Enumerating the planned design teams clearly. A list should do it. Please add the above enumeration to the document. > >>> (4) I don't get why 3.1 talks about SHA-1 fingerprints. It seems >>> very unlikely that any new KMP would use SHA-1 like this. >> >> Is there some simple mechanism we should describe instead? > > I don't believe you're at the point of identifying mechanisms > yet, never mind hash functions and even if you were then you > would not, today, pick sha-1. (Its no longer "modern":-) Please remove the reference to sha-1, and find a better way to say what we mean. > >>> (5) Are you really saying that keys MUST (in 2119 terms) be changed >>> "when an operator leaves" (section 3.2)? That seems plain wrong. >> >> That does seem too strong. I will send a separate note to the KARP list >> to see if we can weaken it. Would changing that to a "should" work for >> you? > > Don't think so. I guess operators employ a lot of people and store > thousands of keys. Not all keys should be changed when any employee > leaves. Saying "sometimes, you may need to change a key after an > employee has moved on" would be fine. But doesn't seem that interesting. > Maybe just delete the sentence? I think we want to leave the reference to employees departing. But It clearly needs much clearer wording. While just saying that we mean employees with key access, that is also slightly misleading (as who really has key access can be ambiguous), so this needs to be toned down to a description a common concern. ... >>> (7) Section 6 says "while defining the new...mechanisms." Why >>> are you ruling re-use of existing mechanisms out of scope? >> The mechanism is at the very least new to the context where it is being >> introduced. The intention is definitely NOT to prohibit reuse of >> technology (IKE/IPSEC, or any other existing security technology. But if >> it were already being used fully and properly, then the design team >> would simply say "nothing to do", which would be veyr nice. The new is >> because they are introducing something. Can you help with wording to >> make that clearer? > > Say that "If new mechanisms are needed, then..." and that'd be fine. > >>> (8) Section 7.4 seems to say that if a PSK is stolen, that that >>> doesn't expose the traffic key presumably derived from the PSK via a >>> standard, openly defined KMP. That just seems wrong. The text in >>> question is: "They may gain access to key derivation material, like a >>> PSK, but not current traffic keys in use." >> >> The document does seem to be making too strong a claim here. We need >> clearer words. After all, TCP-AO has the property that if the pre-shared >> key is known, then the session keys are also known. (I think that is >> your point Stephen?) > > Right. As sent earlier, Stephen confirms the understanding of what needs to be fixed here. Yours, Joel From manav.bhatia@alcatel-lucent.com Thu Sep 22 18:21:41 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 0040C21F8BD5 for ; Thu, 22 Sep 2011 18:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsI8MkWM5McH for ; Thu, 22 Sep 2011 18:21:40 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 54D0C21F8BCD for ; Thu, 22 Sep 2011 18:21:40 -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 p8N1O9W2001335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 20:24:12 -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 p8N1O84f005736 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Sep 2011 06:54:09 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 23 Sep 2011 06:54:08 +0530 From: "Bhatia, Manav (Manav)" To: "Joel M. Halpern" , "karp@ietf.org" Date: Fri, 23 Sep 2011 06:54:06 +0530 Thread-Topic: [karp] Question fro Security AD review Thread-Index: Acx4dRyT+xJQmKxfQJSaS3B09pbUbABGf7Sw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D0052871B@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4E7A05EE.3070902@joelhalpern.com> In-Reply-To: <4E7A05EE.3070902@joelhalpern.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 Subject: Re: [karp] Question fro Security AD review 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, 23 Sep 2011 01:21:41 -0000 Does the following text look ok: "Cryptographic keys should have a limited lifetime and may need to be chang= ed when an operator who had access to them leaves." This is to address the ADs comment that operators could employ lot of peopl= e and may store thousands of keys. Not all keys would need to be changed wh= en any employee leaves. Cheers, Manav=20 > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Joel M. Halpern > Sent: Wednesday, September 21, 2011 9:13 PM > To: karp@ietf.org > Subject: [karp] Question fro Security AD review >=20 > Stephen noted that section 3.2 says taht keys "must" be=20 > changed when an operator who has access to them leaves. > It seems to me that such a a change is an operational matter,=20 > subject to operational trade-offs. (Stephens reaction was stronger.) >=20 > Do we really want a "must" for this? >=20 > Thank you, > Joel > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From jmh@joelhalpern.com Thu Sep 22 19:10:12 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 54DD821F8906 for ; Thu, 22 Sep 2011 19:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB28L8hEodU3 for ; Thu, 22 Sep 2011 19:10:11 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id AEBD521F88B6 for ; Thu, 22 Sep 2011 19:10:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C17B44300CC; Thu, 22 Sep 2011 19:12:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-29.clppva.btas.verizon.net [71.161.52.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 153F8430076; Thu, 22 Sep 2011 19:12:17 -0700 (PDT) Message-ID: <4E7BEB01.9020600@joelhalpern.com> Date: Thu, 22 Sep 2011 22:12:17 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4E7A05EE.3070902@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350D0052871B@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D0052871B@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen Farrell , "karp@ietf.org" Subject: Re: [karp] Question fro Security AD review 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, 23 Sep 2011 02:10:12 -0000 That seems like it ought to suffice. Stephen? Thanks, Joel On 9/22/2011 9:24 PM, Bhatia, Manav (Manav) wrote: > Does the following text look ok: > > "Cryptographic keys should have a limited lifetime and may need to be changed when an operator who had access to them leaves." > > This is to address the ADs comment that operators could employ lot of people and may store thousands of keys. Not all keys would need to be changed when any employee leaves. > > Cheers, Manav > >> -----Original Message----- >> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On >> Behalf Of Joel M. Halpern >> Sent: Wednesday, September 21, 2011 9:13 PM >> To: karp@ietf.org >> Subject: [karp] Question fro Security AD review >> >> Stephen noted that section 3.2 says taht keys "must" be >> changed when an operator who has access to them leaves. >> It seems to me that such a a change is an operational matter, >> subject to operational trade-offs. (Stephens reaction was stronger.) >> >> Do we really want a "must" for this? >> >> Thank you, >> Joel >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >> From stephen.farrell@cs.tcd.ie Fri Sep 23 00:12:42 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7888721F886A for ; Fri, 23 Sep 2011 00:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.203 X-Spam-Level: X-Spam-Status: No, score=-105.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChazehvxrcvR for ; Fri, 23 Sep 2011 00:12:40 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 755F821F87E2 for ; Fri, 23 Sep 2011 00:12:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 25EAD171CE9; Fri, 23 Sep 2011 08:15:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1316762103; bh=+PQRj gHH5wePhjTAYX4ti0ASCzMIbFczIdS5v50xQxo=; b=HhWN7OstEtcBUEmEHwJyX tmNvKQ6E6LTxTONlGUsPEf8FIC+k7NdblFrD1ZtuDdkg7o8OxXRSc3zGok6duU0W KlDV2gvzlyUnnx+dvNBRHIBCZt5TKmeKx4kSe/W1GYaGHGv04ei2gLKEdwoUOTTA kMidh4A5pseLNN0GAH19o6V+3ggg02pYR/n5S3/7Yq7TDWzTXKsBsfJFA/lHMS6Y Qn2YsWkaQM6fwO4J1dTboeX7uqSyd0bC6kFeUK90Klw0yeFRY6w//1v7K+4agtKE y/yUsL51jCWg6vEAFJ8WHiSuMjN01y5aX4xxO6iMmkQiQXt9ySMnrpmt0iKE9EKQ A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ZLvOp8Qdyysp; Fri, 23 Sep 2011 08:15:03 +0100 (IST) Received: from [10.87.48.5] (unknown [86.46.30.134]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7A49A171CE8; Fri, 23 Sep 2011 08:15:00 +0100 (IST) References: <4E7A05EE.3070902@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350D0052871B@INBANSXCHMBSA1.in.alcatel-lucent.com> <4E7BEB01.9020600@joelhalpern.com> In-Reply-To: <4E7BEB01.9020600@joelhalpern.com> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6FF71FD6-0D02-4E82-8578-940C78C37439@cs.tcd.ie> X-Mailer: iPhone Mail (8L1) From: Stephen Farrell Date: Fri, 23 Sep 2011 08:14:57 +0100 To: "Joel M. Halpern" X-Mailman-Approved-At: Fri, 23 Sep 2011 06:46:54 -0700 Cc: "karp@ietf.org" Subject: Re: [karp] Question fro Security AD review 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, 23 Sep 2011 07:12:42 -0000 Works for me S On 23 Sep 2011, at 03:12, "Joel M. Halpern" wrote: > That seems like it ought to suffice. Stephen? > Thanks, > Joel >=20 > On 9/22/2011 9:24 PM, Bhatia, Manav (Manav) wrote: >> Does the following text look ok: >>=20 >> "Cryptographic keys should have a limited lifetime and may need to be cha= nged when an operator who had access to them leaves." >>=20 >> This is to address the ADs comment that operators could employ lot of peo= ple and may store thousands of keys. Not all keys would need to be changed w= hen any employee leaves. >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- >>> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On >>> Behalf Of Joel M. Halpern >>> Sent: Wednesday, September 21, 2011 9:13 PM >>> To: karp@ietf.org >>> Subject: [karp] Question fro Security AD review >>>=20 >>> Stephen noted that section 3.2 says taht keys "must" be >>> changed when an operator who has access to them leaves. >>> It seems to me that such a a change is an operational matter, >>> subject to operational trade-offs. (Stephens reaction was stronger.) >>>=20 >>> Do we really want a "must" for this? >>>=20 >>> Thank you, >>> Joel >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>>=20 From carter@qosient.com Fri Sep 23 07:19:14 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 8576321F8CBD for ; Fri, 23 Sep 2011 07:19:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgfYKwMIyxkw for ; Fri, 23 Sep 2011 07:19:14 -0700 (PDT) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by ietfa.amsl.com (Postfix) with SMTP id A718521F8C7F for ; Fri, 23 Sep 2011 07:19:13 -0700 (PDT) Received: (qmail 36494 invoked from network); 23 Sep 2011 14:21:44 -0000 Received: from 207.237.36.98 (HELO thoth.newyork.qosient.com) (207.237.36.98) by relay00.pair.com with SMTP; 23 Sep 2011 14:21:44 -0000 X-pair-Authenticated: 207.237.36.98 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_398F938D-CE97-4F34-BC0F-0DC05705F890"; protocol="application/pkcs7-signature"; micalg=sha1 From: Carter Bullard In-Reply-To: <6FF71FD6-0D02-4E82-8578-940C78C37439@cs.tcd.ie> Date: Fri, 23 Sep 2011 10:21:44 -0400 Message-Id: References: <4E7A05EE.3070902@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350D0052871B@INBANSXCHMBSA1.in.alcatel-lucent.com> <4E7BEB01.9020600@joelhalpern.com> <6FF71FD6-0D02-4E82-8578-940C78C37439@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1244.3) Cc: "karp@ietf.org" Subject: Re: [karp] Question fro Security AD review 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, 23 Sep 2011 14:19:14 -0000 --Apple-Mail=_398F938D-CE97-4F34-BC0F-0DC05705F890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Gentle people, I apologize for jumping in late, but there are lots of reasons why keys = have limited lifetimes and should be changed often (for some sites that is measured in = geological time, but that is still often). And there are many, many approaches to key management. = It would seem more appropriate to say something like: "Cryptographic keys should have a limited lifetime and should be = managed using an effective management policy (see RFC 2196, Secton 4.1, = Authtentication as a guideline)." Or you can reference section 4.1.4 Password Assurance, or something like = that. While to some this reference may seem dated, it is a reference to the = IETF's Site Security Handbook, which would be where a site would specify its master key = management policy. Hope this is helpful, Carter On Sep 23, 2011, at 3:14 AM, Stephen Farrell wrote: > Works for me > S >=20 > On 23 Sep 2011, at 03:12, "Joel M. Halpern" = wrote: >=20 >> That seems like it ought to suffice. Stephen? >> Thanks, >> Joel >>=20 >> On 9/22/2011 9:24 PM, Bhatia, Manav (Manav) wrote: >>> Does the following text look ok: >>>=20 >>> "Cryptographic keys should have a limited lifetime and may need to = be changed when an operator who had access to them leaves." >>>=20 >>> This is to address the ADs comment that operators could employ lot = of people and may store thousands of keys. Not all keys would need to be = changed when any employee leaves. >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On >>>> Behalf Of Joel M. Halpern >>>> Sent: Wednesday, September 21, 2011 9:13 PM >>>> To: karp@ietf.org >>>> Subject: [karp] Question fro Security AD review >>>>=20 >>>> Stephen noted that section 3.2 says taht keys "must" be >>>> changed when an operator who has access to them leaves. >>>> It seems to me that such a a change is an operational matter, >>>> subject to operational trade-offs. (Stephens reaction was = stronger.) >>>>=20 >>>> Do we really want a "must" for this? >>>>=20 >>>> Thank you, >>>> Joel >>>> _______________________________________________ >>>> karp mailing list >>>> karp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/karp >>>>=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp >=20 --Apple-Mail=_398F938D-CE97-4F34-BC0F-0DC05705F890 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2 uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDkyMzE0MjE0NVowIwYJKoZIhvcNAQkE MRYEFHzPcEhgxp3YFpAIz+TCrXH/PQm9MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB AIa+8hiS5BMX6bhIK7IbDgB7xwUmcYB98VK09nN6ZOaFL3Kaazf/+KYZPIKvLXt1CBWpNzvO6iPF 8j61o/o4NiA9rZAxPpP9OM9SfE8SsGNXj5hHqAUDtr7BFHOSSf0L6aAoYFQFAWUYW6R/gZthQeF8 tJy8zHpCGf1bpJdQgWOUtlSiy42mtFTsRI6aYeeR1hTF3GHrWsHmJZLUmGBTKn3JphoDAQWaBrRz GLSYs7tGcjlmQfPfwATml2qCk0D8XswgD+lKdMKnrmMF6lQUzVpZqZT/EMD86ZN7TYNX1/27OGra 1FWjdwQxEgtJwNgTk0XTJWPmPcsJdLsGO1DkB+AAAAAAAAA= --Apple-Mail=_398F938D-CE97-4F34-BC0F-0DC05705F890-- From internet-drafts@ietf.org Sun Sep 25 07:04:27 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FC821F8C56; Sun, 25 Sep 2011 07:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNxt+yzNjlfd; Sun, 25 Sep 2011 07:04:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1263821F8C4F; Sun, 25 Sep 2011 07:04:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110925140427.17699.96820.idtracker@ietfa.amsl.com> Date: Sun, 25 Sep 2011 07:04:27 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-design-guide-04.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: Sun, 25 Sep 2011 14:04:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (KARP) D= esign Guidelines Author(s) : Gregory M. Lebovitz Manav Bhatia Filename : draft-ietf-karp-design-guide-04.txt Pages : 29 Date : 2011-09-25 This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. = A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-design-guide-04.txt From manav.bhatia@alcatel-lucent.com Sun Sep 25 19:43:47 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 7A0391F0C38 for ; Sun, 25 Sep 2011 19:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUNlDfJnq6DI for ; Sun, 25 Sep 2011 19:43:46 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 87DF01F0C36 for ; Sun, 25 Sep 2011 19:43:42 -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 p8Q2kKt1006028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 25 Sep 2011 21:46:23 -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 p8Q2kJ46020516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 26 Sep 2011 08:16:20 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 26 Sep 2011 08:16:19 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Mon, 26 Sep 2011 08:16:19 +0530 Thread-Topic: Stephen Farrell's Discuss on draft-ietf-karp-design-guide-04: (with DISCUSS and COMMENT) Thread-Index: Acx7rV8avhE3NOKrQUGbcBf50bAjQAANXSugAATgKZA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D005289E6@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] FW: Stephen Farrell's Discuss on draft-ietf-karp-design-guide-04: (with DISCUSS and COMMENT) 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, 26 Sep 2011 02:43:47 -0000 Just noticed that karp mailing list was not included in the original mail .= .=20 -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Monday, September 26, 2011 6:06 AM To: Stephen Farrell; The IESG Cc: karp-chairs@tools.ietf.org; draft-ietf-karp-design-guide@tools.ietf.org Subject: RE: Stephen Farrell's Discuss on draft-ietf-karp-design-guide-04: = (with DISCUSS and COMMENT) Hi Stephen, Addressing your two comments: > I don't know what "very strong keys" might be. Keys are either good or=20 > bad, not very good or very bad. Replaced the "very strong keys" with "strong keys". > =20 > I still don't see a reference for a two time pad. You really need=20 > that. I couldn't find a reference for two-time pads. We can also delete the refer= ence to two time pads as routing protocols DON'T need encryption. However, = we had included the text just in case we need encryption some time in futur= e. Using a KMP would help in that case as well.=20 Would it help if we rewrite the text as: OLD Most importantly it provides fresh traffic keying material for each session= , thus helping to prevent a number of attacks such as inter-connection repl= ay and two-time pads (applicable if encryption is required) NEW Most importantly it provides fresh traffic keying material for each session= , thus helping to prevent inter-connection replay attacks. Any fixed keystr= eam output, generated from the same key and index should only be used to en= crypt once. Re-using such keystream (jokingly called a 'two-time pad' syste= m by cryptographers), can seriously compromise security. The NSA's VENONA p= roject [VENONA] provides a historical example of such a compromise. Usually= routing protocols dont require encryption, however, if they do then using = a KMP avoids the two-time pad problem since packets from different sessions= are encrypted using distinct IVs, or, with distinct session keys or both d= istinct IVs and session keys. [VENONA] Crowell, W. P., "Introduction to the VENONA Project", http://www.= nsa.gov:8080/docs/venona/index.html Cheers, Manav From internet-drafts@ietf.org Mon Sep 26 07:34: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 89AA621F8DA4; Mon, 26 Sep 2011 07:34:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOhQgVuZT3su; Mon, 26 Sep 2011 07:34:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E533521F8CE0; Mon, 26 Sep 2011 07:34:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110926143445.4079.43578.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2011 07:34:45 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-design-guide-05.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:34:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (KARP) D= esign Guidelines Author(s) : Gregory M. Lebovitz Manav Bhatia Filename : draft-ietf-karp-design-guide-05.txt Pages : 29 Date : 2011-09-26 This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. = A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-design-guide-05.txt From hartmans@mit.edu Mon Sep 26 09:40: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 2E8DD11E80BF for ; Mon, 26 Sep 2011 09:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.379 X-Spam-Level: X-Spam-Status: No, score=-103.379 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMsuSBWtB1Ii for ; Mon, 26 Sep 2011 09:40:09 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AD4D911E80BB for ; Mon, 26 Sep 2011 09:40:09 -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 60CAA202FB; Mon, 26 Sep 2011 12:44:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 33CCA4234; Mon, 26 Sep 2011 12:42:21 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: Date: Mon, 26 Sep 2011 12:42:21 -0400 In-Reply-To: (Uma Chunduri's message of "Fri, 2 Sep 2011 19:20:13 -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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 26 Sep 2011 16:40:10 -0000 >>>>> "Uma" == Uma Chunduri writes: Uma> Apart from the protocol ID to differentiate multiple child SA's Uma> (BGP, LDP) between the same peers, it's possible there could be Uma> multiple TCP connections between the same peers for the same Uma> routing protocol. Please refer IDR WG draft: Uma> http://datatracker.ietf.org/doc/ Uma> draft-ietf-idr-bgp-multisession/ So all these BGP connections Uma> between same peers can be differentiated by source port, which Uma> is part of the traffic selectors. Uma> If it is not already considered, probably traffic selectors Uma> need to be considered in the next revision of the combined Uma> IKEv2 based KMP draft. We agree there will be multiple TCP connections. However, I've yet to see an argument for you need different outputs from the KDF in this instance. If all the TCP connections are between the same authenticated peers and have the same access control requirements, why do we need different SAs? TCP-AO will give us different traffic keys in this instance even if it is the same SA. Put another way, is the SA between BGP on peer A and BGP on peer B, or does the SA refer to BGP session x on peer A talking to BGP session y on peer B. The second is more complex in terms of the interface between the KMP and routing protocol. My opinion is that unless the second provides security value, we should take the simpler approach. From housley@vigilsec.com Mon Sep 26 10:06:38 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B283C11E80CC for ; Mon, 26 Sep 2011 10:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHiFcpmdtiP6 for ; Mon, 26 Sep 2011 10:06:38 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3C09311E80A6 for ; Mon, 26 Sep 2011 10:06:38 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C9AD7F240E6; Mon, 26 Sep 2011 13:09:46 -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 X8rvRdCZKLg2; Mon, 26 Sep 2011 13:09:20 -0400 (EDT) Received: from [192.168.147.177] (unknown [74.202.225.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 52444F2403A; Mon, 26 Sep 2011 13:09:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Mon, 26 Sep 2011 13:09:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E7A05EE.3070902@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350D0052871B@INBANSXCHMBSA1.in.alcatel-lucent.com> <4E7BEB01.9020600@joelhalpern.com> <6FF71FD6-0D02-4E82-8578-940C78C37439@cs.tcd.ie> To: Carter Bullard X-Mailer: Apple Mail (2.1084) Cc: karp@ietf.org Subject: Re: [karp] Question fro Security AD review 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, 26 Sep 2011 17:06:38 -0000 Carter: > I apologize for jumping in late, but there are lots of reasons why = keys have limited lifetimes > and should be changed often (for some sites that is measured in = geological time, but that > is still often). And there are many, many approaches to key = management. It would seem > more appropriate to say something like: >=20 > "Cryptographic keys should have a limited lifetime and should be = managed > using an effective management policy (see RFC 2196, Secton 4.1, = Authtentication > as a guideline)." Wouldn't RFC 4107 be a better reference? Or, at least an additional = reference. Russ= From uma.chunduri@ericsson.com Mon Sep 26 11:47:38 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6208721F8D19 for ; Mon, 26 Sep 2011 11:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ96HOQV0OuX for ; Mon, 26 Sep 2011 11:47:37 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2C21F8CDE for ; Mon, 26 Sep 2011 11:47:37 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8QInfxD017161; Mon, 26 Sep 2011 13:50:20 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 26 Sep 2011 14:50:02 -0400 From: Uma Chunduri To: Sam Hartman Date: Mon, 26 Sep 2011 14:50:00 -0400 Thread-Topic: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: Acx8a1t/9kuDlzywSaOm6VmjbDZpOgADJcJg Message-ID: References: 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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 26 Sep 2011 18:47:38 -0000 Uma> Apart from the protocol ID to differentiate multiple child SA's Uma> (BGP, LDP) between the same peers, it's possible there could be Uma> multiple TCP connections between the same peers for the same Uma> routing protocol. Please refer IDR WG draft: Uma> http://datatracker.ietf.org/doc/ Uma> draft-ietf-idr-bgp-multisession/ So all these BGP connections Uma> between same peers can be differentiated by source port, which Uma> is part of the traffic selectors. =20 Uma> If it is not already considered, probably traffic selectors Uma> need to be considered in the next revision of the combined Uma> IKEv2 based KMP draft. We agree there will be multiple TCP connections. However, I've yet to see = an argument for you need different outputs from the KDF in this instance. I= f all the TCP connections are between the same authenticated peers and have= the same access control requirements, why do we need different SAs? TCP-A= O will give us different traffic keys in this instance even if it is the sa= me SA. Put another way, is the SA between BGP on peer A and BGP on peer B, or does= the SA refer to BGP session x on peer A talking to BGP session y on peer B= . The second is more complex in terms of the interface between the KMP and ro= uting protocol. My opinion is that unless the second provides security value, we should tak= e the simpler approach. =3D=3D=3D=3D [Uma] You raised an important point. I would say, the second solution is not nece= ssarily complex but it's the opposite.=20 Think of it- your KMP is capable and it's giving unique session keys to pro= tect underlying session that=20 could be multiple sessions between the same end points (our case of discuss= ion) or different end points. In this case TCP-AO which is the eventual user of the keys, need not do ext= ra KDF to get the session keys=20 (just directly use the KMP keys).=20 The advantage os this approach: - Each underlying session has the capability to choose session parameter m= ore granularly=20 - E.g.: Life time even AUTH algo (BGP may select one and LDP= can select different)=20 - Limited damage in case of a key compromise (limited to the life tim= e of one session) - and as I mentioned I would argue integration with KMP is rather mo= re easier - Remember, in your case what KMP is giving to TCP-AO is KMP'= s traffic key (CHILD_SA key) to generate multiple traffic keys to protect multiple sessi= ons between same peers.=20 If we think more, the reason for KDF and key derivation in TCP-AO is for in= ter-session replay protection and this Is extremely relevant to manual keys but not keys generated with re-key cap= able KMP. But, I recognize today TCP-AO can't consume direct traffic keys from KMP, b= ut this can be changed if one see there=20 is value in it. I will pause here and would listen on what do you think. =09 =20 From hartmans@mit.edu Mon Sep 26 12:23:30 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 925201F0C7F for ; Mon, 26 Sep 2011 12:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=-1.104, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI2P26OfUisK for ; Mon, 26 Sep 2011 12:23:30 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C6E3E1F0C77 for ; Mon, 26 Sep 2011 12:23: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 A036C202FB; Mon, 26 Sep 2011 15:27:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3EDA74234; Mon, 26 Sep 2011 15:25:41 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: Date: Mon, 26 Sep 2011 15:25:41 -0400 In-Reply-To: (Uma Chunduri's message of "Mon, 26 Sep 2011 14:50:00 -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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 26 Sep 2011 19:23:30 -0000 >>>>> "Uma" == Uma Chunduri writes: > We agree there will be multiple TCP connections. However, I've > yet to see an argument for you need different outputs from the > KDF in this instance. If all the TCP connections are between > the same authenticated peers and have the same access control > requirements, why do we need different SAs? TCP-AO will give > us different traffic keys in this instance even if it is the > same SA. > Put another way, is the SA between BGP on peer A and BGP on > peer B, or does the SA refer to BGP session x on peer A talking > to BGP session y on peer B. The second is more complex in > terms of the interface between the KMP and routing protocol. > My opinion is that unless the second provides security value, > we should take the simpler approach. Uma> ==== [Uma] You raised an Uma> important point. I would say, the second solution is not Uma> necessarily complex but it's the opposite. Think of it- your Uma> KMP is capable and it's giving unique session keys to protect Uma> underlying session that could be multiple sessions between the Uma> same end points (our case of discussion) or different end Uma> points. In this case TCP-AO which is the eventual user of the Uma> keys, need not do extra KDF to get the session keys (just Uma> directly use the KMP keys). Uma> The advantage os this approach: - Each underlying session has Uma> the capability to choose session parameter more granularly - Uma> E.g.: Life time even AUTH algo (BGP may select one and LDP can Uma> select different) To show that this is an advantage, you need to show why one BGP session between two peers wants algorithm A and another wants algorithm B. (Or similar for another protocol). We already agree that BGP and LDP are different protocols and thus need different KMP keys. It seems fairly unlikely to me that different sessions between two BGP peers need different algorithms. Uma> - Limited damage in case of a key compromise Uma> - and as I mentioned Uma> I would argue integration with KMP is rather more easier - Uma> Remember, in your case what KMP is giving to TCP-AO is KMP's Uma> traffic key (CHILD_SA key) to generate multiple traffic keys to Uma> protect multiple sessions between same peers. Right. In our model, we give BGP one key between two peers. In your model, BGP somehow needs to communicate the source port to the KMP before the session is opened. It means the KMP has to understand several concepts it doesn't need to understand in our model. In your model the KMP needs to understand the concept of ports, the concept of different transport protocols and their interactions. We don't avoid understanding the concept of routing protocols because that's where access control decisions are made. It would also be very easy to expose details like the per-TCP-AO session state in the configuration in a manner that made the KMP far harder to configure or use. Note that the requirement that the routing protocol tell the KMP the source port significantly complicates the interlocking between the routing protocol and KMP. port Uma> If we think more, the reason for KDF and key derivation in Uma> TCP-AO is for inter-session replay protection and this Is Uma> extremely relevant to manual keys but not keys generated with Uma> re-key capable KMP. Uma> But, I recognize today TCP-AO can't consume direct traffic keys Uma> from KMP, but this can be changed if one see there is value in Uma> it. I will pause here and would listen on what do you think. I think there are several disadvantages. First, changing TCP-AO is expensive from a specification and implementation standpoint. Secondly, there is no advantage in doing so. Even if we find it valuable to do per-session SAs, we can still do the TCP-AO key derivation. The performance is not significant and comes at a non-critical time (session setup not per-packet). Adding direct traffic key support to TCP-AO adds a less secure mode, complicates the security analysis and complicates the protocol. Without significant advantages, I do not support it. I also find that the advantages stated so far for per-session SAs do not justify the complexity in my mind. From mjethanandani@gmail.com Mon Sep 26 12:39:37 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 91A0321F8C8A for ; Mon, 26 Sep 2011 12:39:37 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3ETbg5VVd32 for ; Mon, 26 Sep 2011 12:39:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63721F8C7E for ; Mon, 26 Sep 2011 12:39:36 -0700 (PDT) Received: by yxt33 with SMTP id 33so5726690yxt.31 for ; Mon, 26 Sep 2011 12:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ntDMS3CTZOXTKg9mnAWLzEumYhoKKpLNgsIl1xdzJpY=; b=plCPUkKAYtnu9D/OL/vzC5l1Qdsp+vjkrmrmvj9rYTJ16INtGnCJHGY+sAdCUpejrL zlBEYAY1R2Yd5PX3WSjJLQfRX44Ge5vLxPqIboNUtZIJ/H027RdjE70kQSaI7LRYDhj9 pAUUUKpcGDjaLPJZuTAXJFvP82IH7kWzMqhHQ= Received: by 10.68.23.232 with SMTP id p8mr31889337pbf.0.1317066140070; Mon, 26 Sep 2011 12:42:20 -0700 (PDT) Received: from [192.168.1.147] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id q10sm76221952pbn.9.2011.09.26.12.42.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 12:42:18 -0700 (PDT) Message-ID: <4E80D59E.8090604@gmail.com> Date: Mon, 26 Sep 2011 12:42:22 -0700 From: Mahesh Jethanandani User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: karp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 26 Sep 2011 19:39:37 -0000 I would submit that even if BGP and LDP are two different protocols, why would they need two different KMP keys? It is the level of security that is being negotiated between the two peers, which has no relationship (necessarily) to what will be carried in the payload. On 9/26/2011 12:25 PM, Sam Hartman wrote: > To show that this is an advantage, you need to show why one BGP session > between two peers wants algorithm A and another wants algorithm B. (Or > similar for another protocol). We already agree that BGP and LDP are > different protocols and thus need different KMP keys. From manav.bhatia@alcatel-lucent.com Mon Sep 26 13:03:54 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCCE11E80F5 for ; Mon, 26 Sep 2011 13:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWuciceFtZts for ; Mon, 26 Sep 2011 13:03:53 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD51F0C86 for ; Mon, 26 Sep 2011 13:03:51 -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 p8QK6Vhg016458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 15:06:33 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8QK6TJi017939 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Sep 2011 01:36:29 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 27 Sep 2011 01:36:29 +0530 From: "Bhatia, Manav (Manav)" To: Russ Housley , Carter Bullard Date: Tue, 27 Sep 2011 01:36:31 +0530 Thread-Topic: [karp] Question fro Security AD review Thread-Index: Acx8bw0G5KNVPkmpQJKBvgO6sE/nhgAGH2Ug Message-ID: <7C362EEF9C7896468B36C9B79200D8350D00528C7D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4E7A05EE.3070902@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350D0052871B@INBANSXCHMBSA1.in.alcatel-lucent.com> <4E7BEB01.9020600@joelhalpern.com> <6FF71FD6-0D02-4E82-8578-940C78C37439@cs.tcd.ie> 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: "karp@ietf.org" Subject: Re: [karp] Question fro Security AD review 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, 26 Sep 2011 20:03:54 -0000 We do refer to RFC 4107 in Sec 3. I can refer to RFC 2196 and RFC 4107 when= discussing cryto keys if that helps. Cheers, Manav > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Russ Housley > Sent: Monday, September 26, 2011 10:39 PM > To: Carter Bullard > Cc: karp@ietf.org > Subject: Re: [karp] Question fro Security AD review >=20 > Carter: >=20 > > I apologize for jumping in late, but there are lots of reasons why=20 > > keys have limited lifetimes and should be changed often (for some=20 > > sites that is measured in geological time, but that is=20 > still often). =20 > > And there are many, many approaches to key management. It=20 > would seem more appropriate to say something like: > >=20 > > "Cryptographic keys should have a limited lifetime and=20 > should be managed > > using an effective management policy (see RFC 2196,=20 > Secton 4.1, Authtentication > > as a guideline)." >=20 > Wouldn't RFC 4107 be a better reference? Or, at least an=20 > additional reference. >=20 > Russ > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From carter@qosient.com Mon Sep 26 13:18:06 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0EF21F8DB4 for ; Mon, 26 Sep 2011 13:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egga-bX6FOm2 for ; Mon, 26 Sep 2011 13:18:05 -0700 (PDT) Received: from mx0a-000f2801.pphosted.com (mx0a-000f2801.pphosted.com [67.231.144.139]) by ietfa.amsl.com (Postfix) with ESMTP id 9117D21F8DB2 for ; Mon, 26 Sep 2011 13:17:54 -0700 (PDT) Received: from pps.filterd (m0000510 [127.0.0.1]) by m0000510.ppops.net (8.14.3/8.14.3) with SMTP id p8QKKZSt027973; Mon, 26 Sep 2011 16:20:35 -0400 Received: from et-bwi-3.site.stayonline.net (ip-72-29-194-130.airband.net [72.29.194.130] (may be forged)) by mx0a-000f2801.pphosted.com with ESMTP id 102gfcjkyn-1; Mon, 26 Sep 2011 16:20:35 -0400 Received: from [192.168.14.98] ([192.168.14.98]) by et-bwi-3.site.stayonline.net (8.13.8/8.12.6) with ESMTP id p8QKKQIm028830; Mon, 26 Sep 2011 20:20:26 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_7AE9A75D-3F0C-47DB-BEA0-334E1F1E64E1"; protocol="application/pkcs7-signature"; micalg=sha1 From: Carter Bullard In-Reply-To: Date: Mon, 26 Sep 2011 16:20:25 -0400 Message-Id: <884B5E68-1EEA-44CC-B59A-02EBDC5E255E@qosient.com> References: <4E7A05EE.3070902@joelhalpern.com> <7C362EEF9C7896468B36C9B79200D8350D0052871B@INBANSXCHMBSA1.in.alcatel-lucent.com> <4E7BEB01.9020600@joelhalpern.com> <6FF71FD6-0D02-4E82-8578-940C78C37439@cs.tcd.ie> To: Russ Housley X-Mailer: Apple Mail (2.1244.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-09-26_08:2011-09-26, 2011-09-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1109260239 Cc: karp@ietf.org Subject: Re: [karp] Question fro Security AD review 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, 26 Sep 2011 20:18:06 -0000 --Apple-Mail=_7AE9A75D-3F0C-47DB-BEA0-334E1F1E64E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hey Russ, My principal interest was to have a reference for policy regarding key = replacement. But I am always for as many references as relevant. Carter On Sep 26, 2011, at 1:09 PM, Russ Housley wrote: > Carter: >=20 >> I apologize for jumping in late, but there are lots of reasons why = keys have limited lifetimes >> and should be changed often (for some sites that is measured in = geological time, but that >> is still often). And there are many, many approaches to key = management. It would seem >> more appropriate to say something like: >>=20 >> "Cryptographic keys should have a limited lifetime and should be = managed >> using an effective management policy (see RFC 2196, Secton 4.1, = Authtentication >> as a guideline)." >=20 > Wouldn't RFC 4107 be a better reference? Or, at least an additional = reference. >=20 > Russ --Apple-Mail=_7AE9A75D-3F0C-47DB-BEA0-334E1F1E64E1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2 uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDkyNjIwMjAyNlowIwYJKoZIhvcNAQkE MRYEFHNQIi5oSp0zOu1bPlznZKYAfkhsMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB AAk0d451BjqCC6TiVxU5wJuQw6U+gj+4INNDtwoxFAnQgqF/ZsbK/QBWecBOXMUIuGJH/qIYgURT FduCp6q4Zlnrt252t+KTOdK1Yj+ScCpzqIBmcQcEco0ybJQeY0Z83TZPylFo4al4NtognQv4/9PH BbO6+LXw1Uvv77pRCMlx8qBgTbkWDCVVulJGq2ycUT3Tfpc6vsHPaRrOMPGpEFB0y54Q2UZA1tZv 4MhBv8eCkoE3x8MkFScRYzK8ZlN8C8f09adduD9PcDnUyVo6vHQYOrHPpCVc15ezJwM1JKoMEGOB BDtal+mrs7ztxERwOAN0RciqumZLyCIO7OGbfiEAAAAAAAA= --Apple-Mail=_7AE9A75D-3F0C-47DB-BEA0-334E1F1E64E1-- From uma.chunduri@ericsson.com Mon Sep 26 14:03: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 8166221F8DC8 for ; Mon, 26 Sep 2011 14:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3jpruuA8Hlf for ; Mon, 26 Sep 2011 14:03:01 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C718C21F8DC7 for ; Mon, 26 Sep 2011 14:03:01 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p8QL5des000606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Sep 2011 16:05:45 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 26 Sep 2011 17:05:42 -0400 From: Uma Chunduri To: Sam Hartman Date: Mon, 26 Sep 2011 17:05:40 -0400 Thread-Topic: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: Acx8gi4xoYDIzg/CSCi3s2QbLEccggACBGEQ Message-ID: References: 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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 26 Sep 2011 21:03:02 -0000 To show that this is an advantage, you need to show why one BGP session bet= ween two peers wants algorithm A and another wants algorithm B. (Or similar= for another protocol). We already agree that BGP and LDP are different pro= tocols and thus need different KMP keys. It seems fairly unlikely to me that different sessions between two BGP peer= s need different algorithms. [Uma]: Why do you need to differentiate the application (routing) protocol = between the same peers to authenticate the peer? I believe, you don't need to differentiate the routing protocol between th= e same peers. At the end of the day it's the TCP who=20 is carrying the data and protocol for KMP purpose is TCP (infact, you can h= ide all protocols this way i.e., BGP, LDP, MSDP etc..).=20 Then the selection of SA purely depends on the port. And each SA correspond= ing to a session MAY have different lifetimes and=20 algos negotiated. Right. In our model, we give BGP one key between two peers. In your model= , BGP somehow needs to communicate the source port to the KMP before the se= ssion is opened. It means the KMP has to understand several concepts it doe= sn't need to understand in our model. In your model the KMP needs to unders= tand the concept of ports, the concept of different transport protocols and= their interactions. We don't avoid understanding the concept of routing pr= otocols because that's where access control decisions are made. [Uma] KMP is supposed to understand the selectors, algos lifetimes configur= ed to help negotiate the right set of parameters agreeable to both ends. This is precisely the point of CHILD_SA exchange (which is being used= to give the key to RP).=20 It would also be very easy to expose details like the per-TCP-AO session st= ate in the configuration in a manner that made the KMP far harder to config= ure or use. Note that the requirement that the routing protocol tell the KMP the source= port significantly complicates the interlocking between the routing protoc= ol and KMP. [Uma] We are slightly going on a different topic here. But nevertheless th= is is related and extremely important: Some body has to trigger KMP to get the keys at the time of re-key or at th= e time of application restart to get new set of keys. I didn't understand h= ow can you *completely* avoid the trigger. When you trigger - give the parameters to KMP. I think there are several disadvantages. First, changing TCP-AO is expensive from a specification and implementation= standpoint.Secondly, there is no advantage in doing so.=20 Even if we find it valuable to do per-session SAs, we can still do the TCP= -AO key derivation. The performance is not significant and=20 comes at a non-critical time (session setup not per-packet). [Uma] Yes, KDF doesn't cause performance problem but that is not the point.= The only disadvantage I hear is, changing TCP-AO. There is a simple way fo= r this and we briefly discussed this with Brian Weis, Kayur and one of the TCP-AO authors Ron Bonica at last IETF. =20 Adding direct traffic key support to TCP-AO adds a less secure mode, compli= cates the security analysis and complicates the protocol. Without significa= nt advantages, I do not support it.I also find that the advantages stated s= o far for per-session SAs do not justify the complexity in my mind. [Uma] I didn't understand how it complicates the security analysis/protocol= .=20 Let me re-iterate the advantages of populating the KMP session keys = directly in TCP-AO: Non-Security: - Granular session specific parakeets including session life-time= and optimally algo (which is not needed for multi session BGP) - Easy integration with KMP (which we both disagreed) - This can eliminate the operational issue(may not be issue for R= Ps and I didn't mention this earlier) Session specific selectors are part of the traffic key generati= on through KDF, which can cause NAT issues. (there is a draft and this being worked differently out at this= moment)=20 Security: - Any key compromise is limited to that particular session - You can satisfy all KMP requirements for the traffic key ingred= ients=20 (again will stop here and can elaborate more if this is require= d) So, I strongly believe this is to be designed right at first time consideri= ng all the facts and probably as KMP draft is being published, this is the = right time. =20 =20 =20 =20 From kent@bbn.com Mon Sep 26 20:43:53 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 E327521F8BEE for ; Mon, 26 Sep 2011 20:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.064 X-Spam-Level: X-Spam-Status: No, score=-106.064 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGd+MJJWyn2F for ; Mon, 26 Sep 2011 20:43:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 61A4521F8BBA for ; Mon, 26 Sep 2011 20:43:53 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:54132 helo=[10.5.7.5]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R8Ocu-000Isd-Uu; Mon, 26 Sep 2011 23:46:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D005289E6@INBANSXCHMBSA1.in.alcatel-luce nt.com> References: <7C362EEF9C7896468B36C9B79200D8350D005289E6@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Mon, 26 Sep 2011 10:06:24 -0400 To: "Bhatia, Manav (Manav)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: karp@ietf.org Subject: Re: [karp] FW: Stephen Farrell's Discuss on draft-ietf-karp-design-guide-04: (with DISCUSS and COMMENT) 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, 27 Sep 2011 03:43:54 -0000 > >NEW >Most importantly it provides fresh traffic keying material for each >session, thus helping to prevent inter-connection replay attacks. >Any fixed keystream output, generated from the same key and index >should only be used to encrypt once. Re-using such keystream >(jokingly called a 'two-time pad' system by cryptographers), can >seriously compromise security. The NSA's VENONA project [VENONA] >provides a historical example of such a compromise. Usually routing >protocols dont require encryption, however, if they do then using a >KMP avoids the two-time pad problem since packets from different >sessions are encrypted using distinct IVs, or, with distinct session >keys or both distinct IVs and session keys. This text is better. But, since we have no established requirement for encryption for these protocols, it's also needlessly chatty, with about 90% of the text focusing on an encryption-based rationale. I suggest deleting everything after the first sentence. Steve From manav.bhatia@alcatel-lucent.com Mon Sep 26 21:13:14 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 BE6CD21F8E40 for ; Mon, 26 Sep 2011 21:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z96crg9jeBep for ; Mon, 26 Sep 2011 21:13:14 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4276E21F8E3F for ; Mon, 26 Sep 2011 21:13:13 -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 p8R4FoPQ002942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 23:15:52 -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 p8R4Fk6i003750 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Sep 2011 09:45:46 +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.137.0; Tue, 27 Sep 2011 09:45:46 +0530 Message-ID: <4E814D9F.1090504@alcatel-lucent.com> Date: Tue, 27 Sep 2011 09:44:23 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 ThunderBrowse/3.8 MIME-Version: 1.0 To: Stephen Kent References: <7C362EEF9C7896468B36C9B79200D8350D005289E6@INBANSXCHMBSA1.in.alcatel-luce nt.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] FW: Stephen Farrell's Discuss on draft-ietf-karp-design-guide-04: (with DISCUSS and COMMENT) 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, 27 Sep 2011 04:13:14 -0000 .. and this is precisely what i have done in the -05 version! Cheers, Manav On 9/26/2011 7:36 PM, Stephen Kent wrote: >> >> NEW >> Most importantly it provides fresh traffic keying material for each >> session, thus helping to prevent inter-connection replay attacks. >> Any fixed keystream output, generated from the same key and index >> should only be used to encrypt once. Re-using such keystream >> (jokingly called a 'two-time pad' system by cryptographers), can >> seriously compromise security. The NSA's VENONA project [VENONA] >> provides a historical example of such a compromise. Usually routing >> protocols dont require encryption, however, if they do then using a >> KMP avoids the two-time pad problem since packets from different >> sessions are encrypted using distinct IVs, or, with distinct session >> keys or both distinct IVs and session keys. > > This text is better. But, since we have no established requirement > for encryption for these protocols, it's also needlessly chatty, with > about > 90% of the text focusing on an encryption-based rationale. I suggest deleting > everything after the first sentence. > > Steve From hartmans@mit.edu Tue Sep 27 08:06:24 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 6C4DD21F8E4E for ; Tue, 27 Sep 2011 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.359 X-Spam-Level: X-Spam-Status: No, score=-103.359 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599, FUZZY_VLIUM=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnxf+BYTJX6t for ; Tue, 27 Sep 2011 08:06:23 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A7A6321F8E4A for ; Tue, 27 Sep 2011 08:06:23 -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 D3C352014E; Tue, 27 Sep 2011 11:10:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9F8BB4234; Tue, 27 Sep 2011 11:08:37 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: Date: Tue, 27 Sep 2011 11:08:37 -0400 In-Reply-To: (Uma Chunduri's message of "Mon, 26 Sep 2011 17:05:40 -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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 27 Sep 2011 15:06:24 -0000 >>>>> "Uma" == Uma Chunduri writes: > To show that this is an advantage, you need to show why one BGP > session between two peers wants algorithm A and another wants > algorithm B. (Or similar for another protocol). We already > agree that BGP and LDP are different protocols and thus need > different KMP keys. It seems fairly unlikely to me that > different sessions between two BGP peers need different > algorithms. Uma> [Uma]: Why do you need to differentiate the application Uma> (routing) protocol between the same peers to authenticate the Uma> peer? I believe, you don't need to differentiate the routing Uma> protocol between the same peers. At the end of the day it's the Uma> TCP who is carrying the data and protocol for KMP purpose is Uma> TCP (infact, you can hide all protocols this way i.e., BGP, Uma> LDP, MSDP etc..). Then the selection of SA purely depends on Uma> the port. And each SA corresponding to a session MAY have Uma> different lifetimes and algos negotiated. We could do that. It would be a bad idea because at the end of the day an operator is trying to configure security for a routing protocol. That means the operator wants to make a configuration decision like "turn on security for BGP with peer x," not "turn on security for PORT y to port 179 on peer x". Knowing that it's BGP simplifies configuration, simplifies monitoring and simplifies debugging. The operator wants to make access control decisions in terms of BGP. The operator may very sensibly want to do things like use the same configuration to define a peer as to permit a security association with a peer. All that is easier if we think of this in terms of BGP rather than some TCP port. As you have pointed out several times, we can negotiate different lifetimes and algorithms for two distinct sessions beetween the same peers for the same protocol if we think of things in terms of TCP ports. I agree. However I'm still not seeing that as an advantage. Why would an operator want to do so? > Right. In our model, we give BGP one key between two peers. > In your model, BGP somehow needs to communicate the source port > to the KMP before the session is opened. It means the KMP has > to understand several concepts it doesn't need to understand in > our model. In your model the KMP needs to understand the > concept of ports, the concept of different transport protocols > and their interactions. We don't avoid understanding the > concept of routing protocols because that's where access > control decisions are made. Uma> [Uma] KMP is supposed to understand the selectors, algos Uma> lifetimes configured to help negotiate the right set of Uma> parameters agreeable to both ends. This is precisely the point Uma> of CHILD_SA exchange (which is being used to give the key to Uma> RP). Absolutely truep. However the KMP needs to understand the child SAs exactly to the level of abstraction that we define. That's what we're discussing now. The KMP only needs to understand ports and TCP if we say it does. > It would also be very easy to expose details like the > per-TCP-AO session state in the configuration in a manner that > made the KMP far harder to configure or use. Note that the > requirement that the routing protocol tell the KMP the source > port significantly complicates the interlocking between the > routing protocol and KMP. Uma> [Uma] We are slightly going on a different topic here. But Uma> nevertheless this is related and extremely important: Some body Uma> has to trigger KMP to get the keys at the time of re-key or at Uma> the time of application restart to get new set of keys. I Uma> didn't understand how can you *completely* avoid the trigger. Uma> When you trigger - give the parameters to KMP. It's a lot easier if the trigger can be before connections open and not include ports or other TCP-specific info. Remember that a lot of TCP implementations allocate the source port as part of making a connection. All (or almost all) allow you to override that, but it's significant unnecessary complexity to force routing algorithms to implement their own port allocation strategies. > I think there are several disadvantages. First, changing > TCP-AO is expensive from a specification and implementation > standpoint.Secondly, there is no advantage in doing so. Even > if we find it valuable to do per-session SAs, we can still do > the TCP-AO key derivation. The performance is not significant > and comes at a non-critical time (session setup not > per-packet). Uma> [Uma] Yes, KDF doesn't cause performance problem but that is Uma> not the point. The only disadvantage I hear is, changing Uma> TCP-AO. There is a simple way for this and we briefly discussed Uma> this with Brian Weis, Kayur and one of the TCP-AO authors Ron Uma> Bonica at last IETF. > Adding direct traffic key support to TCP-AO adds a less secure > mode, complicates the security analysis and complicates the > protocol. Without significant advantages, I do not support it.I > also find that the advantages stated so far for per-session SAs > do not justify the complexity in my mind. Uma> [Uma] I didn't understand how it complicates the security Uma> analysis/protocol. Today it's very easy to argue that TCP-AO traffic keys are fresh. With this change, we need to consider two arms of a choice. In the manual choice, we need to examine the existing mechanism. In the direct traffic keys choice, we need to consider the KMP interactions. Uma> So, I strongly believe this is to be designed right at first Uma> time considering all the facts and probably as KMP draft is Uma> being published, this is the right time. Agreed. Having considered the facts so far, I strongly support the existing approach of using protocol IDs for each routing protocol and not changing TCP-AO. If we find there is an operational or security reason to distinguish sessions, we should do that. I do not support direct traffic keys for TCP-AO. From uma.chunduri@ericsson.com Tue Sep 27 12:44:43 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 E6B2121F8FF4 for ; Tue, 27 Sep 2011 12:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHq2O142I3GS for ; Tue, 27 Sep 2011 12:44:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C064621F8FF3 for ; Tue, 27 Sep 2011 12:44:42 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8RJlQTq031621; Tue, 27 Sep 2011 14:47:27 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 27 Sep 2011 15:47:22 -0400 From: Uma Chunduri To: Sam Hartman Date: Tue, 27 Sep 2011 15:47:21 -0400 Thread-Topic: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: Acx9J267Q9BTx44TQR6bHnDS4sgyLwAGkinw Message-ID: References: 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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 27 Sep 2011 19:44:44 -0000 Uma> [Uma]: Why do you need to differentiate the application Uma> (routing) protocol between the same peers to authenticate the Uma> peer? I believe, you don't need to differentiate the routing Uma> protocol between the same peers. At the end of the day it's the Uma> TCP who is carrying the data and protocol for KMP purpose is Uma> TCP (infact, you can hide all protocols this way i.e., BGP, Uma> LDP, MSDP etc..). Then the selection of SA purely depends on Uma> the port. And each SA corresponding to a session MAY have Uma> different lifetimes and algos negotiated. We could do that. It would be a bad idea because at the end of the day an = operator is trying to configure security for a routing protocol. That means the operator wants to make a configuration decision like "turn o= n security for BGP with peer x," not "turn on security for PORT y to port 1= 79 on peer x". Knowing that it's BGP simplifies configuration, simplifies monitoring and s= implifies debugging.The operator wants to make access control decisions in = terms of BGP.=20 The operator may very sensibly want to do things like use the same configur= ation to define a peer as to permit a security association with a peer. All that is easier if we think of this in terms of BGP rather than some TCP= port.As you have pointed out several times, we can negotiate different=20 lifetimes and algorithms for two distinct sessions beetween the same peers = for the same protocol if we think of things in terms of TCP ports. I agree. However I'm still not seeing that as an advantage. Why would an op= erator want to do so? [Uma]:=20 1. Even if you build application (routing) protocol knowledge in IK= Ev2 by introducing protocol ID to distinguish=20 CHILD_SA, the true user of this SA is TCP-AO and it *doesn't* ide= ntify connection with application protocol=20 (just SIP, DIP, source port and Destination port). If you really = want this (why?) then you need to change TCP-AO=20 connection identifier. Application protocol can be identified sim= ply by unique destination port. 2. What you are suggesting is taking away the granularity of the con= nection identification, which is well present in=20 both IKEv2 (Child_SA) and TCP-AO by lumping all connections with = a protocol ID. Life time of keys for a particular=20 connection can always be more aggressive based on the topology of= the connection or operator policy (for SIDR, for XYZ etc..).=20 You don't need to take this away for no reason (I don't agree you= r notion of complexity and hiding parameters here).=20 Infact, taking this away through specification introduces unneces= sary churn and changes to both established protocols. Uma> [Uma] KMP is supposed to understand the selectors, algos Uma> lifetimes configured to help negotiate the right set of Uma> parameters agreeable to both ends. This is precisely the point Uma> of CHILD_SA exchange (which is being used to give the key to Uma> RP). Absolutely truep. However the KMP needs to understand the child SAs exactly= to the level of abstraction that we define. =20 That's what we're discussing now. The KMP only needs to understand ports a= nd TCP if we say it does. [Uma]: Even with one connection between the peers the ability to negotiate = the lifetime of the keys and algorithm is one=20 of the advantage of the CHILD_SA negotiation. If some body deploys K= MP, they expect this flexibility when connecting to=20 100 peers around with different algo and different lifetime requirem= ents. I don't like taking this way for one connection=20 or multiple connections for unexplained complexity. It's a lot easier if the trigger can be before connections open and not inc= lude ports or other TCP-specific info. =20 [Uma]: If you want make the trigger before connection the disadvantage I se= e is all protocols (BGP, LDP, MSDP etc..)=20 change and built-in this interaction with KMP. Which is a *significa= nt* disadvantage. TCP-AO already provides that interface, one has to build on that and= just use the same. With this one can better=20 control which traffic is being protected exactly with connection id= entifies provided by TCP-AO (where SRC port could always be *). Today it's very easy to argue that TCP-AO traffic keys are fresh. With this change, we need to consider two arms of a choice. In the manual c= hoice, we need to examine the existing mechanism. In the direct traffic keys choic= e,=20 we need to consider the KMP interactions. [Uma] If this is the point of worry, then answer is very simple. With a *si= mple* extension=20 to TCP-AO this can be achieved with absolutely 0 changes for existing= manual mechanism. So your worry for current/future manual deployment is non-issue.=20 =20 Having considered the facts so far, I strongly support the existing approach of using protocol IDs for each routing protocol and not changing TCP-AO. If we find there is an operational or security reason to distinguish sessions, we should do that. I do not support direct traffic keys for TCP-AO. =20 =20 [Uma] I don't agree this. As I listed earlier and again below - it has bot= h operational and security reasons. Non-Security: - Granular session specific parameters - Easy integration with KMP (which we both disagreed) - This can eliminate the operational issue. Session specific sele= ctors are part of the=20 traffic key generation through KDF, which can cause NAT issues. Security: - Any key compromise is limited to that particular session - You can satisfy all KMP requirements for the traffic keys (and = it's ingredients). =20 The weired part is you are giving a child_sa generated *traffic key* = to TCP-AO to generate multiple=20 *traffic keys* again by AO to protect the eventual connections.=20 > Adding direct traffic key support to TCP-AO adds a less secure mode,=20 [Uma]: How this can be less secure mode?? =20 From hartmans@mit.edu Tue Sep 27 13:20:18 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 481B121F901B for ; Tue, 27 Sep 2011 13:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.35 X-Spam-Level: X-Spam-Status: No, score=-103.35 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5tVd0HOzC67 for ; Tue, 27 Sep 2011 13:20:17 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7733221F9018 for ; Tue, 27 Sep 2011 13:20:17 -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 469812033C; Tue, 27 Sep 2011 16:24:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D9DC14234; Tue, 27 Sep 2011 16:22:31 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: Date: Tue, 27 Sep 2011 16:22:31 -0400 In-Reply-To: (Uma Chunduri's message of "Tue, 27 Sep 2011 15:47:21 -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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 27 Sep 2011 20:20:18 -0000 I think we've more or less reached the point where we've clearly stated our positions and disagree. This will be a matter for WG consensus either during the process of adopting a proposal or once the WG has adopted a proposal. This is likely to be my last message on the subject unless something really new pops up. >>>>> "Uma" == Uma Chunduri writes: Uma> [Uma]: Even with one connection between the peers the ability Uma> to negotiate the lifetime of the keys and algorithm is one of Uma> the advantage of the CHILD_SA negotiation. If some body deploys Uma> KMP, they expect this flexibility when connecting to 100 peers Uma> around with different algo and different lifetime Uma> requirements. I don't like taking this way for one connection Uma> or multiple connections for unexplained complexity. I absolutely agree that per-peer lifetime and algorithm negotiation is something that a KMP should be able to do. Our proposal has this flexibility. Note that we are not proposing using IKEv2. We are proposing a KMP based on IKEv2 (possibly sharing code in some implementations). So, we are proposing no changes to IKEv2. Also, we are proposing no changes to TCP-AO. TThe interface between TCP-AO and the application is largely undefined. draft-ietf-karp-crypto-tables defines that interface for KARP protocols. Our design is intended to be consistent with the crypto tables. Thanks for an excellent discussion: it has helped me clarify my thinking. From uma.chunduri@ericsson.com Tue Sep 27 15:13: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 32D0A21F904B for ; Tue, 27 Sep 2011 15:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV1vMdYe-BaE for ; Tue, 27 Sep 2011 15:13:38 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A511821F8F8B for ; Tue, 27 Sep 2011 15:13:38 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p8RMGOni012294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Sep 2011 17:16:25 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 27 Sep 2011 18:16:23 -0400 From: Uma Chunduri To: Sam Hartman Date: Tue, 27 Sep 2011 18:16:22 -0400 Thread-Topic: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: Acx9U0VME1hUEYBgSIuqyI1mBafBugAC8WNA Message-ID: References: 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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 27 Sep 2011 22:13:39 -0000 I think we've more or less reached the point where we've clearly stated our= positions and disagree. This will be a matter for WG consensus either dur= ing the process of adopting a proposal or once the WG has adopted a proposa= l. [Uma]: Sure, I agree with this. This is likely to be my last message on the subject unless something really= new pops up. [Uma]: Sure ..we both have only limited time for this. >>>>> "Uma" =3D=3D Uma Chunduri writes: Uma> [Uma]: Even with one connection between the peers the ability Uma> to negotiate the lifetime of the keys and algorithm is one of Uma> the advantage of the CHILD_SA negotiation. If some body deploys Uma> KMP, they expect this flexibility when connecting to 100 peers Uma> around with different algo and different lifetime Uma> requirements. I don't like taking this way for one connection Uma> or multiple connections for unexplained complexity. I absolutely agree that per-peer lifetime and algorithm negotiation is some= thing that a KMP should be able to do. Our proposal has this flexibility. [Uma]: Ok. Again we discussed more from per-connection requirements where w= e didn't converge. I know, IKEv2 based KMP has the flexibility for that too and it all = starts with what keys are used eventually. Also, we are proposing no changes to TCP-AO. TThe interface between TCP-AO = and the application is largely undefined.=20 [Uma]: My point is from KMP perspective, how we should *better* integrate a= nd leverage properties of IKEv2 based KMP with TCP-AO I see minor extension for AO to get there. But it's not fair for me = to talk further on this, with out specifying what those are. Even, If we disagree we will specify what those are exactly and the = benefits. Thanks for an excellent discussion: it has helped me clarify my thinking. [Uma]: Thanks. I echo the same. From russw@riw.us Tue Sep 27 15:26:06 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F093121F907C for ; Tue, 27 Sep 2011 15:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+5Xd6oQcr9m for ; Tue, 27 Sep 2011 15:26:06 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 79C3121F907A for ; Tue, 27 Sep 2011 15:26:06 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:65397 helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R8g8x-0001IB-MR for karp@ietf.org; Tue, 27 Sep 2011 18:28:51 -0400 Message-ID: <4E824E27.2000209@riw.us> Date: Tue, 27 Sep 2011 18:28:55 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: karp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 27 Sep 2011 22:26:07 -0000 > Uma> [Uma]: Why do you need to differentiate the application > Uma> (routing) protocol between the same peers to authenticate the > Uma> peer? I believe, you don't need to differentiate the routing > Uma> protocol between the same peers. At the end of the day it's the > Uma> TCP who is carrying the data and protocol for KMP purpose is > Uma> TCP (infact, you can hide all protocols this way i.e., BGP, > Uma> LDP, MSDP etc..). Then the selection of SA purely depends on > Uma> the port. And each SA corresponding to a session MAY have > Uma> different lifetimes and algos negotiated. > > We could do that. It would be a bad idea because at the end of the day an operator is trying to configure security for a routing protocol. For what it's worth, I will agree with Sam here. At some point in the future you might want to be able to have multiple sessions running between the same pair of peers, and have them authenticated separately. So it's valuable to know which specific protocol is being secured, not just which pair of peers is being secured. Russ From uma.chunduri@ericsson.com Tue Sep 27 15:54:55 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 470DD21F8E1D for ; Tue, 27 Sep 2011 15:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoeYZbHObEMg for ; Tue, 27 Sep 2011 15:54:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B36F221F8E1A for ; Tue, 27 Sep 2011 15:54:54 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8RMvd7C008855; Tue, 27 Sep 2011 17:57:40 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 27 Sep 2011 18:57:36 -0400 From: Uma Chunduri To: Russ White , "karp@ietf.org" Date: Tue, 27 Sep 2011 18:57:34 -0400 Thread-Topic: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: Acx9ZNiQcPazV6DOQgeHZL6H8sz7oAAArdLQ Message-ID: References: <4E824E27.2000209@riw.us> In-Reply-To: <4E824E27.2000209@riw.us> 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 Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 27 Sep 2011 22:54:55 -0000 > Uma> [Uma]: Why do you need to differentiate the application > Uma> (routing) protocol between the same peers to authenticate the > Uma> peer? I believe, you don't need to differentiate the routing > Uma> protocol between the same peers. At the end of the day it's the > Uma> TCP who is carrying the data and protocol for KMP purpose is > Uma> TCP (infact, you can hide all protocols this way i.e., BGP, > Uma> LDP, MSDP etc..). Then the selection of SA purely depends on > Uma> the port. And each SA corresponding to a session MAY have > Uma> different lifetimes and algos negotiated. >=20 > We could do that. It would be a bad idea because at the end of the day a= n operator is trying to configure security for a routing protocol. For what it's worth, I will agree with Sam here. At some point in the futur= e you might want to be able to have multiple sessions running between the s= ame pair of peers, and have them authenticated separately. So it's valuable to know which specific protocol is being secured, not just= which pair of peers is being secured. [Uma]: Authentication and having multiple sessions (for the same protocol o= r different protocol) between the same peers are different things. You will authenticate the peer only *once* and with CHILD_SA you can= create as many re-keyable sessions as you want between the same peers. The= application=20 protocol being secured will and can always be distinguished by desti= nation port (which will be unique for routing protocol E.g.: BGP 179) at bo= th IKEv2 and TCP-AO. In that sense no way which specific protocol is being secured is los= t any where. _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From russw@riw.us Tue Sep 27 16:07:15 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 D49E421F8C91 for ; Tue, 27 Sep 2011 16:07:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT8LzRBlJxXg for ; Tue, 27 Sep 2011 16:07:15 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5EABB21F8C8B for ; Tue, 27 Sep 2011 16:07:15 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:49404 helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R8gmm-00032o-Ld; Tue, 27 Sep 2011 19:10:00 -0400 Message-ID: <4E8257CC.90808@riw.us> Date: Tue, 27 Sep 2011 19:10:04 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Uma Chunduri References: <4E824E27.2000209@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "karp@ietf.org" Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 27 Sep 2011 23:07:15 -0000 > [Uma]: Authentication and having multiple sessions (for the same protocol or different protocol) between the same peers are different things. > You will authenticate the peer only *once* and with CHILD_SA you can create as many re-keyable sessions as you want between the same peers. The application > protocol being secured will and can always be distinguished by destination port (which will be unique for routing protocol E.g.: BGP 179) at both IKEv2 and TCP-AO. > In that sense no way which specific protocol is being secured is lost any where. You're assuming each session represents the same peering at the administrative level --and this might not be true. :-) Russ From uma.chunduri@ericsson.com Tue Sep 27 17:13:18 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 12C1521F8F04 for ; Tue, 27 Sep 2011 17:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymmNoYSGT3uy for ; Tue, 27 Sep 2011 17:13:17 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9154C21F8DFF for ; Tue, 27 Sep 2011 17:13:17 -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 p8S0G1QI018735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Sep 2011 19:16:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 27 Sep 2011 20:16:01 -0400 From: Uma Chunduri To: Russ White Date: Tue, 27 Sep 2011 20:16:00 -0400 Thread-Topic: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: Acx9apoPq6jYiaqpRUSJ6PYGn8HZqgAAC8vA Message-ID: References: <4E824E27.2000209@riw.us> <4E8257CC.90808@riw.us> In-Reply-To: <4E8257CC.90808@riw.us> 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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 28 Sep 2011 00:13:18 -0000 =20 > [Uma]: Authentication and having multiple sessions (for the same protocol= or different protocol) between the same peers are different things. > You will authenticate the peer only *once* and with CHILD_SA you c= an create as many re-keyable sessions as you want between the same peers. T= he application=20 > protocol being secured will and can always be distinguished by des= tination port (which will be unique for routing protocol E.g.: BGP 179) at = both IKEv2 and TCP-AO. > In that sense no way which specific protocol is being secured is l= ost any where. You're assuming each session represents the same peering at the administrat= ive level --and this might not be true. :-) [Uma]: That is even better. We were talking about the obvious case, say bot= h BGP and LDP using the same loopback. If both protocols use different peering at the administrative level = you will end-up authenticating the same guy twice (different DIP), and foll= owed by different CHILD_SA. There also routing protocol ID is not required to distinguish the SA= . Again, your protocol info is inherently being represented by unique desti= nation port. KMP can always see the protocol as TCP. The question is what extra benefit you are getting by introducing th= e routing protocol ID otherwise you would not have? =20 From russw@riw.us Tue Sep 27 19:17:06 2011 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D6721F8BB5 for ; Tue, 27 Sep 2011 19:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7owdiiX0ZSNK for ; Tue, 27 Sep 2011 19:17:06 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 16A3A21F8BB0 for ; Tue, 27 Sep 2011 19:17:06 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:50467 helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R8jkU-0002Fr-Rs; Tue, 27 Sep 2011 22:19:50 -0400 Message-ID: <4E828447.7030009@riw.us> Date: Tue, 27 Sep 2011 22:19:51 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Uma Chunduri References: <4E824E27.2000209@riw.us> <4E8257CC.90808@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "karp@ietf.org" Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 28 Sep 2011 02:17:06 -0000 > [Uma]: That is even better. We were talking about the obvious case, say both BGP and LDP using the same loopback. > If both protocols use different peering at the administrative level you will end-up authenticating the same guy twice (different DIP), and followed by different CHILD_SA. > There also routing protocol ID is not required to distinguish the SA. Again, your protocol info is inherently being represented by unique destination port. > KMP can always see the protocol as TCP. > The question is what extra benefit you are getting by introducing the routing protocol ID otherwise you would not have? You're thinking that a single "box," in terms of a virtual machine, or a single o/s instance, is going to be a single "thing," in terms of identity. The problem is this simply might not be true, even in the short term. Today we already have one hardware interface with many virtual interfaces that expose themselves to the o/s instance, and you have many address families within a single protocol. We need to have the ability to virtualize at this level, as well as at the o/s level. I would argue these identifiers would give you this ability, and it doesn't seem like they cost all that much to add, so... :-) Russ From uma.chunduri@ericsson.com Tue Sep 27 21:25:23 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 6A99211E8086 for ; Tue, 27 Sep 2011 21:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGnihxq0RrQt for ; Tue, 27 Sep 2011 21:25:23 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D743111E8082 for ; Tue, 27 Sep 2011 21:25:22 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p8S4S611026567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Sep 2011 23:28:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 28 Sep 2011 00:28:05 -0400 From: Uma Chunduri To: Russ White Date: Wed, 28 Sep 2011 00:28:00 -0400 Thread-Topic: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: Acx9hR57fn5dmIBoTgSEFbUj01x2PgAEOQMw Message-ID: References: <4E824E27.2000209@riw.us> <4E8257CC.90808@riw.us> <4E828447.7030009@riw.us> In-Reply-To: <4E828447.7030009@riw.us> 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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 28 Sep 2011 04:25:23 -0000 You're thinking that a single "box," in terms of a virtual machine, or a si= ngle o/s instance, is going to be a single "thing," in terms of identity. T= he problem is this simply might not be true, even in the short term. Today = we already have one hardware interface with many virtual interfaces that ex= pose themselves to the o/s instance, and you have many address families wit= hin a single protocol. [Uma]: If you go back and see the discussion started exactly around similar= situation (multi-session BGP with many address families)..=20 We need to have the ability to virtualize at this level, as well as at the = o/s level. I would argue these identifiers would give you this ability, and= it doesn't seem like they cost all that much to add, so... [Uma]: So..?? Which identifiers give you what exact ability to virtualize a= t O/S level and interface level??=20 =20 From russw@riw.us Wed Sep 28 08:15:56 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 E9DA81F0C58 for ; Wed, 28 Sep 2011 08:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iT54dgL2RGEx for ; Wed, 28 Sep 2011 08:15:56 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 68C3A1F0C42 for ; Wed, 28 Sep 2011 08:15:56 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:49682 helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R8vuE-0005DZ-R1; Wed, 28 Sep 2011 11:18:43 -0400 Message-ID: <4E833AD2.4020109@riw.us> Date: Wed, 28 Sep 2011 11:18:42 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Uma Chunduri References: <4E824E27.2000209@riw.us> <4E8257CC.90808@riw.us> <4E828447.7030009@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "karp@ietf.org" Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 28 Sep 2011 15:15:57 -0000 > You're thinking that a single "box," in terms of a virtual machine, or a single o/s instance, is going to be a single "thing," in terms of identity. The problem is this simply might not be true, even in the short term. Today we already have one hardware interface with many virtual interfaces that expose themselves to the o/s instance, and you have many address families within a single protocol. > > [Uma]: If you go back and see the discussion started exactly around similar situation (multi-session BGP with many address families).. > > We need to have the ability to virtualize at this level, as well as at the o/s level. I would argue these identifiers would give you this ability, and it doesn't seem like they cost all that much to add, so... > [Uma]: So..?? Which identifiers give you what exact ability to virtualize at O/S level and interface level?? The identifier would give you the ability to identify which routing process on a particular machine you are pairing with, rather than simply assuming all routing processes are in the same admin domain. Are you saying you don't need any identifiers to identify which routing process you're pairing with? If not, why not? :-) Russ From uma.chunduri@ericsson.com Wed Sep 28 09:27: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 2CEA01F0C6E for ; Wed, 28 Sep 2011 09:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7eGp2gn9q72 for ; Wed, 28 Sep 2011 09:27:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A6FF11F0C69 for ; Wed, 28 Sep 2011 09:27:45 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p8SGUXbY025354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Sep 2011 11:30:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 28 Sep 2011 12:30:33 -0400 From: Uma Chunduri To: Russ White Date: Wed, 28 Sep 2011 12:30:31 -0400 Thread-Topic: [karp] KARP-KMP for pair wise routing protocols (traffic selectors) Thread-Index: Acx98evrjMeZPVgUQSCZ8NWwS5UurQABjI9A Message-ID: References: <4E824E27.2000209@riw.us> <4E8257CC.90808@riw.us> <4E828447.7030009@riw.us> <4E833AD2.4020109@riw.us> In-Reply-To: <4E833AD2.4020109@riw.us> 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] KARP-KMP for pair wise routing protocols (traffic selectors) 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, 28 Sep 2011 16:27:46 -0000 =20 Hello Russ: The identifier would give you the ability to identify which routing process= on a particular machine you are pairing with, [Uma] Ok, let me ask this. How do you identify the machine (virtual/physica= l)?=20 Routing process can be identified by destination port or protocol. Ev= en if you put this redundant information in the KMP=20 (on what is being discussed in here) you don't have this in the ultim= ate user of this SA, which is TCP-AO.. Because - it is=20 just not needed to securely deliver a packet a particular virtual/phys= ical interface/machine. =20 rather than simply assuming all routing processes are in the same admin dom= ain.=20 Uma] No.. I don't think neither me or sam assumed this. Are you saying you don't need any identifiers to identify which routing pro= cess you're pairing with? If not, why not? [Uma] As I said you can identify same thing with multiple identifiers and b= uild more redundant knowledge not only in KMP and TCP-AO etc..=20 Ok, let me summarize this for your opinion: protocol ID introduction and identifying SA alone with that, doesn't give t= he granularity of the underlying connection. As you correctly, mentioned ev= en each AFI/SAFI in the protocol need to be identified separately and that = can be simply achieved by creating a connection with different source port = but not just introducing one protocol ID to identify the whole thing and re= moving the existing source port granularity. This is the main issue we disa= greed upon.=20 If a connection granularity for the same protocol is given talking about pr= otocol ID is completely ancillary and I have absolutely no issue with intro= ducing the same as doesn't harm.