MashSSL XG Final Report

Table of Contents

• Introduction
• Use Cases
  • 3-Party MashSSL
  • 2-Party MashSSL
• Design Goals
• Solution Overview
  • SSL Overview
  • MashSSL Overview
    • MashSSL Full Handshake
    • MashSSL Abbreviated Handshake
• Protocol Specification
  • MashSSL Full Handshake
  • MashSSL Abbreviated Handshake
  • Encryption of Data Using MashSSL Keys
• Leveraging Existing SSL Certificate Infrastructures
• Security Considerations
• Future Work
• Acknowledgements
• IPR Statement
  • Certificate Definitions
  • Licensing Commitment
• References
• Appendix: Motivation for MashSSL
  • Examples
  • Generalizing

Introduction

This report describes an open security protocol, MashSSL, which can be used to solve a fundamental Internet security problem:  when two web applications communicate through a potentially un-trusted user they do not have any standard way of mutually authenticating each other and establishing a trusted channel. MashSSL uses the well studied SSL protocol as a starting point.

SSL [RFC5246] is a two-party protocol for mutual authentication and encryption that is typically used at the transport level. When used with mutual authentication, it is proven, trusted, and critically, has a well established and widely deployed trust and key management infrastructure in the form of certificate authorities who issue digital certificates.  However, it cannot be used directly for the problem we posed, which is inherently multi-party, and which needs a solution that runs ‘over’ HTTP, not ‘under’ HTTP.   

MashSSL is a new multi-party protocol that has been expressly designed to inherit, to the extent feasible, the security properties of SSL, and to be able to leverage its trust infrastructure.  It is based on the unique insight [GANE08] that the introduction of a legitimate man in the middle into the SSL protocol (aka Friend in the Middle or FITM) actually results in a powerful new protocol, which can solve the core problem we identified and has a number of other applications.  And, thanks to the work already done on SSL, MashSSL is lightweight with a short specification designed to be implemented in a RESTful fashion.

Use Cases

As described above, MashSSL is a common building-block that can be used in multiple use cases where this problem occurs. In this section we describe the abstract use case and real-world scenarios where MashSSL can be potentially used. For a more detailed motivation for the need for MashSSL please see Appendix – A: The Motivation for MashSSL.

3-Party MashSSL

This specification covers the use of MashSSL between two web applications communicating through a HTTP User Agent, as shown in the Figure-1 below.

Figure-1: 3-Party MashSSL

In the above example, the user is accessing both web applications. However, there is a requirement that the two web applications need to establish trust between them in the context of the user (HTTP User Agent). This trust could be:

• Mutual Authentication - for e.g. Web Application #2 may want to know the identity of the other web application before it displays content to the user.
• Data Encryption – In addition to authentication, there may be an optional requirement for the two web applications to exchange data securely through the user’s browser. For e.g. this could be entitlements data or in some cases it could be application specific data.

The above abstract use-cases can be seen in various real-world scenarios:

• Client side mash-ups: Cross-domain XHR, OpenAJAX
• Server side mash-ups: OAUTH
• Other 3-party protocols – OpenID, proprietary web payment protocols

2-Party MashSSL

The diagram below, Figure-2, describes a use case where two web nodes need to establish trust between them. This looks similar the standard SSL/TLS use case, but with one difference. The trust is established at the application layer and not at the transport layer.

Figure-2: 2-Party MashSSL

Initially, this use case was conceived as a practical optimization between the two web-applications described above. However, this pattern can be used by itself in several application scenarios. For e.g. Mutual authentication between the user’s browser and a web site, at a finer granularity than the domain name. e.g. blog or shared hosting scenarios.

Design Goals

For a single generic protocol to address the problem, we have identified the following design goals or guiding principles:

