Network Working Group | R. Van Rein |
Internet-Draft | ARPA2.net |
Intended status: Standards Track | September 4, 2015 |
Expires: March 7, 2016 |
Symmetry for Transport Layer Security
draft-vanrein-tls-symmetry-00
TLS connections can be run over various transports, and can in turn carry many application protocols. All current transports and at least some application protocols are capable of running between symmetric end points, in what could be called peer-to-peer mode, but the use of TLS introduces a requirement to always assign a client and server role, thus enforcing asymmetry and complicating symmetric peer-to-peer protocols. This specification defines a TLS Extension to remedy that stringency of TLS.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
TLS secures many application protocols, some of which can be run symmetrically between peers, possibly after discovery through a mechanism such as mDNS. The introduction of TLS as a security layer underneath application protocols enforces the assignment of asymmetric client and server roles, something that not all protocols were designed to negotiate. Examples of application protocols that do not suggest client and server roles for end points include XMPP and SIP in peer-to-peer mode, or some uses of the symmetric MSRP protocol. In addition, there are many non-standard protocols that have been designed to operate symmetrically from the ground up because they are meant for peer-to-peer operation.
TLS can be carried over transports UDP, TCP and SCTP, sometimes in the DTLS variation. It is commonly understood that UDP can be initiated from either or both sides, but it is less well-known that TCP and SCTP may also connect between two active end points; in this situation both end points initiate the connection, and as a result of network communication delays these attempts cross midway. And indeed, this is even a practically possible situation when one or both end points have a known address, for instance as a result of prior exchange of transparent addresses. Furthermore, firewalls and other middle boxes tend to faithfully implement the TCP state diagrams [Figure 6 of [RFC0793]] that enable this connection setup between two active end points. Lacking an obvious active and passive side for at least some transport connections means that this is not always available as a tie-breaker to assign TLS client and TLS server rolese.
The need to authenticate a remote peer may help to decide which side must play the role of client, and which is to be the server. But in situations with mutual authentication using a more-or-less symmetric CipherSuite, this last reason for asymmetric client/server role separation may also be unsuitable.
This specification introduces a TLS Extension that can be used to indicate that the client/server role assignment is open for negotiation as part of the TLS handshake. This is helpful for those situations where these roles cannot be derived from the context, as described above. It can also be used by a TLS server that wants to actively initiate a connection to a TLS client, and even by a TLS end point that wants to open a hole in its local firewall.
The protocol flow then allows both end points to send a ClientHello containing the new TLS Extension, and based on a tie-breaker value in that extension each party reaches the same conclusion on which TLS end point continues as a client, and which continues as a server. The following figure demonstrates how the resulting TLS flow looks.
ClientHello <-------> ClientHello ServerHello ServerKeyExchange <-------- ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
The role_preference extension carries a byte sequence of at least 1 byte and at most 32 bytes in its extension_data field; each of the bytes must have a value of at least 33 and no more than 126; this makes the byte sequences suitable for treatment as case-sensitive ASCII strings; it should however be noted that these strings have no terminating NUL character.
These role_preference values may be compared on a byte-by-byte basis to determine whether one is ordered before another. The first byte value that differs determines which of the strings is ordered before the other; and if one string equals the other but has additional bytes then the shorter is ordered before the longer one. When one role_preference values is exactly the same as another, they are said to be ordered as equals. When one role_preference value is neither ordered before, nor as an equal to another, then the one is said to be ordered after the other.
An easy way to remember these ordering rules is that "client" is ordered before "server"; and this hints at the intention: if one role_preference value is ordered before another, then the party who sent the one value should take on the role of TLS client, whereas the party that sent the other value should take on the role of TLS server. When two role_preference are ordered as equals then the surrounding TLS handshake fails, on grounds of not being able to establish a client/server role distinction, which should be reported through a handshake_failure alert.
This section defines procedures for sending ClientHello and processing the reception of one.
A ClientHello with the role_preference extension may be sent once by each of the peers, as the initiation of a TLS handshake. The order in which the sides send this extension is arbitrary. It is only possible to send a ClientHello with the role_preference as the first record in a TLS handshake, either on a fresh connection or during (secure) renegotiation.
It is considered an error condition when both sides send a ClientHello but not both incorporate the role_preference extension. This situation MUST result in a handshake_error alert, and may be the cause for a new attempt over a new connection. A more conservative approach would be for a TLS end point to wait for a ClientHello from the remote end point and see if the extension is present; this can work if the remote TLS end point is known to be able to act as a client. Context, historic behaviour and the application protocol can all be helpful determine the most useful approach here.
The role_preference value comprising of a single byte valued 33 will never have a value ordered before it; this can be sent to require a client role. The role_preference value comprising of 32 bytes, all valued 126, will never have a value ordered after it; this can be sent to require a server role. When both sides require the same role, a handshake_error alert will be the result.
When a TLS end point is neutral about its role as a client or a server, it can send any value in between, and it should send a random value to achieve a high probabily of being compatible with any remote TLS end point. The probability of running into a random value from the remote that happens to be the same will be negligable for long enough extension values.
Other details in the ClientHello, such as a Server Name Indication and listed CipherSuites, SHALL be representative only of a potential client role; the TLS end point that ends up in the server role will send a ServerHello with new information.
When a ClientHello with the role_preference extension is received and a ClientHello has not been sent yet, then a ClientHello with the role_preference must still be sent. Only TLS implementations or configurations that do not support the role_preference extension would not send this ClientHello.
After a ClientHello with role_preference is both sent and received, their values can be ordered. When the extension value sent is ordered before the extension value received, the local side will continue as a TLS client and the ClientHello sent continues as the ClientHello record for the TLS handshake, whereas the ClientHello received is strikken from the TLS handshake. When the extension value sent is ordered after the extension value received, the local side will continue as a TLS server and the received ClientHello continues as the ClientHello record for the TLS Handshake, whereas the ClientHello sent is strikken from the TLS handshake. When the extension values sent and received are ordered as equals, a handshake_error alert is locally processed as though it had been received over the TLS connection.
When a ClientHello mesage is strikken from the TLS handshake, the following can be said:
When a ClientHello with the role_preference extension has been sent, but the remote TLS end point respondes with a ClientHello without role_preference extension, then a handshake_error alert MUST be raised, as the handshake procedure was not properly adapted to this specification.
When a ClientHello with the role_preference extension has been sent, but the remote TLS end point responds with a ServerHello, it is clear that no ClientHello is to be expected. The conclusion is then that the remote TLS end point does not implement the role_preference extension. In this case, the handshake continues as it would have without the role_preference extension; the TLS end point that sent the ClientHello continues as a client and the TLS end point that responded with a ServerHello continues as a server.
As an exception to the last paragraph, there is the situation where the role_preference was set to require a server role. In this case, a ServerHello response from the remote TLS end point SHOULD be considered an error, and will raise the handshake_error alert. Note that this is actually a new use case, where a server sends a ClientHello and expects the other side to initiate a client connection on its initiative; this is not part of the usual TLS flow, so it does not dismantle any of the normal TLS usage patterns.
When one of the TLS end points has been selected to fulfil the server role, it will send the usual ServerHello. ServerHello messages MUST NOT include the role_preference extension, as this has already been acknowledged in the ClientHello response preceeding the ServerHello.
In fact, the ServerHello and all follow-up messages conform to the existing TLS procedures. Only when renegotiating TLS with a new handshake will the possibility of change of roles come up again.
The role_preference extension MUST NOT be sent by default by a general TLS implementation. Only when it is implemented with the possibility of symmetric peers in mind, or when it is explicitly configured to permit this mode of operation, SHOULD the role_preference extension be sent.
Most current applications of TLS are aware of client and server roles, and will specify their authentication and encryption requirements in those terms. For example, it is often assumed that a client does not offer authentication, but that a server will authenticate to the client. The client thereby becomes the responsible party to detect man-in-the-middle attacks, because the server cannot distinguish an honest client from a rogue one. Note that this protocol flow is asymmetric, and as a result so is its configuration.
When welcoming both client and server roles, the TLS implementation conceals the actual client and server role assignment, and the application using it will be considered as a symmetric peer. This has an impact on the configuration, which must now speak in terms of local and remote configuration, instead of in terms of client and server configuration. Not all CipherSuites are equally suited for this mode of operation, but use cases that require mutual authentication are reasonably well-supported, and are also the most likely for symmetric peer-to-peer applications of TLS.
During renegotiation of the handshake, the roles of client and server may be swapped. This process is asynchronous to the application-level protocol, and MUST NOT be permitted by default, unless it is explicitly configured from code that is aware of the application protocol's assumptions.
TLS implementations that can end up being either a client or a server SHOULD permit separate configuration of the various parameters that are negotiated during the ClientHello, ServerHello handshake. They should permit separate CipherSuite lists for the two roles, for instance, and their use of Server Name Indications and other extensions may also differ between the two roles.
The TLS changes specified here introduce one more message to the TLS handshake. When this message is generated asynchronously, there is no need for an extra roundtrip, as both sides simply start sending it as soon as the connection comes up. Whether this is safe depends in part on the application protocol; symmetric peer-to-peer protocols will often be able to assume support for the extension.
When the extension is negotiated by a side that defaults to the client role, then a side that defaults to the server role would await it and be required to send the additional ClientHello in its response to indicate support for the role_preference extension. If this response lets the sides take on their default roles, then no extra roundtrip is required because the additional ClientHello can be sent together with the ServerHello that immediately follows it. If the response switches sides, then half a roundtrip is added, as the sides switch their roles. The added flexbility of making this switch may be considered sufficiently valuable to invest this half roundtrip time.
The generated random values for the role_preference extension need not be cryptographically secure values; they merely exist as a tie-breaker in the client/role appointment. This can be achieved with a lower quality random number generator, which can be implemented more efficiently than a secure random number generator.
The ClientHello sent by the server provides additional information, such as the CipherSuites acceptable to the server when it ends up in client mode, and extension information such as a Server Name Indication.
This specification introduces more dynamicity to TLS, and that is automatically a concern. The additional flexibility is not advised as a default mode of operation for general TLS implementations, to avoid interfering with the assumptions made by applications about strict client/server behaviour of TLS.
Applications that are aware of their potential to be either a TLS client or a TLS server should be mindful, and select separate configuration settings for each role. It may be helpful to permit configuration to take place in terms of requirements of authenticating the remote end. And, just as any TLS configuration should take the possibility of NULL CipherSuites into account, it should also be aware of the impact of the various CipherSuites on the two roles to be played.
In a symmetric peer-to-peer application, it makes some sense to consider both the client and server role, and setup for each separately. This work is otherwise done separately on each end, but symmetric peer-to-peer protocols tend to connect in both directions and therefore already require both configurations to be defined. This has not changed; what has changed is that the application is not necessarily aware of which applies.
Having said that, most TLS implementations will not conceal the chosen role completely, because many application protocols need to know about it.
A concern that TLS end points must be aware of when permitting changes of role, is that there may sometimes be a reason to renegotiate the handshake, in which case the client has a decisive role, whereas the server can only ask the client. Whether this could be problematic is an application-level decision to be taken into account before enabling the role_preference extension.
It is also worth noting that the renegotiation provides an opportunity for change of the appointment of client and server roles. This may happen in a manner that is asynchronous to the application-layer protocol. This may or may not be a desired effect, which is why it is recommended as an explicit option to configure, defaulting towards the conservative option of not permitting a change of the roles.
This specification defines a TLS extension, to be registered by IANA in the TLS Extensions Registry, ExtensionType Values subregistry. The Extension Name to be used is role_preference.
[RFC0793] | Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981. |
[RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. |