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