[mpls] FYI - [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt
Loa Andersson <loa@pi.nu> Tue, 26 May 2015 09:05 UTC
Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5CF1A1F16; Tue, 26 May 2015 02:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Yb-hh2U8e2j; Tue, 26 May 2015 02:05:41 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8C61A1EF2; Tue, 26 May 2015 02:05:40 -0700 (PDT)
Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9C4A3180133E; Tue, 26 May 2015 11:05:38 +0200 (CEST)
Message-ID: <5564375E.9060306@pi.nu>
Date: Tue, 26 May 2015 11:05:34 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "mpls@ietf.org" <mpls@ietf.org>
References: <554CAAE8.9090800@pi.nu> <BAY405-EAS3675C46A1A113881AD230F6DFCD0@phx.gbl>
In-Reply-To: <BAY405-EAS3675C46A1A113881AD230F6DFCD0@phx.gbl>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/lLtiwg8bjdYmb4N0hZylNidK66E>
Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls-chairs@tools.ietf.org, 'secdir' <secdir@ietf.org>, Charlie Kaufman <charliekaufman@outlook.com>
Subject: [mpls] FYI - [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 09:05:44 -0000
Charlie, We normally send this type of reviews to the working group also, so I do that now. Working Group, When we started the MPLS-RT review of draft-farrelll-mpls-opportunistic- encrypt we also asked the sec-dir for an early review of the document. Please find the review from Charlie included. /Loa mpls wg co-chair On 2015-05-26 01:34, Charlie Kaufman wrote: > Loa-- > I hope this is an appropriate distribution list. If not please > forward as necessary. > > All-- > Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a > protocol for doing opportunistic encryption of MPLS connections. It permits > encryption at any of two scopes: between adjacent Label Switching Routers > (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an > LSP. Opportunistic encryption in this case means that there is no mechanism > specified for authenticating the endpoints of the encrypted channel. The two > endpoints do an anonymous Diffie-Hellman exchange and use the resulting key > to encrypt the connection. The protocol is not protected from a > man-in-the-middle attack (though some mechanisms for detecting such an > attack after the fact are suggested and a keying infrastructure could be > added later). > > The encryption aspects of the protocol seem well thought out and > appropriate. The question at hand is whether to adopt this document as a > working group document and it easily meets that bar (at least from a > security standpoint). I have a number of questions about operational aspects > of the protocol (perhaps due to my limited understanding of MPLS) and I have > some suggestions for enhancements that will probably be necessary eventually > and might be easier to make before there is widespread deployment: > > There is an issue that came up in the design of IKEv2 that may be an issue > here as well. I don't know whether MPLS connections are bi-directional or > whether separate connections need to be established in the two directions. > If they are bi-directional, then there are race conditions that can occur if > both ends attempt to initialize a connection simultaneously and there must > be some tie-breaking mechanism to assure that exactly one of the connection > attempts succeeds. If they are uni-directional, and if the connection is > always initialized by the sending end, then this is not a problem (though it > is replaced with the problem that messages of this protocol sent in the > reverse direction cannot be tunneled over the MPLS connection). (This > document seems to imply that MPLS connections can be either uni-directional > or bi-directional, but I don't understand MPLS well enough to have > understood it). Even if the connections are bi-directional, it will make > your life simpler if you use different symmetric keys in the two directions. > This can be done easily by getting two independent keys from the key > expansion process. > > A second issue relates to algorithm negotiation. While the protocol allows > for any of the crypto algorithms to be replaced, and the algorithms are > indicated on the wire, it does not appear to allow for a smooth upgrade > where the two ends are updated independently and everything must continue to > work when only one end has been updated. To accomplish that, there should be > an algorithm negotiation (as takes place in IKE and TLS) where one end > presents a list of algorithms is can support and the other end chooses the > algorithms it prefers. A simpler variation would be for a responder to be > able to reject the algorithms assumed by the initiator and send back a list > of algorithms it will accept. Note: it's possible that MPLS already operates > with the restriction that the two ends of a connection must be consistent > and operations will halt if the two ends are updated non-simultaneously. If > that's true, then adding crypto doesn't make the situation any worse and it > would be acceptable to continue to operate that way. > > A possible problem with Key Identifiers: the Key Identifier is only 4 bits > long, which should be sufficient because at most two keys should be active > at any given time. The Key Identifier, however, is chosen effectively > randomly, which means that one time in 16 it will be the same as the Key > Identifier it is replacing. While the protocol could be modified to do > something special in that last (like adding one to the Key Identifier if it > matches the previous value or redoing the key negotiation in that case), it > would probably be better to get the Key-ID from the key expansion when there > is no previous connection and add one (mod 16) when rekeying. > > There is mention of the possibility of reusing g^i and g^r between > connections. Some crypto purists would object to that, but I wouldn't. If > you want to allow implementations that option, however, you should also > include in the exchange nonce values Ni and Nr that are not reused between > connections rather than depending on unique values for the other parameters > to prevent reuse of keys. > > In section 3.5 (MTU considerations), I suspect you may be underestimating > the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad > bytes to make the encrypted payload size a multiple of 16 bytes. There are > algorithm variants that do not add any padding, but they are somewhat > controversial and difficult to implement in hardware. Further, the total > overhead will be dependent of the crypto algorithm chosen, and the text > should indicate that so that readers don't assume that there is some maximum > number of bytes that can be wired into protocols that run above this. > > I would suggest that most or all of sections 5 and 7 should be moved to > Security Considerations. Failing that, the Security Considerations section > should reference them. > > Typos: > > P4: "and if may be advisable" -> "and it may be advisable" > P4: "an alternative key derivation functions" -> "alternative key derivation > functions" > P5: "key definition function" -> "key derivation function" > P5: "attck vecotrs" -> "attack vectors" > P5: "descirption" -> "description" > P19: "opostie" -> "opposite" > > > > > --Charlie > > -----Original Message----- > From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, May 08, 2015 5:24 AM > To: secdir; draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt > > Security Directorate, > > Apologies if I'm sending this too wide! > > The MPLS wg has a review team. The task of the review team is to support the > wg chair, in particular when we are considering a wg adoption poll. > > Before starting a wg adoption poll we run all documents through the MPLS-RT > review (you can find a typical invite to such a review below). > > Just now we have draft-farrelll-mpls-opportunistic-encrypt in MPLS-RT > review. We have enough reviewers accepting to do the review, but all of them > have flagged that they are not entirely comfortable reviwing the document > from a security perspective. Stephen have very graciously offered to help if > there are question. > > I still would like to ask if it possible to find an expert reviewer in the > security directorate. Questions asked are the same as you find in the invite > below. > > Please contact me if you are willing to review the document for us. > > /Loa > mpls wg co-chair > > -----------example of mpls-rt review invite ----------------------- > > Dave, Mach, Lizhong and Kamran, > > > You have be selected as MPLS-RT reviewers for > draft-farrelll-mpls-opportunistic-encrypt. > > Note to authors: You have been CC'd on this email so that you can know that > this review is going on. However, please do not review your own document. > > Note to the reviewers: I understand that this document is very much on the > "security side of the house", however I will also reach out to the Sec-Dir > for a more security biased review. > This should not stop you from commenting on security aspects of the draft, > but if you feel like it I'm comfortable with a "normal MPLS-RT review", > responding to questions below. > > Reviews should comment on whether the document is coherent, is it useful > (ie, is it likely to be actually useful in operational networks), and is the > document technically sound? We are interested in knowing whether the > document is ready to be considered for WG adoption (ie, it doesn't have to > be perfect at this point, but should be a good start). > > Reviews should be sent to the document authors, WG co-chairs and WG > secretary, and CC'd to the MPLS WG email list. If necessary, comments may be > sent privately to only the WG chairs. > > If you have technical comments you should try to be explicit about what > *really* need to be resolved before adopting it as a working group document, > and what can wait until the document is a working group document and the > working group has the revision control. > > Are you able to review this draft by May 17, 2015? Please respond in a > timely fashion. > > > Thanks, Loa > (as MPLS WG chair) > > > /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
- [mpls] FYI - [secdir] Early review of draft-farre… Loa Andersson
- Re: [mpls] FYI - [secdir] Early review of draft-f… Adrian Farrel
- Re: [mpls] FYI - [secdir] Early review of draft-f… Stephen Farrell
- Re: [mpls] [secdir] FYI - Early review of draft-f… Stephen Farrell