Subject: Re: [Pce] Use of TCP AO and TLS in PCEP

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 06 Feb 2014 08:44:39 +0000

Hi Adrian, Joe,

Thanks for the review. It will really help in putting the draft in a better shape. We are preparing a new version and the replies below will be reflected there.

On 19 Jan 2014, at 17:37 , Adrian Farrel <[email-masked]> wrote:
>>> The PCE WG has http://datatracker.ietf.org/doc/draft-lopez-pce-pceps/ which
>>> is about running PCEP (the PCE protocol, a TCP-using protocol) using TLS and
>>> TCP-AO.
>>>
>>> We could look at the work done in KARP (RFC 6952) but that is hardly
> conclusive.
>>
>> That work was driven largely by that WG's concern with the lack of
>> availability of a TCP-AO implementation in end-system OSes (Linux or
>> FreeBSD). They spent an inordinate amount of time complaining about
>> that, time that could easily have been used to implement the protocol
>> rather than worrying about alternate interim solutions.

In fact, a first set of ideas on this draft was discussed at the KARP meeting in Berlin. The reference to TCP-AO is derived from that discussion, as there seemed to be a general consensus among the group that TCP-AO should be considered. After this input from you and some other discussions I and the other co-authors have had around, we will focus the discussion on the TLS aspects, and mention TCP protection in general and TCP-AO in particular in the "Security Considerations" section. No interaction between TLS and TCP-AO will be mentioned.

>>> 2.1.  TCP ports
>>>
>>>   The default destination port number for PCEPS is TCP/XXXX.
>>>
>>>   NOTE: This port has to be agreed and registered as PCEPS with IANA.
>>
>> PCEP already is assigned to port 4189. RFC5440 already permits PCEP
>> connections to use either TCP MD5 or TCP-AO, but at the time of that
>> document there was no TCP-AO to reference.
>>
>> As a result it should be trivial for a PCEP server to differentiate pcep
>> vs. pceps connections:
>>
>>      MD5 must be pcep, and already don't use TLS
>>
>>      TCP-AO must be pceps, and thus must include TLS
>>
>>      connections using neither MD5 nor TCP-AO must be pceps,
>>      and thus must include TLS
>>
>> I don't see a rationale for needing a separate port.

The rationale is the common practice derived from the TLS layered approach, so a client knows how and when require the server to start a TLS connection, and the server knows in advance what the client is requiring and match it against its policy. The use of TCP protection must be orthogonal to the use of TLS, so it can not be used for the server making a guess of the protocol security encapsulation.

Either we have a protocol-specific mechanism (a-la-STARTTLS) or we use a specific port. The latter implies no changes at all to the protocol, which is included as one of the requirements for secure PCEP exchanges. If adding such a mechanism would be acceptable, we could go for the first option. This is something that should be decided by the WG. I'll update the draft noting this point and highlight it to the WG for discussion.

>>
>>> 2.2.  TLS Connection Establishment
>> ...
>>>   NOTE: We have to consider potential interactions between TLS re-
>>>   negotiation and TCP-AO MKT
>>
>> I don't understand this statement. TLS has nothing to do with TCP-AO;
>> TCP-AO's protection does not modify the application (TLS) view of TCP at
>> all (even if keys change during a connection).
>>
>> There should be no interaction.

Good point. As said above, this will be moved to the Security Considerations section and the TCP-AO deemed out-of-scope, being independent of the TLS usage.