1. Solve it once:  We believe that we should solve this problem once at the fabric level, and not in a piecemeal fashion for the various situations in which the absence of a fundamental solution manifests as a problem. This is not a cross-domain XHR,  OAuth, OpenID,  etc. problem, it is a fundamental Internet security component that is missing in action!
2. Solve it at the application level: In a sense HTTP has become the new ‘transport’ protocol for the web, and we believe that the protocol must run on top of HTTP.
3. No browser changes:  Any protocol that requires browser changes will be faced with an adoption challenge. Further, in our situation we are dealing with web service to web service security, and requiring changes at the browser does not appear necessary.
4. Do not use user authentication as a proxy for server authentication:  We consider it a poor choice to use the fact that a user can authenticate into a web service as a proxy for actual web service to web service authentication.
5. Minimize new cryptography: Where possible we wish to use protocol constructs that have been well studied in the past. While the security of crypto building blocks cannot provide a guarantee on the security of a composite protocol, it is certainly the case that it is usually better to start with proven primitives.
6. If possible leverage existing trust infrastructures: Perhaps the hardest part of any solution would be to distribute trustworthy credentials to applications. This is a problem of business processes, trust, insurance, indemnity, etc., and it is infinitely preferable to use an existing infrastructure, and existing credentials.
7. Plan for scale: Finally, we believe that the solution should anticipate that in many practical situations the same two web apps will need to repeatedly authenticate each other, but through different users, and it needs to scale well under those circumstances (for instance repeating expensive PKI operations would not be a good idea).

Solution Overview

Our solution, MashSSL, is a multi-party variant of the SSL protocol that is designed to run over HTTP. It adds an important optimization to the SSL Abbreviated Handshake in order to complete that handshake in two steps instead of three steps. To make this document self contained, we first provide a generic description of SSL and then describe MashSSL within that context.

SSL Overview

The SSL protocol [RFC5246] is tried and tested. The cryptography has been extensively analyzed and the community went through a multi-year process of working out the kinks. Further, the trust infrastructure for SSL, namely digital certificates issued by Certificate Authorities (CA) is in place and working today. Organizations know how to obtain, deploy, and manage certificates for their servers.  And there is a concerted effort to further improve standards for issuance of SSL certificates.

Let us examine SSL more closely to understand its elegance. In this paper we are only presenting SSL at a conceptual level; we refer the interested reader to the most recent specification [RFC5246] for more details. The SSL protocol can be thought of as having two phases: a handshake during which authentication and session key exchange happens, followed by the exchange of application data encrypted with the newly agreed upon session key.

The SSL handshake is shown in Figure-3 below. In our example Web App 1 serves as the “SSL Client” (the party that initiates the protocol) and Web App 2 serves as the “SSL Server”.   We will use the words Client and Server to refer to two web applications (not a user at a browser).

Figure-3: SSL Full Handshake

Let us assume that both parties have digital certificates. The process plays out as follows:

• The Client sends the Server a sessionID (which will be null if this is a new session) and a fresh random number it generates, R1. This data is sent in the clear and is visible to any MITM who is present.
• The Server responds with a new random number R2 of its own, its certificate (which contains its public key), and a request for client authentication. This is also sent in the clear.
• The Client then:
• • generates a third random number R3, and encrypts it with the Server’s public key,
  • signs a running hash of all messages exchanged to date using its private key,
  • computes themaster_secret = function(R1,R2,R3), and creates a client.verify message which is a function of the master_secret and some other standard values.
• Upon receiving the above, the Server then:
• • verifies the signature on the running hash (rhash) using the client’s public key, at which point it has authenticated the Client,
  •  decrypts R3 using its private key, and computes the master_secret and verifies that the client.verify message was calculated correctly
  • computes the server.verify message as a function of the master_secret and some other standard values, and sends this message to the Client.
• The Client then verifies that the server.verify message was calculated correctly, and if so, it  has then authenticated the Server.

The two sides have now mutually authenticated, exchanged a session key (the master_secret) and can send each other messages encrypted with the session key.

A key part of the design is that SSL, when used with mutual authentication, eliminates man in the middle attacks. This happens because:

• the server public key, which the Client uses to encrypt R3, is derived from the server certificate received in Step 2, and
• this is the same server certificate which is part of the message chain that is hashed to create the running hash, rhash, which the Client signs.

So a MITM who does not change what it received from the genuine server in Step 2, and simply forwards the genuine server’s certificate on to the Client, cannot retrieve R3. And a MITM who substitutes its own certificate for the real server’s in Step 2 will get a signature on a rhash that will not be the same as the rhash the real server expects to see signed. 

The ability to claim that a mutual authentication and key exchange protocol is MITM safe is possibly one of the most important cryptographic claims that can be made for such protocols, and SSL, when used with mutual authentication, has withstood the test of time in this regard.

Another elegant part of SSL is that it has been designed with a well thought out mechanism for session reuse. This protocol is shown in Figure-4.

Figure-4: SSL Abbreviated Handshake

A Client and Server that have previously carried out the SSL handshake over a particular socket can reuse  those values on a new connection. While the number of steps appears to be the same, the cryptographic processing is significantly reduced. And, this mechanism is not just meant to resume older sessions, it can also be used to start multiple sessions.

