MashSSL Core Specification 1.2.0open

Table of Contents

Intellectual Property and Licensing

This specification is made available under the W3C Patent Policy and can be implemented without any royalties due to the author or the organizations they represent.

Open Web Foundation Licensing Statement:

As of 11/11/2009, the following persons or entities have made this Specification available under the Open Web Foundation Agreement Version 0.9, which is available at http://www.openwebfoundation.org.
SafeMashups Inc.
You can review the signed copies of the Open Web Foundation Agreement Version 0.9 for this Specification at http://www.safemashups.com/downloads/Open_Web_Foundation_Agreement_ MashSSL_1_2_0_open.pdf, which may also include additional parties to those listed above.
Your use of this Specification may be subject to other third party rights. THIS SPECIFICATION IS PROVIDED “AS IS.” The contributors expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the Specification. The entire risk as to implementing or otherwise using the Specification is assumed by the Specification implementer and user. IN NO EVENT WILL ANY PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS SPECIFICATION OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Version History

Version Date Notes Author(s)
0.0.1 02/28/08 Private XML Spec Ravi Ganesan, Ramakrishna Menon
1.0.0 02/28/09 Initial Public Release Ravi Ganesan, Erhan Kartaltepe and Todd Wolff
1.0.1 03/18/2009 Support for the kerbweb use case Ravi Ganesan, Erhan Kartaltepe and Todd Wolff
1.0.2 03/22/2009 Extended scrambling use cases Ravi Ganesan, Erhan Kartaltepe and Todd Wolff
1.1.0 11/11/2009 Companion to 1.2.0open Ravi Ganesan (ravi AT findravi.com)
1.2.0open 11/11/2009 First open version. Ravi Ganesan (ravi AT findravi.com)

Abstract

The MashSSL Core Specification 1.2.0open allows two web services communicating through a HTTP User Agent to mutually authenticate and exchange a session key. It uses an invention called "friend in the middle" (FITM) to re-purpose the SSL protocol to achieve this goal. While SSL is a two party protocol that is usually deployed at the transport level, MashSSL 1.2.0open (henceforth referred to as MashSSL) is run over HTTP. For more motivation and security analysis of MashSSL, the reader is referred to the accompanying white paper. This document takes the conceptual protocol described in that paper and makes it a concrete specification.

Notations and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

Definitions

Client. The entity initiating the MashSSL connection who is conceptually at one end of the connection. (the term is used to be consistent with SSL terminology; in MashSSL the Client is usually a web application).

Server. The other end of the MashSSL connection (the term is used to be consistent with SSL terminology; in MashSSL the Server is usually a web application).

FITM. The Friend in the Middle is an entity in the middle of a MashSSL connection; typically the entity is a web browser or another web application. The Client and Server exchange SSL messages through the FITM.

Self Signed Certificate. Any certificate which is signed using the private key corresponding to the public key certified in the certificate. e.g. a certificate Alice issues to herself attesting to her own validity.

Private Certificate. A certificate issued to an entity (e.g. a web server running at an enterprise) by another entity (e.g. a Certificate Authority run by the enterprise) which is part of the same legal enterprise.

Self Issued Certificate. Any certificate that is a Private Certificate or a Self Signed Certificate.

HTTP User Agent. An application, such as a web browser, that interface a human user to a web application, such as a web server, where the communication between the user agent and the remote server uses the HTTP protocol.

Use Cases

This specification covers the use of MashSSL between two web applications communicating through a HTTP User Agent. The pre-dominant specification of interest however is the web application to web browser to web application over HTTP use case. Further, we also describe two legged MashSSL, a degenerate case of MashSSL between two web servers which provides a practical optimization.

Type of Certificates

This specification covers self-issued certificates. All references below are to self-issued certificates. It is assumed that the certificates adhere to the X.509 standard.

Overall Flow of Messages

MashSSL is a multi-party protocol; for our purposes here there are three main actors:

  • The Client which initiates the protocol (will typically be a web service).
  • The Friend-in-the-middle (FITM), the legitimate agent who can listen to the messages between the Client and Server as well as modify, delete, and replay messages (typically a browser).
  • The Server which terminates the other end of the connection, (typically another web service).

