[secdir] FYI - Early review of draft-farrelll-mpls-opportunistic-encrypt

[Loa Andersson <[e-mail]>]

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:[e-mail]] On Behalf Of Loa Andersson
> Sent: Friday, May 08, 2015 5:24 AM
> To: secdir; [e-mail];
> [e-mail]
> 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: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]