In this case the SSL handshake is said to be abbreviated and works as follows:

1. The Client sends a sessionID used in a previous handshake with the Server.
2. The Server decides if it is willing or not to reuse the parameters from the prior session.
3. 1. If it decides not to reuse the parameters it simply responds with the same messages as in the full handshake and both parties can proceed as before.
   2. If it does decide to reuse the parameters it simply responds with the server.verify message (which is a function of the master_secret from the previous message).
4. If the Client is able to successfully verify the server.verify message then at that point it has authenticated the Server. It then sends a client.verify.
5. If the Server is able to successfully verify the client.verify then at that point it has authenticated the Client.
6. The two parties can then exchange data encrypted with the master_secret.

In addition to these well thought out features, SSL also has been tweaked to defend against more esoteric but potentially serious attacks (some which were discovered several years after SSL was widely used). Further, the protocol has well-defined mechanisms for accommodating different types of cryptographic algorithms.

MashSSL Overview

Mash SSL is a multi-party variant of SSL that runs over HTTP.  We largely reuse the SSL messages, which are exchanged between the web services as HTTP name-value pairs.  Similar to SSL, MashSSL supports and defines both the full and abbreviated handshake messages, though we introduce an optimization in the latter which we will describe.  MashSSL runs in two steps, first the web services directly carry out a MashSSL full handshake to establish a shared master-secret.  Once this is done, they can communicate through a user’s browser using the MashSSL abbreviated handshake.   This approach is extremely efficient as after one full handshake which requires PKI operations, the two sites can do a very large number of abbreviated handshakes which are efficient and only require symmetric key operations.  So, for instance, if two web services communicate via users a hundred thousand times a day, they might choose to perform the full handshake once a day and leverage that across the hundred thousand transactions.

MashSSL Full Handshake

The MashSSL handshake closely follows the SSL handshake messages described above. The two web services exchange the handshake messages and at the end of the handshake a common master_secret is established between them. The actual messages are described in the next Section. The figure shows a layered view of the different protocols. Note that the security of MashSSL does not rest on the use of the optional SSL pipe.

Figure-5: MashSSL Full Handshake Layered View

MashSSL Abbreviated Handshake

Once the two web services have established a master-secret, they can run the MashSSL abbreviated handshake through a user’s browser, serving to cryptographically bind all three parties together.

Figure-6: MashSSL Abbreviated Handshake Layered View

As shown in the figure, the SSL abbreviated handshake consists of three sets of messages, Client to Server, Server to Client and Client to Server. While MashSSL can mimic this structure, and in fact the earlier versions of the specification describe MashSSL in this fashion, we have since chosen to propose an optimization, which reduces the number of round trips. Specifically, the first set of Client to Server messages contain all the information needed for the Server to authenticate the Client. The Server then (if the Client requests it) responds with a set of Server to Client messages which completes the handshake. Referring again to the figure, it will quickly become evident that to achieve this, the Client needs to pick the server random number, and in the next Section we describe how this is done. There has been discussion of introducing a very similar optimization into TLS itself and the interested reader is referred to this thread [MLLIST]on the TLS mailing list.

Protocol Specification

As described above, the MashSSL protocol consists of first running the MashSSL Full Handshake directly between the two web services, and then the MashSSL Abbreviated Handshake through the user’s browser. We describe the messages that make up both sets of handshakes below. In order to make analysis and comparison to the SSL protocol simpler we:

• Ensure that we provide a specific reference to RFC 5246 wherever appropriate.
• Use the notation of message.specific_structure.field_name. While MashSSL parameters  have no notion of structures or hierarchy and exist in a flat namespace, we use this convention to make cross referencing the RFC simpler.

MashSSL Full Handshake

The MashSSL protocol begins by the Client sending the Server 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 1.3. 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.extension
• • This parameter does not exist in TLS and can be used by the protocols tunneling through MashSSL to achieve certain goals. For instance the notion of ‘scrambling’ described in the original MashSSL research paper [GANE08] can be implemented by manipulating structures within this extension. Further, the protocols that tunnel through MashSSL can use this extension. A Server can choose to not interpret this parameter, but must include it in calculations of hashes, etc.

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 1.3.  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.
• 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.extension
• • This field does not exist in TLS and can be used by the protocols tunneling through MashSSL to achieve certain goals. For instance the notion of ‘scrambling’ described in the original MashSSL research paper can be implemented by manipulating structures within this extension. Further, the protocols that tunnel through MashSSL can use this extension. A Client can choose to not interpret this parameter, but must include it in calculations of hashes, etc.

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. “13” or “1.3” 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_helloand 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 sends these five parameters together 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. 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 value, 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 theserver_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 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.  At this point, the Client and the Server have mutually authenticated and  share the master_secret. This completes the MashSSL Full Handshake.