The Client and Server exchange messages through the FITM.  MashSSL specifies the handshake messages which allow for mutual authentication and key distribution. After the handshake messages, the Client and Server can exchange messages (directly or through the FITM) encrypted with their shared session secret. The format of these messages will be application dependent and beyond the scope of this standard. There are four messages passed between the parties in the MashSSL full handshake:

  • client_hello
  • server_hello
  • client_key_exchange
  • server_finished

The message interaction of the full handshake is shown below:

If at the end of a protocol run, a valid session is established, then, just as in the Secure Sockets Layer (SSL) protocol, the key material that has been exchanged can be reused to create a new session without repeating a lot of the cryptographic overhead. Of note: in MashSSL, the Client and Server can recreate this new session through a different FITM. This can come in useful in situations where the Client and Server cooperate on behalf of a large number of users. In the abbreviated MashSSL handshake the following messages are exchanged:

  • client_hello
  • server_finished
  • client_finished
  • server_done (this is an additional message we introduce)

Note that the set of parameters in similarly titled messages in the full and abbreviated handshake are not necessarily the same.  The message interaction of the abbreviated handshake is shown below.

 

The standard deliberately does not address how the messages are sent between the Client, the FITM, and the Server. Two examples of how such interactions can be implemented without any change to existing browsers or web servers are:

  • The message interactions could happen via HTTP POSTs between the Client and Server through a FITM. JavaScript provided by the Client or the Server to the FITM can handle any unscrambling that is required.
  • One can imagine a situation where there are widgets representing the Client and the Server already at the browser, and the messages are transferred between these widgets and the Client and the Server using XmlHTTPRequests (XHR). 

FITM-to-Client and FITM-to-Server connections MAY be protected by TLS. As we shall see below, however:

  • It is REQUIRED that the Client be able to compare the purported address of the Server it is working with, with the actual address in the Server certificate.
  • It is REQUIRED that the Server be able to compare the purported address of the Client it is working with, with the actual address in the Client certificate. How the “purported address” is discovered is dependent on the transport.

The Full Handshake

The MashSSL protocol begins by the Client sending the FITM the client_hello message. This message consists of six parameters: 

  • client_hello.client_hello.client_version
    • This SHOULD be the highest version number of the protocol the Client supports. This is expressed as two bytes and read as BYTE1.BYTE2.  For this version of the protocol it should read 0.9. Further reference: RFC 5246, Page 40.
  • client_hello.client_hello.gmt_unix_time
    • The current date and time in standard UNIX 32 bit format. Further reference: RFC 5246, Page 38.
  • client_hello.client_hello.random
    • 28 random bytes. Further reference: RFC 5246, Page 38.
  • client_hello.client_hello.session_id
    • This is a variable length value that SHOULD be empty in the full handshake. Further reference: RFC 5246, Page 38.
  • client_hello.client_hello.cipher_suites
    • Is of the form uint8 cipher_suites.  MashSSL will only support a proper subset of the cryptographic suites supported in the TLS 1.2 specification. Not all suites in that specification can be supported with the protocol as designed. At this time the standard only supports cipher-suites that use RSA for authentication and key-exchange.  Further reference: RFC 5246, Page 74.
  • client_hello.scramble.is_scrambled
    • This consists of three sub-fields separated by a ‘|’.  Specifically “flag|username|authtype”.  The description of these fields is specified in Appendix – A.

 These six parameters comprising the client_hello MUST be sent together to the FITM.

Upon receiving the client_hello, the FITM examines the client_hello.scramble.is_scrambled  and handles it as set forth in Appendix-A before passing it on to the Server.

