MashSSL Core Specification 1.1.0 (November 11, 2009)

Table of Contents

Intellectual Property and Licensing

The intellectual property covering MashSSL Core Specification 1.1, and its predecessor versions, is wholly owned by SafeMashups Inc. and the Regents of the University of Texas. A companion specification, MashSSL Core Specification 1.2open, has been made available under the W3C Patent Policy and can be implemented royalty free.

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)

Abstract

The MashSSL Core Specification 1.1.0 is a multi-party Internet trust protocol that allows two entities communicating through a third entity 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 can be run through three or more entities and will usually be implemented at the application level (Layer 7 of the OSI stack). 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 RFC 2119.

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 legally part of the same enterprise.

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

Third Party Issued Certificate. Any certificate that is issued to an entity (e.g. a web server running at an enterprise) by another entity (e.g. a public Certificate Authority) which is legally not a part of the first entity.

Use Cases

This specification covers the use of MashSSL between any entities with any underlying protocol binding. For instance one can use it for server to server to server communication over TCP. The pre-dominant specification of interest however is the web application to browser to web application over HTTP use case. Further, we also describe two legged MashSSL, a degenerate case of MashSSL between two entities which provides a practical optimization.

Type of Certificates

This specification covers both self-issued and third-party-issued digital certificates (see definitions). 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 entities:

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

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.

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 all together to the FITM. Upon receiving the client_hello, the FITM examines the client_hello.scramble.is_scrambled. If the flag indicates that scrambling had been performed, then the FITM has to 'unscramble'  the client_hello.client_hello.random before passing the parameters 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 all together to the FITM. Upon receiving the server_hello, the FITM examines the server_hello.scramble.is_scrambled. If the flag indicates that scrambling had been performed, then the FITM has to 'unscramble'  the server_hello.server_hello.random before passing the parameters 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.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

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

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.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. Note that the FITM cannot manipulate the is_scrambled message without causing protocol failure. 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 FITM can restart that session or create copies of it.   A unique advantage of MashSSL is that this can happen through a different FITM. The scrambling will be different as the scrambling keys will differ for each FITM, 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.

These six parameters comprising the client_hello MUST be sent all together to the FITM. Upon receiving the client_hello, the FITM examines the client_hello.scramble.is_scrambled. If the flag indicates that scrambling had been performed, than the FITM has to 'unscramble'  the client_hello.client_hello.random before passing the parameters 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 FITM. Upon receiving the server_hello, the FITM examines the server_hello.scramble.is_scrambled. If it is set to true, the FITM 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 FITM 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 FITM 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. If it had used scrambling then this also serves to authenticate the FITM to the Server.

Two Legged MashSSL

We observe that MashSSL can also be run directly between a Client and a Server without a FITM (and without scrambling). Two Legged MashSSL serves three purposes:

  • Two web applications who expect to run MashSSL several times during the course of a period through a large number of FITMs, can run two legged MashSSL with the full handshake first, and then choose to only run the abbreviated handshake through FITMs. As the message lengths and computation times are larger for a full handshake this ensures that a full handshake is never (or rarely) run through a user's browser.
  • Provides an alterative to transport level SSL for server to server communications security.
  • Can be used for browser to web-server security as an alternative to SSL. This is an attractive option in certain situation. For instance, when the application only seeks to encrypt certain portions of the application data stream, instead of the entire transport stream.

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

The client_hello.scramble.is_scrambled and server_hello.scramble.is_scrambled messages in the full handshake, and, the client_hello.scramble.is_scrambled and server_hello.finished.scramble.is_scrambled in the abbreviated handshake all have the same structure. The parameter consists of three sub-fields separated by a ‘|’.  Specifically “flag|username|authtype”.

The parameter when sent by the Client/Server is, if required, acted on by the FITM, before the message is passed on to the Server/Client. The first field, flag, MUST have the values “true” or “false” or “request”. If it is set to “true” then the FITM  knows that the Client/Server has scrambled the 28 bytes in the server_hello.server_hello.random. The FITM MUST unscramble this value and restore the original value for the protocol to succeed. If the value is “false”  the FITM does not have to take any action. Finally, this field can also have value “request”, which is an indication to the Client/Server that the Server/Client would like the Client/Server to turn scrambling on for future requests.

The second field, username, is simply a string containing the username. It can have a maximum of 80 characters. There are no restrictions on what is in this field. This field was added to accommodate the kerbweb use case. With this special exception, MashSSL should in general be viewed as a secure "application level transport" for Federation protocols, and is itself "user identity" unaware.

The third field, authtype, again added to deal with the kerbweb use case, specifies a field which can be used to communicate the type of authentication. 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, based on feedback from the Kerberos community.