MashSSL Abbreviated Handshake

Once a Client and a Server have established a master-secret using the MashSSL Full Handshake, they are now ready to initiate an abbreviated handshake via a user’s browser.  The handshake is described below. We only describe in detail the parameters that are different from the full handshake. The handshake traverses the user’s browser, and this standard does not limit the manner in which this happens (redirects, POSTs, XHR, etc.). Under certain circumstances, logic in the browser may manipulate the bits in ‘extension’ parameter, however all other parameters must be passed as-is.

The Client starts by sending the client_hello to the Server via the user’s browser:

• 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.extension
• client_hello.response_required

• suggest_ server_hello_finished.server_hello.random

• client_hello.finished.verify_data

Upon receiving the client_hello message the Server:

1. Ensures that is has not received this message before (the size of the cache for preventing replays must at least accommodate messages received within the clock slew that is tolerated)
2. Checks if client_hello.client_hello.gmt_unix_time is within five minutes of its own clock. 
3. If so, it recomputes  the suggest_Server_hello_finished.server_hello.random and verifies that it is identical to that sent by the Client.
4. If so, it recomputes the client_hello.finished.verify_data, and if it is correct, then at this point it has successfully authenticated the Client.

If the client_hello.response_required is set to true, then the Server computes its response as follows:

• 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

• server_hello.finished. extension
• server_hello_finished.finished.verify_data

Encryption of Data Using MashSSL Keys

MashSSL currently does not contain the analogue of the TLS record protocol, and hence we do not describe the key calculation for encryption. Applications desiring to create an encrypted record protocol can use the key calculation described in TLS 5246 Page 24.

Leveraging Existing SSL Certificate Infrastructures

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.example.com/mail and http://www.example.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.

We do recommend that if possible, organizations should embed the application URI in the Subject Alternate Name field in the certificate.

Security Considerations

By starting with TLS, MashSSL is able to leverage the existing security infrastructure of SSL certificates. The analysis of the cryptography can also use the analysis of TLS as a starting point. However, it is a different protocol, most notably in its introduction of the optimized abbreviated handshake, and hence it cannot be assumed that it automatically inherits all the security properties of TLS.

To prevent cut and paste attacks the application must ensure cryptographic binding between the MashSSL header in the abbreviated handshake and the body. This is best achieved by encrypting the payload.

Future Work

There are at least three areas of future work to advance the standard:

1. The optimization in the abbreviated handshake makes some of the parameters superfluous. We have retained these for now, but it is clear that the abbreviated handshake can be further simplified.
2. A standard mechanism for generating keys for privacy and integrity based on the MashSSL handshakes, and the equivalent of the SSL record protocol, should be specified to make this standard more self contained.
3. Perhaps the most interesting future work is based on the observation that the MashSSL handshakes we have described could well be run between a browser and a web application, allowing for application level mutual authentication and encryption. 

Acknowledgements

The authors would like to thank Erhan Kartaltepe, Ramakrishna Menon and Todd Wolff who worked on earlier versions of the MashSSL specification and software, and Lynn Terwoerds for a careful review. We are also grateful to all those who have been a part of the SSL community over the years for their hard work that we are able to leverage.

IPR Statement

Certificate Definitions

We define the following types of certificates:

• 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.
• 3rd Party Certificate. A certificate issued to an entity by a 3rd Party.

Licensing Commitment

Any Essential Claims will be licensed for use with Self Issued Certificates in accordance with W3C Royalty-Free Licensing Requirements. Licenses for use with 3rd Party Certificates (e.g., implementations relying on certificates issued by third party commercial CAs) may be provided on reasonable and non-discriminatory terms and conditioned on payment of royalties, fees or other consideration.

References