When the Server receives this message, it verifies that the Client is using a supported protocol version and that there is at least one cipher-suite in the list that it can support. It then creates a server_hello message with the following eight parameters:

  • server_hello.server_hello.server_version
    • This SHOULD be the lower of that suggested by the Client and the highest supported by the server. For this version of the protocol it should read 0.9.  Further reference: RFC 5246, Page 42.
  • server_hello.server_hello.gmt_unix_time
    • The current date and time in standard UNIX 32 bit format. Further reference: RFC 5246, Page 38.
  • server_hello.server_hello.random
    • 28 random bytes. Note that the TLS specification says this value MUST be independent of that of the random number received from the Client.  Further reference: RFC 5246, Page 38.
  • server_hello.server_hello.session_id
    • Contains the Server-generated session_id. Unlike in the TLS specification where this can be empty (indicating the Server does not want ability to resume session), we require that the Server MUST return a valid value (which does not imply that the Server will agree to resume sessions).
  • server_hello.server_hello.cipher_suite
    • The specific suite chosen by the Server from the list the Client provides. Further reference: RFC 5246, Page 42.
  • server_hello.certificate.certificate_list
    • The Server’s certificate with the chain up until or including the root. The certificate must make sense in the context of the cipher-suite chosen.  Further reference: RFC 5246, Page 46.
  • server_hello.certificate_request.certificate_authorities
    • Unlike in TLS 1.2, MashSSL requires that this MUST be sent. The format is identical to that in the specification and includes the list of supported signature algorithms and certificate authorities. This must make sense in the context of the cipher-suite chosen. Further reference: RFC 5246, Page 52.
  • server_hello.scramble.is_scrambled
    • This consists of three sub-fields separated by a ‘|’.  Specifically “flag|username|authtype”.  The description of these fields is specified in Appendix – A.

The Server MUST send all eight parameters together to the FITM. Upon receiving the server_hello, the FITM examines the server_hello.scramble.is_scrambled and handles it as specified in Appendix-A before passing it on to the Client.
The Client examines the message and if it can proceed, it first creates the following three parameters:

  • client_key_exchange.session_id
    • Contains the same session_id as sent by the Server.
  • client_key_exchange.scramble.is_scrambled
    • This consists of three sub-fields separated by a ‘|’.  Specifically “flag|username|authtype”.  The description of these fields is specified in Appendix – A.
  • client_key_exchange.certificate.certificate_list
    • The Client’s certificate, with the chain up until or including the root. The certificate must make sense in the context of the cipher-suite chosen.  Further reference: RFC 5246, Page 54
  • client_key_exchange.encrypted_pre_master_secret
    • The Client verifies that the Server certificate chains up to a valid root certificate it trusts a priori.  It then generates 46 random bytes, prepending it with the 2 byte version number. “09” or “0.9” are valid values for this version of the protocol. The Client must use the version number it sent in the client_hello, not what it receives in server_hello. These 46 random bytes are used to compute the pre_master_secret. The resulting 48 byte pre_master_secret MUST be PKCS1-padded using the RSAES-OAEP encryption scheme described in [PKCS1].  The result is encrypted with the RSA public key of the Server (present in the Server’s certificate), to create the encrypted_pre_master_secret. Note that the first two bytes MUST be the length bytes. Further reference:  RFC 5246 Pg. 57.

