Message Security Layer (MSL) is an extensible and flexible secure messaging framework that can be used to transport data between two or more communicating entities. Data may also be associated with specific users, and treated as confidential or non-replayable if so desired.

MSL does not attempt to solve any specific use case or communication scenario. Rather it is capable of supporting a wide variety of applications and of leveraging external cryptographic resources. There is no one-size-fits-all implementation or configuration; proper use of MSL requires the application designer to understand their specific security requirements.

Each MSL message is associated with an entity. Cryptographic keys associated with the entity are used to authenticate the entity and integrity protect the message. Data, whether confidential or not, is typically encrypted during transport using cryptographic keys associated with the entity, but non-confidential data may also be transmitted without encryption. Messages are optionally associated with a user by including data that can be used to authenticate the user. Messages are optionally protected against replay through the use of a non-replayable ID synchronized between the communicating entities.

Session key establishment is also supported through the use of key exchange mechanisms. It may be necessary to establish session keys before confidential data can be securely transmitted.

The authentication and key exchange schemes are not explicitly defined and must be provided in order to create a secure deployment of the MSL framework. The general approach by which messages are authenticated and key exchange occurs are documented below in Entity Authentication, User Authentication, and Key Exchange.

No assumptions are made about the security properties, dependencies, or implementation of the authentication or key exchange schemes. Specific entity authentication schemes may or may not provide encryption, integrity protection, or authentication and may provide those properties to different degrees of strength. Specific user authentication schemes may offer different degrees of trust regarding the user’s identity. Specific key exchange schemes may or may not provide perfect forward secrecy, protection against man-in-the-middle attacks, or assurances against key leakage or misuse and may provide those properties to different degrees of strength. The correct combination of authentication and key exchange schemes must be used to satisfy the security requirements of a specific application, and will depend upon the security features and capabilities of the application’s execution environment. Examples of authentication schemes, key exchange schemes, and MSL stack configurations are documented in the Configuration Guide.

MSL-based communication may consist of as little as one message between a sender and receiver, or a potentially infinite number of messages flowing between two entities. It is also possible to establish a long-term secure communication channel between two entities using a pair of request and response messages, after which application data may be sent full-duplex over that channel without requiring further authentication.

The design is informed by the following assumptions.

• Operation in both client-server and peer-to-peer modes (each participant is referred to as an entity).
• Basic cryptographic operations are available.
  • W3C Web Cryptography Working Group
  • W3C Web Crypto Key Discovery
• The MSL stack will need to be implemented in JavaScript as well as other languages.
  • JavaScript presents the lowest-common-denominator when it comes to language and environment restrictions.
  • JavaScript has a restricted integer number space of [-2^53^,2^53^].
• A secure random number generator (RNG).
  • A secure RNG is cryptographically indistinguishable from a true random source.
  • Several RNG or pseudo-RNG (PRNG) implementations have turned out to be insecure so be sure to verify your source.
  • XOR of two RNG or PRNG sources to generate random numbers can result in improved randomness.
• Clocks and time may be unreliable or incorrect.
• The application may be untrusted or easily tampered with (e.g. JavaScript in a web browser).

These are the primary security features that MSL provides.

• Entity authentication.
• User authentication.
• Key exchange/agreement.
• Application data transport with encryption and integrity protection.

The following additional features are also provided.

• Cryptographic binding of application data to entities and users.
• Non-replayable messages when requested.
• Cleartext transport of application data is permitted when requested.
• Compatibility with multiple authentication mechanisms and credential types.

MSL does not provide authorization features. All authorization logic must be performed at the application layer.

These are the high level application features that MSL should provide.

• Allow any service to perform entity and user authentication.
  When certain authentication mechanisms are only supported by a subset of services, dependencies are created, operational overhead increases, and potential user experiences are inhibited.

• Allow authorized services to share credential tokens.
  Once authenticated against one service, entities and users will be authenticated against other authorized services which eliminates any costs of re-authentication.

• Eliminate dependence on underlying protocol concepts.
  Integrating a protocol into its transport protocol forces adoption of the transport protocol concepts and restrictions. Some examples based on HTTP include shared cookie state complicating simultaneous user transactions, HTTP headers being blocked by intermediary software, and HTTP status codes being repurposed as error codes.

• Eliminate the increased network overhead associated with SSL handshakes.
  Establishing an SSL connection requires at least one additional network round trip which is costly. CRL and OCSP revocation checks can further increase network overhead.

• Minimize local state requirements.
  A minimal amount of local state requirements, particularly by servers, allows simultaneous communication with many clients without data storage or synchronization overhead.

• Decouple entity and user authentication and credentials.
  If entity and user authentication and credentials are not decoupled, entity authentication would have to occur more often than necessary to match user authentication. Additionally, authentication policies cannot be independently deployed.

• Provide an application-agnostic transport protocol.
  MSL shall act as a transport protocol and will not preclude the use of any form of application protocol.

• Provide high performance operation.
  MSL shall strive to minimize network overhead and support parallel communication between multiple entities.

• Provide built-in compression.
  MSL shall support application-requested compression of application data to facilitate faster message delivery and decrease bandwidth usage.

• Support bulk messaging.
  MSL shall support a streaming data model allowing processing and validation to occur as data is received.

• Forwards compatibility.
  MSL shall strive to be forwards-compatible whenever possible, by using a type encoding that permits easy addition and removal of data.