RFC5246 T. Dierks and E. Rescorla , “The Transport Layer Security (TLS) Protocol Version 1.2”
(http://tools.ietf.org/html/rfc5246)

GANE08  R. Ganesan, “MashSSL: Towards Multi-Party Trust in the Internet”
(http://www.safemashups.com/downloads/MashSSL_Towards_Multi_Party_Trust_in_the_Internet.pdf)

CABFRM “The CA Browser Forum”
(http://www.cabforum.org).

MLLIST “Link to IETF TLS mailing list”
(http://www.ietf.org/mail-archive/web/tls/current/msg05728.html)

Appendix: The Motivation for MashSSL

We first present several motivating examples and then generalize the problem.

Examples

As our first example, let us consider a hypothetical situation where a web service receives a cross domain XHR request which purports to originate from a partner web service.   In our example, illustrated in Figure-7, the web service is willing to provide video content of classic movies to any subscriber of a partner movie site.  The question immediately arises: Is the request coming from a genuine subscriber of the movie site, or is it a content pirate who is substituting ORIGIN tags in the requests?

Figure-7: Site to Site Authentication for Cross Domain XHR

When such a situation manifest in practice, web services often resort to proprietary cryptographic  mechanisms, and requiring signatures on some proprietary tickets. The immediate consequence of such a solution is that there is yet another potentially weak security protocol that has been ginned up to solve a specific problem, and, both sides have another set of keys to manage to solve this particular problem.  Another suggestion for solving the above problem might be to use an identity federation protocol. While that might certainly be apropos for many situations, in this particular example the classic clips site has no interest in user identity, the requirement is simple, it wants to be able to authenticate the origin of the cross domain request without having to trust the intermediary. We note that the W3C Cross Origin Resource Sharing specification is intended to solve the complementary problem of protecting the user from a malicious web service, whereas our focus is to protect the web service from a malicious user.

For our second example we turn to a very common situation, shown in Figure-8, of an eCommerce site implementing payment options on their site. To maximize business the merchant is likely to want to offer multiple options. While every payment option has its own semantics, and it would be unrealistic to imagine a standard covering them all, we do note one commonality in many of these situations (e.g. PayPal, VISA 3D Secure, etc.). Specifically, the user is redirected to a payment site, and then redirected back to the merchant after payment. 

Figure-8: Site to Site Authentication for Payment Buttons

Both web services in this situation have to ensure that a malicious user does not tamper with the information flowing back and forth. Consequently they typically implement some proprietary cryptography and require special credentials. From the stand point of the merchant who implements multiple such options, there is soon a profusion of crypto protocols and a credential management headache.

For our third example we consider identity federation protocols like OpenID [OPENID].  Almost all of these protocols follow the identity ‘dance’ shown in Figure-9, wherein a user is redirected to an identity provider who authenticates the user and then makes assertions about the user. 

Figure-9: The Federation Identity Dance

Central to the security of these protocols is the mutual authentication of the IP and the RP and the establishment of a secure channel, and this is a challenge for these protocols. For instance, in their analysis of the security [OIDSEC] of the OpenID protocol , the authors observe: “browser is de facto MITM….vulnerability to active attacks (session swapping)…association establishment (MITM)”.  Solving these problems requires new crypto and the introduction of yet another credential.

For our final example we turn to the OAuth delegated authorization protocol which, combined with OpenID, is becoming a fundamental piece of the security puzzle for securing mashup APIs. Currently OAuth is used widely in applications such as social networks. However, it is expected that OAuth or similar protocols will be used in mashups of even more sensitive information such as financial or healthcare data is likely to follow. An example is shown in Figure-10.

Figure-10: The OAuth Use Case

When OAuth was first designed, the familiar problem of how the two web services would mutually authenticate and establish a trusted session was encountered. The initial solution was found to suffer from a classic man-in-the-middle session fixation attack, and has subsequently been altered.  The crypto to solve this problem is again proprietary to OAuth and a web service needs an OAuth specific credential.

Generalizing

We have described four situations in which web services communicating through a potentially untrusted user (or browser) have to resort to proprietary crypto and have to issue or obtain and maintain special purpose credentials. This is not a new problem for web services, but is a problem that is growing. We are rapidly transitioning to a world where the end user’s web experience is typically a composite or mashup of several web services. The need for these web services to mutually authenticate and establish a trusted channel is going to arise again and again in many different contexts. Consequently there is a growing need to solve this problem once with a standard protocol that can be reused in any applicable context.

It must be emphasized that our goal is not to replace any of the protocols we described above. Rather, our goal is to provide for a standard way of mutual authentication and establishment of a secure pipe between the two web services, which can then be used by various protocols. Just as SSL is the default underlying security protocol for browser to web server security, we see MashSSL evolving to be the default underlying security protocol for web server to browser to web server communications.