Each of the parameters above MUST be represented as a key/value pair of the form namei=valuei, delimited by an ampersand. The Client takes the parameters above (from the beginning of the protocol up to this point), orders them alphabetically based on the name of the parameter, and forms the string handshake_messages_up_to_this_point = name1=value1&name2=value2&...&namen=valuen, for n key/value pairs.  The Client then computes the next parameter.

  • client_key_exchange.certificate_verify.signature
    • The Client computes a hash on the string handshake_messages_up_to_this_point and digitally signs it using the RSA private key corresponding to the public key in the certificate in client_key_exchange.certificate.certificate_list. The hash algorithm used is as specified in the chosen cipher-suite. Further reference:  RFC 5246 Pg. 56
  • client_key_exchange.finished.verify_data
    • This value is computed as the first 12 bytes of PRF((master_secret, “client finished”, Hash(handshake_messages_up_to_this_point)). Further reference:  RFC 5246 Pg. 61.

T
The Client then computes the master_secret by using a Pseudo-Random Function (PRF) (see RFC 5246, Pg. 13). The master_secret is the first 48 bytes derived from the output of the PRF taking as input the pre_master_secret, the string literal “master secret”, and the concatenation of the client_hello and server_hello random numbers (that is, master_secret = PRF(pre_master_secret, “master secret”, client_hello.client_hello.random + server_hello.server_hello.random). The Client then updates the handshake_messages_up_to_this_point to include the client_key_exchange.certificate_verify.signature. The Client then computes the next parameter.

  • client_key_exchange.finished.verify_data
    • This value is computed as the first 12 bytes of PRF((master_secret, “client finished”, Hash(handshake_messages_up_to_this_point)). Further reference:  RFC 5246 Pg. 61.

The Client MUST send these five parameters together to the FITM, which forwards them to the Server.  The Server verifies that the Client’s certificate chains up to a root it trusts. It then verifies the signature in the client_key_exchange.certificate_verify.signature using the public key in the Client certificate. If this is successful then the Server has successfully authenticated the Client. Further, if the Server had scrambled the random value in the server_hello message, then a successful verification of the Client signature also means the unscrambling at the FITM was successful, and so the Server has also successfully authenticated the FITM.
If the above signature was verified successfully, the Server uses its own private key to recover the pre_master_secret from the client_key_exchange.encrypted_pre_master_secret.  If either the version_number or the length  of the expected message is incorrect, the Server MUST compute a random 48 byte, set it equal to the pre_master_secret, and proceed with the rest of the protocol. The reader is invited to study the explanation for this action in RFC5246, Pg. 57 and in the papers referenced there.  It provides a valuable lesson on why starting with a proven and fifteen year old specification for this standard is so important and why devising a new cryptographic protocol is fraught with peril.
The Server then computes the master_secret using PRF(pre_master_secret, “master secret”, client_hello.client_hello.random + server_hello.server_hello.random). It then verifies the client_key_exchange.finished.verify_data by re-computing it using the exact same steps the Client followed (the handshake_messages_up_to_this_point must be equal to when the Client computed it). The Server then computes the server_finished message, which has three parameters.

  • server_finished.session_id
    • The session_id used for this run of the protocol.
  • server_finished.scramble.is_scrambled
    • This consists of three sub-fields separated by a ‘|’.  Specifically “flag|username|authtype”.  The description of these fields is specified in Appendix – A.
  • server_finished.finished.verify_data
    • The Server updates the handshake_messages_up_to_this_point to include every parameter except this one, and computes this value as the first 12 bytes of PRF(master_secret, “server  finished”, Hash(handshake_messages_up_to_this_point)). Further reference:  RFC 5246 Pg. 61.

The Server sends the server_finished message to the FITM, which forwards it to the Client.
The Client verifies that this message was computed correctly by re-computing the server_finished.finished.verify_data value. If this verification proceeds correctly, then the Client has authenticated the Server.  Further, if the Client had scrambled the random value in the client_hello message, then a successful verification of this message also means the unscrambling at the FITM was successful, and so the Client has also successfully authenticated the FITM.


At this point, the Client and the Server have mutually authenticated, and they have each authenticated the FITM if they activated scrambling.  The Client and the Server are also aware if the other has authenticated the FITM, which is especially useful if they are not authenticating the FITM themselves. For instance, if the Client is a relying party in a federation protocol (who does not perform any scrambling itself), but wants to know if the Server has authenticated the FITM. The Client and the Server also share the master_secret, a value not known to the FITM.

The Abbreviated Handshake

A Client and Server who have established a session through a MITM can restart that session or create copies of it.   A unique advantage of MashSSL is that this can happen through a different MITM. The scrambling will be different as the scrambling keys will differ for each MITM, but even the scrambling algorithm or whether it is performed at all can differ. The handshake is described below. We only describe in detail the parameters that are different.
The Client starts by sending the client_hello:

  • client_hello.client_hello.client_version
  • client_hello.client_hello.gmt_unix_time
  • client_hello.client_hello.random
  • client_hello.client_hello.session_id
    • This will be the session_id from a previous session.
  • client_hello.client_hello.cipher_suites
    • The list of cipher_suites MUST include the one selected for use in the session being resumed. It is RECOMMENDED it only include the cipher suite selected in the session being resumed.
  • client_hello.scramble.is_scrambled
    • This consists of three sub-fields separated by a ‘|’.  Specifically “flag|username|authtype”.  The description of these fields is specified in Appendix – A.
    • This consists of three sub-fields separated by a ‘|’.  Specifically “flag|username|authtype”.

These six parameters comprising the client_hello MUST be sent together to the MITM.
Upon receiving the client_hello, the MITM examines the client_hello.scramble.is_scrambled. If it is set to true, the MITM unscrambles client_hello.client_hello.random before passing it on to the Server.
The Server decides if it is willing and able to reuse the existing session. If it is not willing, it responds with a server_hello message as in the full handshake, and the Client is expected to continue with a full handshake.  If it is willing to conduct an abbreviated handshake it then creates a  server_hello_finished with the following parameters:

  • server_hello_finished.server_hello.server_version
  • server_hello_finished.server_hello.gmt_unix_time
  • server_hello_finished.server_hello.random
  • server_hello_finished.server_hello.session_id
  • server_hello_finished.server_hello.cipher_suite
    • Must be the same as that used in the original session.
  • server_hello.finished.scramble.is_scrambled
    • This consists of three sub-fields separated by a ‘|’.  Specifically “flag|username|authtype”.  The description of these fields is specified in Appendix – A.
  • server_hello_finished.finished.verify_data
    • The Server updates the handshake_messages_up_to_this_point to include every parameter except this one, and computes this value as the first 12 bytes of PRF(master_secret, “server  finished”, Hash(handshake_messages_up_to_this_point)).

The Server MUST send all seven parameters together to the MITM. Upon receiving the server_hello, the MITM examines the server_hello.scramble.is_scrambled. If it is set to true, the MITM unscrambles server_hello.client_hello.random before passing it on to the Server.
The Client re-computes the server_hello_finished.finished.verify_data value, and if it matches with what the Server sent, then it has successfully authenticated the Server. If it had used scrambling then this also serves to authenticate the MITM to the Client.
The Client then creates the client_finished message consisting of the following two parameters

  • client_finished.session_id
    • Contains the same session_id sent by the Server.
  • client_finished.finished.verify_data
    • The verify_data is computed as the first 12 bytes of PRF(master_secret, “client finished”, Hash(handshake_messages_up_to_this_point)). Further reference:  RFC 5246 Pg. 61.

The Client sends the client_finished to the MITM who forwards it on to the Server. The Server re-computes the client_finished.finished.verify_data value, and if it computes correctly then it has authenticated the Client.

MashSSL Certificates versus SSL Certificates

The protocol as currently defined will work with existing SSL certificates without any changes. We believe however that we need to move towards “application certificates” where certificates are issued to an application URL. So for instance http://www.safemashups.com/mail and http://www.safemashups.com/calendar should require separate certificates.

For now however we do require that any implementation of the MashSSL protocol be able to recognize and handle certificates issued to application URLs and to extract a Fully Qualified Domain Name (FQDN) from them.  However, we do not as yet expect them to be able to differentiate between separate applications that resolve to the same FQDN.

References

RFC5246               T. Dierks and E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, August 2008.
GANE08                R. Ganesan, “MashSSL: Towards Multi-Party Trust in the Internet”, October 2008.

Acknowledgements

The author of this version of the specification would like to thank the co-authors on previous versions Erhan Kartaltepe, Ramakrishna Menon and Todd Wolff. A special thank-you to Slava Kasvan for coining the term "friend in the middle" to describe a "legitimate man in the middle".

Appendix-A

The ten character hex string authtype is interpreted as follows:

  • The first and second hex characters determine the sort of authentication, for example password, tokens, etc.
  • The third and fourth hex characters determine any underlying authentication protocol that was used to establish authentication. For example Kerberos, OpenID, SAML, etc.
  • The fifth and sixth hex characters determine the level of verification of the user before the credential was issued.
  • The seventh is either set to ‘0000’ or ‘1111’. If it is set to ‘0000’ that implies that the scrambling was performed right after authentication, i.e. the authentication is fresh. If it is set to ‘1111’ it implies the scrambling is being performed based on a prior authentication, e.g. by using ‘virtual scrambling’ (see GANE08). If the Client has set the flag to request, then this hex value is interpreted by the Server as an indication of whether the Client desires fresh authentication or not. The Server however does not have to honor the Client’s request, and the Client in turn can decide whether to proceed or not if its request was not satisfied.
  • The last three hex characters are reserved.
This revision of the protocol establishes this framework, with the expectations that the next revision will specify the actual codes.