Re: [mpls] FYI - [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 29 May 2015 21:03 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 3E0211B2D63; Fri, 29 May 2015 14:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 GqNt4TI6ZdIv; Fri, 29 May 2015 14:03:01 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C138A1B2D5C; Fri, 29 May 2015 14:03:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8C37CBF19; Fri, 29 May 2015 22:02:59 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCAEZhbZ1rgD; Fri, 29 May 2015 22:02:57 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 54AEBBF03; Fri, 29 May 2015 22:02:57 +0100 (IST)
Message-ID: <5568D401.3040004@cs.tcd.ie>
Date: Fri, 29 May 2015 22:02:57 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, 'Charlie Kaufman' <charliekaufman@outlook.com>
References: <554CAAE8.9090800@pi.nu> <BAY405-EAS3675C46A1A113881AD230F6DFCD0@phx.gbl> <5564375E.9060306@pi.nu> <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk>
In-Reply-To: <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/vJfU1ULkrcq6nB7cwzgnJ8wsYRw>
Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls@ietf.org, mpls-chairs@tools.ietf.org, 'secdir' <secdir@ietf.org>
Subject: Re: [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: Fri, 29 May 2015 21:03:03 -0000
Hiya, On 29/05/15 19:57, Adrian Farrel wrote: > Charlie, > > Thanks for this. Forgive me for stumbling through the security aspects: I'm sure > Stephen will pick me up on whatever I get wrong. I'll get to this in a day or so, thanks Charlie for the review and Adrian for processing it. S. > >> 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. > > Right. LSPs may be unidirectional or bidirectional. > > Section 4 and particularly 4.3 describe how the return path is selected for the > case of a unidirectional LSP. > > So we have four questions: > > 1. Is the return path secure? > 2. Who initiates the use of OS? > 3. How do we handle race conditions? > 4. Should we have different keys in different directions? > > In fact, the key exchange does not itself need to be secure, but it would be > better if it was. 4.2.1 and 4.4 say how to do this if possible, but notes it > will likely not be possible in the case of OS. So that's Q1. > > In the case of a unidirectional LSP, only the source node (i.e. upstream from > the perspective of data flow) can be the initiator for the key exchange because > the key exchange requires the use of a message flowing on the LSP itself. So, > for Q2 we only have to worry about bidirectional LSPs, and that takes us to Q3. > > But, in fact, a bidirectional LSP is in fact (from the point of view of the > forwarding plane) the association of two unidirectional LSPs. The association > may be so tight (in the control plane or the management plane, and with fate > sharing) that the LSP is referred to as *a* single bidirectional LSP, but that > doesn't change the forwarding plane behavior. And, indeed, in the bidirectional > case, there is no reason to not have encryption in one direction and not in the > other direction (except, of course, that more is better :-). So that means that > each direction of the bidirectional LSP is responsible for initiating its own > OS. > > Hence Q3 is not a problem, and Q4 takes care of itself. > > We should definitely clarify this in the draft (and thank you for making me > describe it here), but I'd like some more discussion with the WG to check I am > right about this. > >> 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. > > I'm so far from being an expert in this matter that I am probably making a fool > of myself (again), but is algorithm replacement actually any different from key > change? That is, the key negotiation protocol negotiates the key and algorithm > to use and so can also negotiate changes in both key and algorithm. > > Section 4.2.3 mentions this, but is exceptionally week. I'll add some text > (assuming what I just wrote is not complete lunacy). > The key ID identifies the key and the algorithm in one field, so being able to > change the key ID was intended to also allow changing the algorithm. > >> 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. > > Yes, I had assumed that if the key ID was reselected then some form of secondary > choice would be made. Not sure that the predictability of simply adding one is > good idea (not that I can think of specific associated risk). > >> 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. > > Ah, hmm, OK. > Stephen? > Help! > >> 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. > > That's helpful. > Stephen, I need you to help with 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. > > Thanks. Since 5 is growing, I've put back pointer from 6. > 7.1 is already referenced from 6.2 and 6.3 > >> 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" > > Good. > > vmt > Adrian > >
- [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