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

Hi Charlie,

I've finally gotten around to the detail of this as we get ready
to shoot out a -05 addressing the mpls review team comments and
your security review. (And thanks to you and the mpls-rt folks
for the good comments.)

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

Yep, some more mpls-clue would help me on the directionality thing
too, but I think Adrian's answers are good. In particular, regardless
of all else, we will definitely not end up allowing the same symmetric
key in both directions as that would permit reflection attacks. The
current version doesn't have that bad properly and I'll make sure that
we don't introduce it. To be complete: I think the LSP ID is different
for both directions and that is an input to the KDF, as are the LSR
IDs whose order will differ. So I don't think we can currently end
up with the same symmetric key used in two directions with the current
draft.

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

Right, we are here assuming that any algorithm negotiation is done
via some management system that is not defined by the basic mechanism,
i.e. not here. I think that's reasonable as that same management system
would be the place where someone decides whether and when to try use OS,
so handling those aspects of algorithm agility at that stage seems
better.

It's probably also worth noting that since the symmetric crypto here
is very likely to have to be in h/w for performance reasons, this is
not quite the same as cases where a s/w update might introduce a new
algorithm nor is it that likely that a single node supports many
algorithms given the fairly severe performance constraints that apply,
i.e. line rates of N x 10G generally.

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

Yep, adding one (mod 16) until no more collision or throwing an
error if all 16 are used already or similar is needed. I've added
that.

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

Sure. For now, I added a RECOMMENDATION to use fresh i & r every time
and a ref to RFC4086. I think the recommendation should stay the same
as we don't ever need to do loads of key agreements in a hurry afaik.

But the phrasing of that may change e.g. if we adopt Curve25519 later
or if CFRG or the TLS WG produce guidance on re-use of DH public values
that's more detailed. (The most common case of such re-use for TLS I
think so I'd expect better guidance on this to come from TLS1.3 or CFRG,
and we should just point at whichever of those is best as we go along.)

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

For our initial MTI, I believe we need to pick the same symmetric
cipher and mode that is already supported by h/w that is used for
MACsec as that exists, meets the performance requirements and is
at least somewhat deployed.

That implies that the overhead is probably only as much as problem
as it already is for MACsec, since we're just changing the layer
that sees that overhead. If one runs this and MACsec there could be
fun though, yes.

In any case, we do note the data expansion so the WG and implementers
will deal with that as we go. I do not think we'd be wise to try to
be innovative here with modes of operation, at least not at first. And
if new modes with better properties do turn out to be needed, that
could be defined later on.

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

Yep, I think we'll need to do some editorial surgery later as we
accumulate new bits and pieces of text. The same is true for the
introductory material in section 2 - given we've now published
RFC7435, a lot of that should probably disappear before we're
done. (But is worth keeping for now probably.)

Thanks again for the review.

Cheers,
Stephen.

PS: Adrian and I are nearly done on a -05 version reflecting all
these reviews.

> 
>> 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
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> 