This page looks at core M-Switch Security Features. In addition to this page, security related features are covered on the pages on M-Switch Content checking (anti-virus, anti-spam and reputation services), M-Switch X.400 (X.400 non-military security capabilities), M-Switch X.400 Military messaging (STANAG 4406 security capabilities) and M-Switch Encryption (S/MIME Encryption).

This page presents:

S/MIME

S/MIME (Secure MIME) is a widely used standard (RFC 5751) for providing end to end message digital signature based on X.509 PKI and message encryption.

M-Switch can check S/MIME signatures on message submission, to validate message integrity and origination. These checks are integrated with the authorization system, so messages can be controlled based on signature presence and validity.

When the S/MIME signatures is verified , the results are reported an RFC 7001 Authentication-Results: header according to “Authentication-Results Registration for S/MIME signature verification”.

S/MIME headers may be signed following the S/MIME procedures. When this is done M-Switch marks the S/MIME signed headers following "Considerations for protecting Email header with S/MIME". This enables correct reverse mapping by M-Switch when header signing is used.

M-Switch content conversion can strip S/MIME signatures, and can add an S/MIME signature. So M-Switch can be used to add S/MIME signatures at a boundary, or to add signatures where clients cannot do this, to provide onward message integrity services.

All of these capabilities work for both single wrap and triple wrap messages.

S/MIME Encryption is supported by M-Switch Encryption, which is a capability that may be added to M-Switch.

Security Labels

M-Switch provides support for Security Labels in a number of formats:

  • ESS Labels using the standard RFC 2634 encoding in S/MIME.
  • ESS Labels, base64 encoded in a configurable X- Header
  • Text encoded labels, represented in X-Header, Subject for First Line of Text (FLOT).

M-Switch can convert between label formats, using a Security Policy (SPIF) based approach to map between the various supported label formats. This conversion can also use configured equivalent labels to map between different Security Policies.

M-Switch can make authorization decisions based on presence and validity of a security label. It can also make Access Control decisions (checking against Security Clearance in the context of a governing Security Policy) based on destination channel, MTA, and user.

For more information see [Security Label Capabilities in M-Switch].

Authorization & Routing Policy

M-Switch provides a comprehensive rule based authorization mechanism, for controlling which messages can be sent and how they are sent. Capabilities include:

  • Control based on sender and recipient, including address pattern matching.
  • Prevention of message relay.
  • Controls based on destination channel, which enables control of protocols and options used.
  • Control of content conversion.
  • Controls based on message size and message priority.
  • Controls based on S/MIME signatures and security labels.
  • Control for archiving.
  • Controls based on submitting IP address and sub-network and on submitting host and authentication. This is useful to separate out “internal” users, so that different policy can be applied. This is set up as “smtp-internal” and “smtp-external” in default M-Switch configurations.
  • Subject Indicator Code (SIC) count.
  • Security Classification.

Recipient Addition

M-Switch provides an authorization controlled mechanism to add additional recipients to a message. This is implemented as an extension to the Archive Capability, so that inbound messages may be "archived" by sending email to a configured recipient. This can be used for archiving, but also provides a mechanism to get selected messages sent to additional recipients. The recipient addition capability can also be used for a variety of purposes, including:

  • Sending select messages to an additional “backup” address.
  • Monitoring traffic to or from selected local users or remote destinations.

Security and Authentication

Isode uses Transport Layer Security (TLS) for data confidentiality and Simple Authentication and Security Layer (SASL) for authentication. SASL is also used to map simple identifiers onto directory names for authentication. A wide range of SASL authentication mechanisms are supported, including GSSAPI (Kerberos). X.509 (PKI) based authentication can be used, by using TLS and SASL-EXTERNAL authentication. SASL and TLS are supported for SMTP Message Submission, and may be optional or mandatory.

SASL authentication identifiers are usually managed in the directory, but may also be configured in an XML database, which may be suitable for small deployments.

SASL and TLS are used by Isode’s SOM protocols, so that secure management over SOM is possible. Currently, MConsole supports SASL, but not TLS.

TLS, SASL and S/MIME Cryptography may be configured to be compliant with FIPS 140-2.

Operator Authentication and Rights

M-Switch provides authentication for both configuration and operation. Users are authenticated against the directory. Isode’s recommended model is that (human) users authenticate as themselves, and that each user is given appropriate rights. The benefit of this approach is that all actions can be audit logged according to the user (not the role) which improves accountability when activity is analysed.

Configuration is held in the directory, and so the operator will authenticate to the directory. Directory access control is used to give users full rights on the configuration, read only, or no access.

Operational access uses the SOM protocol, which uses SASL authentication against the directory, so that common authentication is used for configuration and operation. Operator rights for SOM usage are configured using a directory attribute.