>>
>>> 2.3.  TCP-AO Application
>>>
>>>   PCEPS implementations MAY in addition apply the mechanisms described
>>>   by the TCP Authentication Option (TCP-AO, described in [RFC5925] to
>>>   provide an additional level of protection with respect to attacks
>>>   specifically addressed to forging the TCP connection underpinning
>>>   TLS.  TCP-AO is fully compatible with and deemed as complementary to
>>>   TLS, so its usage is to be considered as a security enhancement
>>>   whenever any of the PCEPS peers require it.'
>>
>> I don't understand the rational for the protection defined by PCEPS vs PCEP.
>>
>> PCEP = *requires* TCP protection (either TCP MD5 or IPsec), but allows
>> privacy to be optional (e.g., when using TCP MD5); regardless of the
>> forward pointer to TCP-AO, there was no specification to cite, thus it
>> cannot be required.
>>
>> PCEPS = *requires* privacy by TLS, but leaves TCP protection as optional.
>>
>> This makes no sense to me. IMO, TCP protection *must* be mandatory, or
>> RFC5440 needs to be updated before PCEPS should proceed.
>>
>>>   Implementations including support for TCP-AO MUST provide mechanisms
>>>   to configure the requirements to use TCP-AO, as well as the
>>>   association of a TCP-AO Master Key Tuple (MKT) with a particular
>>>   peer.
>>
>> The above is a strange way to say "implementations supporting TCP-AO
>> MUST support TCP-AO", which is a tautology that need not be stated.
>>
>>> Whether these mechanisms are provided by the administrative
>>>   interface or rely on the TLS handshake according to procedures
>>>   similar to those described in [RFC5216] and [RFC5705] is outside the
>>>   scope of this document.
>>
>> TLS cannot be used to protect TCP-AO sessions. For a given connection,
>> TCP-AO must be started at connection establishment, which is prior to
>> TLS negotiation.

Agreed. The intertwining of TLS and TCP protection will be eliminated.

>>
>>> 4.  Backward Compatibility
>>>
>>>   Since the procedure described in this document describes a security
>>>   container for the transport of PCEP requests and replies carried on a
>>>   newly allocated TCP port there will be no impact on the base PCEP
>>>   and/or any further extensions.
>>
>> See my comment above; I agree, but not because a new port is needed.

As said above, not using a different port would translate in requiring an additional protocol element, so clients could express their request to start a TLS connection. Going for analyzing a combination of the TCP protection mechanisms would imply the intertwining we are trying to avoid, that translates in the inconsistencies you noted above.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Feb 2014 13:41:53 -0800

Hi, Diego,

Some responses below to some specific points:

On 2/6/2014 12:44 AM, Diego R. Lopez wrote:
> Hi Adrian, Joe,
>
> Thanks for the review. It will really help in putting the draft in a
better shape. We are preparing a new version and the replies below will
be reflected there.
...
> The rationale is the common practice derived from the TLS layered
> approach, so a client knows how and when require the server to start a
> TLS connection, and the server knows in advance what the client is
> requiring and match it against its policy.

That is common when there is no other way to determine whether a 
connection uses TLS or not (and even then is at best a performance 
optimization).

> The use of TCP protection must be orthogonal to the use of TLS, so it
> can not be used for the server making a guess of the protocol
> security encapsulation.

TCP protection isn't orthogonal to TLS for pcep as currently specified; 
see the table above. The only connections that can use TLS would be 
those that do not use TCP MD5 (see the list of cases above).

> Either we have a protocol-specific mechanism (a-la-STARTTLS) or we
> usea specific port.
...

For every connection, you already know the mode before the connection 
starts. If the connection is configured to require TCP MD5, then there 
is no TLS. If not, then there must be TLS.

There are no protocol changes required to make this happen; you just 
need to use the information you already have.

...
> As said above, not using a different port would translate in
> requiring an additional protocol element, so clients could express
> their request to start a TLS connection.

That information isn't needed; you already have to know in advance 
whether you require them to use TCP MD5 or not. That's enough 
information to know whether it's TLS or not too.

Joe

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 11 Feb 2014 14:26:08 +0000

Hi Joe,

Too much travel making my email backlog grow, I'm afraid...

On 6 Feb 2014, at 22:41 , Joe Touch <[email-masked]> wrote:
> That is common when there is no other way to determine whether a connection uses TLS or not (and even then is at best a performance optimization).

I'd say is not only performance, but a security optimization. Unless the server is sure that starting a TLS session is explicitly required by the client, how can a server know whether there has been an intentional downgrade by a man-in-the-middle? Furthermore, the client and server codes become completely independent of what happens at the TCP layer, and I think this is in general a good design practice.

And even if you find counterarguments to the two reasons above, the common practice is the use of either a dedicated port or a dedicated command. And that implies that developers will find plenty of choices to implement this, widely validated and understood by the community. And when it comes to security, this is of great value, mostly when PCEP peer developers will not usually be security experts.

> TCP protection isn't orthogonal to TLS for pcep as currently specified; see the table above. The only connections that can use TLS would be those that do not use TCP MD5 (see the list of cases above).
>
> For every connection, you already know the mode before the connection starts. If the connection is configured to require TCP MD5, then there is no TLS. If not, then there must be TLS.

What I cannot see is why the combination of TCP MD5 with TLS could not happen, or the combination of TCP AO without TLS. We are talking about independent layers, or am I missing something? FWIW, you could use any of them on an IPsec connection as well...

> There are no protocol changes required to make this happen; you just need to use the information you already have.

By not having TCP protection and TLS orthogonal we are mixing security mechanisms at two different layers, and assuming there is some kind of cross-layer exchange that may not necessarily happen because is out of the common practice, and that is a recipe for security holes.

Maybe that the current writing of the PCEPS draft is not clear enough in that respect. We would really appreciate any suggestion in improving it.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Feb 2014 06:52:14 -0800

On 2/11/2014 6:26 AM, Diego R. Lopez wrote:
> I'd say is not only performance, but a security optimization. Unless
> the server is sure that starting a TLS session is explicitly required by
> the client, how can a server know whether there has been an intentional
> downgrade by a man-in-the-middle?

It cannot, but let's look at the case where there are different ports. 
The MITM in that case can rewrite packets to the different port. Same 
problem.

The conclusion is that the server cannot know about the downgrade until 
the connection fails because the MITM can't spoof the server's TLS 
credentials back to the client.

 > Furthermore, the client and server
> codes become completely independent of what happens at the TCP layer,
> and I think this is in general a good design practice.

Ports are a critical global community resource, not a programming 
convenience.

> And even if you find counterarguments to the two reasons above, the
> common practice is the use of either a dedicated port or a dedicated
> command.

We should be aiming for best practice, not common practice.

 > And that implies that developers will find plenty of choices to
> implement this, widely validated and understood by the community. And
> when it comes to security, this is of great value, mostly when PCEP peer
> developers will not usually be security experts.

Agreed, but they need to be protocol experts or they won't get the 
protocols right. If they do get the protocols right, then they can 
trivially determine the type of connection - at connection start - 
simply from the configuration of keys.

>> For every connection, you already know the mode before the
>> connectionstarts. If the connection is configured to require TCP MD5, then there
> What I cannot see is why the combination of TCP MD5 with TLS could
> nothappen,

It isn't specified, therefore you can say that if it happens you can 
cancel the connection attempt.

 > or the combination of TCP AO without TLS.

Same thing.

> We are talking about
> independent layers, or am I missing something? FWIW, you could use any
> of them on an IPsec connection as well...

You could, but they should all fail except the ones that you specify. 
That's a basic tenet of security design.

This is why I concluded that the protocol specifications - existing and 
the one currently under review - are easily distinguished. Ports are 
assigned for current use, not potential future use.

So unless you're proposing to revise the doc to include these other 
cases, they're irrelevant. And if you are, we can then talk about 
whether it's good security design to consider so may alternatives 
without specific use cases in mind.

>> There are no protocol changes required to make this happen; you
>> just  need to use the information you already have.
>
> By not having TCP protection and TLS orthogonal we are mixing
> securitymechanisms at two different layers, and assuming there is some kind of
> cross-layer exchange that may not necessarily happen because is out of
> the common practice, and that is a recipe for security holes.

TCP is - and needs to be - aware of both TCP and TLS protection. It has 
to have all the information needed anyway.

(yes, if we throw in other protocol layers here, that might not be true, 
but again we're talking about what has been proposed, not what might be).

> Maybe that the current writing of the PCEPS draft is not clear
> enough  in that respect. We would really appreciate any suggestion in 
improving it.

If you intend the protections to be orthogonal, you need to say that, 
and you need to justify why all possible combinations are needed. At 
that point I would argue against that set of combinations.

Joe

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 12 Feb 2014 11:06:48 +0000

On 11 Feb 2014, at 15:52 , Joe Touch <[email-masked]> wrote:
> It cannot, but let's look at the case where there are different ports. The MITM in that case can rewrite packets to the different port. Same problem.
>
> The conclusion is that the server cannot know about the downgrade until the connection fails because the MITM can't spoof the server's TLS credentials back to the client.

Granted. But relaying a security decision at one layer of the combination of other unrelated options at another supporting layer seems an unnecessary complication, and that is against good security practice.

> Ports are a critical global community resource, not a programming convenience.

If this the gist of your argument on the additional port issue, I can understand it. And if restricting the allocation of specific ports is a common view within the community we could address the solution based on a specific command.

> We should be aiming for best practice, not common practice.

I am afraid I do not see why intertwinning two layers is a best practice...

> Agreed, but they need to be protocol experts or they won't get the protocols right. If they do get the protocols right, then they can trivially determine the type of connection - at connection start - simply from the configuration of keys.

From information derived from another layer they should not be concerned with. If there were no other feasible choices, I'd go for it. But there are, with wide support and thorough scanning for security flaws.

> You could, but they should all fail except the ones that you specify. That's a basic tenet of security design.
>
> This is why I concluded that the protocol specifications - existing and the one currently under review - are easily distinguished. Ports are assigned for current use, not potential future use.
>
> So unless you're proposing to revise the doc to include these other cases, they're irrelevant. And if you are, we can then talk about whether it's good security design to consider so may alternatives without specific use cases in mind.

The document is revised (in version -01) to say that TCP protection mechanisms and TLS usage are orthogonal, so I don't see the need to consider all or any of the alternatives that arise from their combination

> TCP is - and needs to be - aware of both TCP and TLS protection. It has to have all the information needed anyway.

TCP should be totally oblivious to the fact TLS is used above it, in the same sense that TLS is oblivious to the particular TCP options in use. And the same happens with PCEP with respect to both of them.

> If you intend the protections to be orthogonal, you need to say that, and you need to justify why all possible combinations are needed. At that point I would argue against that set of combinations.

As I said before, in version -01 orthogonality is declared. And since they are declared orthogonal I don't see the need for analyzing the different combinations, for the same reason I don't see the need of discussing about running PCEPS on public or private IP addressing, to give an example.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Feb 2014 07:55:14 -0800

On 2/12/2014 3:06 AM, Diego R. Lopez wrote:
> If this the gist of your argument on the additional port issue, I can
> understand it.

FWIW, it is.

Joe

 > And if restricting the allocation of specific ports is
> a common view within the community we could address the solution
> based on a specific command.