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

From: Loa Andersson <[email-masked]>
Date: Fri, 08 May 2015 14:24:08 +0200

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: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Charlie Kaufman <[email-masked]>
Date: Mon, 25 May 2015 16:34:06 -0700

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:[email-masked]] On Behalf Of Loa Andersson
Sent: Friday, May 08, 2015 5:24 AM
To: secdir; [email-masked];
[email-masked]
Subject: [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt

Security Directorate,

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.

/Loa
mpls wg co-chair

-----------example of mpls-rt review invite -----------------------

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.

Thanks, Loa
(as MPLS WG chair)

/Loa
-- 

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 May 2015 11:05:34 +0200

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

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 May 2015 19:57:40 +0100

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.

> This can be done easily by getting two independent keys from the key

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.

> 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

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.

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

> to prevent reuse of keys.

Ah, hmm, OK.
Stephen?
Help!

> number of bytes that can be wired into protocols that run above this.

That's helpful.
Stephen, I need you to help with this.

> Security Considerations. Failing that, the Security Considerations section

Thanks. Since 5 is growing, I've put  back pointer from 6.
7.1 is already referenced from 6.2 and 6.3

> P19: "opostie" -> "opposite"

Good.

vmt
Adrian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 May 2015 22:02:57 +0100

Hiya,

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