This chapter presents the MHS security features that counter the
vulnerabilities described in Chapter \ref{x400-vulnerabilities}.  These 
features can be categorized into three general services.  First, they 
allow various MHS entities to authenticate their identity.  Second, they 
protect messages against modification, and third, they protect messages 
against unauthorized disclosure.
\vspace{5 mm}

The security features provided by the MHS apply only to messages submitted 
directly to an MTA by an MTS user (i.e., a User Agent, Message Store, or 
Access Unit).  They do not apply to communication between the MHS user 
(e.g., a person) and the MHS (e.g., the person's UA).  Thus, the scope of 
MHS security services extends, for example, to communication between two UAs, 
but not to communication between two people.
\vspace{5 mm}

Many of the MHS security services require security capabilities within the UA,
but not the MTA.  For example, to ensure the confidentiality of a message, 
the originating UA encrypts the message content, and submits the message to
the MTS.  Any MTA that handles the message uses envelope information to 
make decisions (e.g., routing), never needing access to the message content.  
Some security services, however, require MTAs with security capabilities.  
For example, to ensure that an originating MTA submitted a message for 
delivery, the originating MTA must generate and return proof of the 
submission to the originating user.  Some of the MHS security services apply 
to the MS (Message Store) as well as to UAs and MTAs, such as services 
involving the exchange of security labels.  In general, however, the MS is 
transparent to security features that apply between the originating and 
recipient UAs.
\vspace{5 mm}

Many of the MHS security services rely on encryption techniques.  Most
services are flexible regarding whether asymmetric or symmetric encryption
techniques are used, and more specifically, which algorithms are used.
Some services, such as the non-repudiation services, require an asymmetric 
encryption algorithm.
\vspace{5 mm}

The remainder of this chapter describes specific MHS security services.
These services include: {\em message security labelling, secure access
management, origin authentication, data integrity, data confidentiality,
non-repudiation,} and {\em security management}.

\section{Message Security Labelling \label{x400-msl}}

The {\em message security labelling} service binds a security label to an
MHS object.  Security labels can be bound to transferable objects (e.g., 
messages, reports), MHS entities (e.g., MTAs, UAs), and associations between 
peer MHS entities (e.g., UAs and MTAs, MTAs and MTAs).  
\vspace{5 mm}

The following simple example illustrates a use of security labels.  
An MTA services two users: {\em User1} and {\em User2}.  Each user registers
a set of security labels with the MTA.  At some later time, a message 
addressed to both users arrives at the MTA.  The message contains a security 
label with a security classification of {\em Secret}.  The MTA examines the
security labels registered for its users, and ascertains that {\em User1} has
registered a {\em Secret} security label, however, {\em User2} has not.  
Depending on the security policy in force, the MTA may deliver the message 
to {\em User1}, and non-deliver the message to {\em User2}.  By the same
mechanism, the MTA may prevent {\em User2} from originating messages
containing security labels classified as {\em Secret}.
\vspace{5 mm}

As illustrated in the example, security labels can be used to control the
sensitivity of messages originated by and delivered to a user.  Section
\ref{x400-sc} describes how security labels can also be used to prevent the
misrouting of messages.

\section{Secure Access Management \label{x400-sam}}

{\em Secure access management} enables authentication between peer entities
in the MHS.  It counters the threats of masquerade, misrouting, and the 
replay of connection requests.  {\em Secure access management} can be 
divided into two components: {\em peer entity authentication} and {\em 
security context}.  

\subsection{Peer Entity Authentication \label{x400-pea}}

The {\em peer entity authentication} service allows two adjacent components
in the MHS to create a secure association by transferring authentication
credentials.  For example, a UA may provide a password to its MTA when 
establishing a connection to submit a message.  This service counters the 
threat of masquerade (i.e., impersonation of one MHS entity to another).  
\vspace{5 mm}

To provide {\em peer entity authentication}, the connection initiator 
transfers either simple authentication credentials (i.e., passwords) or 
strong authentication credentials (i.e., signatures) to the connection
recipient.  If strong authentication is used, the signature is applied to 
an asymmetric token, called a {\em bind} token.
\vspace{5 mm}

In the bind token's signed-data, the connection initiator places a
non-repeating number.  This number allows the recipient to detect replay 
threats.  For example, if a recipient receives a connection request where
the token's non-repeating number duplicates a number received previously, 
the recipient can assume that the connection request is a replay of the 
previous connection.
\vspace{5 mm}

The initiator may use the bind token's encrypted-data to transfer 
secret information, such as a symmetric encryption key.  The communicating
parties can use this key to encrypt data transferred across the
connection (see Section \ref{x400-pos} for an example).
\vspace{5 mm}

The connection initiator signs the bind token using its private 
asymmetric key.  The recipient validates the token signature using the 
initiator's public key certificate.  This certificate may be registered
with the recipient, transferred during the authentication process, or
distributed by some other means.

\subsection{Security Context \label{x400-sc}}

During the peer authentication process, the initiator may propose a 
{\em security context}.  A security context is a set of security 
labels which can determine the sensitivity of messages passed over an 
association.  If the initiator has registered a set of security labels 
with the connection recipient, the proposed security context must be a 
subset of the registered labels.
\vspace{5 mm}

The following examples illustrate how security contexts control the
transfer of messages over an association, and, in specific instances, 
counter the threat of message misrouting.  If a security 
context is established between an originator and the originating MTA, 
the originator may only be allowed to submit messages with security 
labels permitted by the security context.  If a security context is  
established between two MTA's, the transfer of messages and reports may 
be determined by the security label of the message or report, and the 
security context.  This allows security labels to be used for routing 
purposes; only trusted MTAs (i.e., MTAs capable of establishing a security 
context) will be used to route a message.  If a security context is 
established between a recipient and the delivering MTA, the MTA may only 
be allowed to deliver messages and reports with security labels permitted 
by the security context.  If the security label for a message is allowed
by the recipient's registered security labels, but not by the recipient's
current security context, the MTA may retain the message for delivery at 
a later time.  

\section{Origin Authentication \label{x400-oa}}

{\em Origin authentication} is a set of security services allowing 
communicating parties to authenticate their identities.  It comprises
the following services: {\em message origin authentication, report origin
authentication, proof of submission,} and {\em proof of delivery}.

\subsection{Message Origin Authentication \label{x400-moa}}

{\em Message origin authentication} allows the identity of a message
originator to be verified.  This service counters the threat of 
masquerade (i.e., impersonation of the message originator).  Since 
origin authentication has limited utility without content integrity, the 
{\em message origin authentication} service also provides assurance that 
the message content has not been modified.  If a security label is present
in the message, this service also enables proof of association between the 
security label and the message.  {\em Message origin authentication} can 
be provided by one of two methods: a message origin authentication check or 
a content integrity check.

\subsubsection{Message Origin Authentication Check \label{x400-moac}}

The message origin authentication check allows the identity of a message 
originator to be verified by the message recipient(s), and any MTA
transferring the message.  It is provided on a per-message basis using 
an asymmetric encryption technique.  
\vspace{5 mm}

The message origin authentication check is a digital signature included
in the message envelope.  The originator computes the signature as a 
function of the message content, the message content identifier (an optional 
attribute generated by the originator to facilitate the correlation of a 
message with any reports it may provoke), and the message security label.  
If the message content is encrypted, the signature is computed as a function 
of the encrypted content.  Thus, the identity of the originator can be
confirmed without the need to see the plaintext content.
\vspace{5 mm}

If the signature is computed using the plaintext content, the
message origin authentication check also provides {\em non-repudiation 
of origin} (see Section \ref{x400-nr}).  This provision is not maintained 
if the signature is computed using the encrypted message content.  The
message originator, although unable to deny sending the encrypted content,
can deny that the content decrypted by the recipient is the same as the 
original plaintext content.
\vspace{5 mm}

The message origin authentication check is computed using the originator's 
private asymmetric encryption key.  The service places no restrictions on
the originator regarding which asymmetric algorithm is used.  The 
originator conveys the object identifier for the algorithm, any input 
parameters required by the algorithm (e.g., an RSA message digest 
identifier), and the signature generated by the algorithm, in the message 
envelope.
\vspace{5 mm}

The message recipient(s), and any MTA transferring the message, can
validate the signature using the originator's public key certificate.  
This certificate may be transferred in the message envelope, or obtained
by some other means.

\subsubsection{Content Integrity Check \label{x400-cic}}

The content integrity check allows the identity of the originator to be 
verified by the message recipient(s), and possibly by any MTA transferring 
the message.  It is provided (typically) on a per-recipient basis, using 
either symmetric or asymmetric encryption techniques.  
\vspace{5 mm}

The content integrity check is a cryptographic checksum included in the
message token.  A distinct token can be generated for each message 
recipient.  Unlike the message origin authentication check, the 
content integrity check must be computed as a function of the plaintext  
message content.  The originator places the check in the token's signed-data, 
or if the secrecy of the check is required, in the token's encrypted-data.
\vspace{5 mm}

The originator may choose either a symmetric or asymmetric encryption 
algorithm to compute the check.  If the originator chooses a symmetric 
encryption algorithm, a symmetric encryption key is used by the 
message originator to compute the check, and by the message recipient(s)
to validate the check.  This key can be transferred in the token's
encrypted-data, or distributed by some other means (e.g., by prior
agreement).  Since only the originator and the recipient(s) share this 
key, no MTA transferring the message can authenticate the message.
\vspace{5 mm}

If the content integrity check is computed with an asymmetric encryption
algorithm (i.e., is a digital signature), the originator's private asymmetric 
key is used to generate the check.  The recipient validates the check using 
the originator's public key certificate.  This certificate may be 
transferred in the message envelope, or obtained by some other means.  
Providing the originator does not transfer the check in the token's 
encrypted-data, any MTA handling the message can validate the check.
\vspace{5 mm}

The content integrity check can be computed using any symmetric or asymmetric
algorithm understood by both the originator and the recipient.  All
information relevant to the algorithm can be conveyed in the message token.  
\vspace{5 mm}

By placing the content integrity check in the token's signed-data or 
encrypted-data, the originator provides {\em non-repudiation of origin} 
(see Section \ref{x400-nr}) in addition to {\em origin authentication}.  This
is because the check is computed using the plaintext content, then signed
by the originator.  The originator may also transfer a security label with 
the content integrity check in either the token's signed-data or 
encrypted-data, to bind the security label to the message content.  

\subsection{Report Origin Authentication \label{x400-roa}}

The {\em report origin authentication} service enables a message 
originator to authenticate the origin of a delivery/non-delivery report.  
This service counters the threat of masquerade (i.e., impersonation of the
report originator).  It is provided to the message originator, as well 
as to any MTA transferring the report, on a per-report basis 
using an asymmetric encryption technique.  If a security label is present 
in the report, the service binds the security label to the report.
\vspace{5 mm}

The reporting MTA provides this service by generating a report origin 
authentication check (i.e., a digital signature) and sending it in the 
report.  The report is signed if a message origin authentication check 
is present in the subject message.  The report signature is computed as 
a function of the content identifier and security label of the subject 
message, the name of the recipient, and for:

\begin{description}
 \item[a delivery report:] the time the message was delivered, and if
       requested by the originator, {\em proof of delivery} (see Section
       \ref{x400-pod}),
 \item[a non-delivery report:] the reason and diagnostic for non-delivery.
\end{description}

The report origin authentication check is derived using the reporting
MTA's private asymmetric encryption key.  The check is validated by the 
originator of the subject message, and any MTA transferring the
message, using the MTA's public key certificate.  This certificate 
may be transferred in the report, or obtained by some other means.

\subsection{Proof of Submission \label{x400-pos}}

{\em Proof of submission} allows a message originator to obtain proof that
its MTA submitted a message for delivery to the intended recipient(s).  This 
service counters the threat of masquerade (i.e., impersonation of an MTA to 
an MTS user).  It is provided on a per-message basis using symmetric or
asymmetric encryption techniques.
\vspace{5 mm}

The message originator requests the service by submitting a {\em proof of 
submission} request with a message.  The originator's MTA returns the proof 
in an acknowledgement.  The proof is computed as a function of 
the submitted message arguments (i.e., the submitted message without the 
content), the message identifier (which is added by the MTA), and the 
time the message was submitted.  
\vspace{5 mm}

To generate the proof using an asymmetric encryption algorithm, the MTA signs 
the acknowledgement using its private asymmetric key.  The message originator 
validates the signature using the MTA's public key certificate.  This
certificate may be registered with the originator, transferred in the 
acknowledgement, or obtained by some other means.  An asymmetric {\em proof 
of submission} also provides {\em non-repudiation of submission} (see 
Section \ref{x400-nr}).
\vspace{5 mm}

If the message originator transferred a symmetric encryption key to the MTA 
during the authentication process (see Section \ref{x400-pea}), the MTA can 
compute the {\em proof of submission} using this key.  A symmetric {\em proof 
of submission} does not provide {\em non-repudiation of submission}.  

\subsection{Proof of Delivery \label{x400-pod}}

{\em Proof of delivery} allows a message originator to verify that
a message was delivered to the intended recipient(s).  This service 
counters the threat of falsely acknowledged receipt.  It is provided on a 
per-recipient basis using symmetric or asymmetric encryption techniques.
\vspace{5 mm}

The message originator requests the service from each message recipient 
(i.e., proof may be requested from some recipients, but not from others).  
The recipient returns the proof in a delivery report.  Although the 
report is created by the delivering MTA, the proof included in the
report is generated by the recipient MTS user (e.g., the recipient UA). 
The proof is computed as a function of the recipient's name, the time the 
message was delivered, and the following information from the subject
message:  the content identifier, the security label, and the plaintext 
content. 
\vspace{5 mm}

To generate the proof using an asymmetric encryption algorithm, the
recipient signs the report using its private asymmetric key.  The message
originator validates the signature using the recipient's public key 
certificate.  This certificate may be transferred in the report, or
obtained by some other means.  An asymmetric {\em proof of delivery} also 
provides {\em non-repudiation of delivery} (see Section \ref{x400-nr}).
\vspace{5 mm}

If a symmetric encryption algorithm is used, the recipient computes the
{\em proof of delivery} using a symmetric encryption key.  The originator 
uses the same key to validate the proof.  The X.400 Recommendations do not 
define how this key is distributed between the communicating parties.  A 
symmetric {\em proof of delivery} does not provide {\em non-repudiation of 
delivery}.
\vspace{5 mm}

A message recipient is not mandated to return {\em proof of delivery}.
That is, even if the originator requests the service, the recipient has
the option of not returning the proof.  Thus, not receiving {\em proof of
delivery} does not imply non-delivery of the subject message.

\section{Data Integrity \label{x400-di}}

{\em Data integrity} is a set of security services verifying that the
content of a message has not been modified, and if a sequence of messages
is transferred, that the sequence has been preserved.  It comprises the 
{\em content integrity} and {\em message sequence integrity} services.

\subsection{Content Integrity \label{x400-ci}}

The {\em content integrity} service allows an originator to provide proof 
that the content of a single message has not been modified.  As mentioned 
previously, {\em content integrity} is meaningless to a user 
without {\em origin authentication}.  {\em Content integrity}, on its own, 
authenticates the content of a message; however, the message may have
been submitted by an imposter.  {\em Origin authentication}, on its own, 
verifies the identity of message originator; however, the content received
may not match the content originated.  Thus, {\em content integrity} and 
{\em origin authentication} are provided by the same security mechanisms.  
These mechanisms, the content integrity check and the message origin
authentication check, are described in Section \ref{x400-moa}.

\subsection{Message Sequence Integrity \label{x400-msi}}

{\em Message sequence integrity} provides proof that the ordering of a 
sequence of messages sent from an originator to a recipient has been 
preserved.  This service counters message sequencing threats, such as the 
replaying and re-ordering of messages.  It is provided on a per-recipient 
basis using symmetric or asymmetric encryption techniques.
\vspace{5 mm}

To provide the service, the message originator generates a sequence number, 
which identifies the position of the message in the sequence.  This number
is transferred in the message token's signed-data, or if the secrecy of the
number is required, in the token's encrypted-data.  Each originator/recipient 
pair using this service maintains a distinct pair of sequence numbers.  

\section{Data Confidentiality \label{x400-dc}}

{\em Data confidentiality} is a set of services used to protect data against 
unauthorized disclosure.  It comprises the {\em content confidentiality} 
and {\em message flow confidentiality} services.

\subsection{Content Confidentiality \label{x400-cc}}

{\em Content confidentiality} prevents the disclosure of the plaintext 
content of a message to any party other than the intended recipient(s).  It 
is provided on a per-message basis using an asymmetric or symmetric encryption
technique.  The encrypted content is unintelligible to any MTA handling 
the message.
\vspace{5 mm}

If the originator chooses an asymmetric algorithm, the recipient's public 
asymmetric key is used to encrypt the message content.  The recipient uses 
its private asymmetric key to decrypt the content.  If an asymmetric 
encryption algorithm is used, the message can only be addressed to a 
single recipient (i.e., the recipient whose private key is paired with the 
public key used to perform the encryption).
\vspace{5 mm}

If the originator chooses a symmetric algorithm, delivery to multiple
recipients is possible.  The originator encrypts the content using a 
symmetric encryption key.  This key may be distributed to each message 
recipient by placing the key in the encrypted-data of the message token 
for that recipient.  The key may also be distributed by some other means
(e.g., by prior agreement).
\vspace{5 mm}

The message originator can encrypt the content using any symmetric or 
asymmetric algorithm understood by both the originator and the recipient.  
All information relevant to the algorithm, such as the algorithm's object
identifier and any input parameters, can be conveyed in the message 
envelope or the signed-data of the message token.

\subsection{Message Flow Confidentiality \label{x400-mfc}}

{\em Message flow confidentiality} allows the message originator to conceal
the flow of a message through the MHS, protecting against information that
may be derived from its observation.  This service counters the threats of
traffic analysis and loss of anonymity of the communicating parties.  It 
is provided by a technique called {\em double enveloping}.
\vspace{5 mm}

To provide this service, the message originator specifies that the content
of a message is itself a complete message (usually encrypted).  The 
recipient on the outer envelope, upon receiving the message, forwards the
message to the recipient named on the inner envelope.  Double enveloping
only provides a limited {\em message flow confidentiality} service.  A
more comprehensive service would include {\em traffic padding} and {\em
routing control}, which are outside the scope of the X.400 Recommendations.

\section{Non-repudiation \label{x400-nr}}

Non-repudiation services provide unforgeable evidence that a specific 
action occurred.  The MHS provides the following non-repudiation 
services: {\em non-repudiation of origin}, {\em non-repudiation of 
submission}, and {\em non-repudiation of delivery}.  {\em Non-repudiation 
of origin} protects against any attempt by a message originator to deny 
sending a message.  {\em Non-repudiation of submission} protects against 
any attempt by an MTA to deny that a message was submitted for delivery.  
{\em Non-repudiation of delivery} protects against any attempt by a 
message recipient to deny receiving a message.
\vspace{5 mm}

The non-repudiation services are similar to their weaker proof
counterparts (i.e., {\em proof of submission, proof of delivery,} and 
{\em message origin authentication}); however, non-repudiation provides
stronger protection, because the proof can be demonstrated to a third
party.  Digital signatures are used to provide non-repudiation.
For example, if a recipient returns {\em proof of delivery} by signing 
a report, {\em non-repudiation of delivery} is also provided.  Since only
the recipient's private asymmetric key could have generated the signature,
the signature provides unforgeable evidence of message delivery.  Symmetric 
encryption cannot guarantee non-repudiation.  Since both the originator 
and recipient share the symmetric encryption key, either party can 
generate the proof.
\vspace{5 mm}

The exact mechanisms used to provide {\em non-repudiation of origin, 
non-repudiation of submission}, and {\em non-repudiation of delivery} are 
described in Sections \ref{x400-moac}, \ref{x400-pos}, and \ref{x400-pod} 
respectively.  Non-repudiation services may also be provided by a third party
notary; however, third party notaries are outside the scope of the X.400
Recommendations.  

\section{Security Management \label{x400-sm}}

Throughout this chapter, references have been made to MHS {\em security
management} services, namely, the {\em registration of security labels}, and 
the {\em registration of credentials}.  For completeness, these services are 
described in this section.
\vspace{5 mm}

The {\em registration of security labels} service allows an MTS user to 
convey a set of security labels that are maintained by its MTA.  The MTA
uses these labels primarily to control the delivery of messages to the MTS
user.
\vspace{5 mm}

The {\em registration of credentials} service allows peer MHS entities
(i.e., an MTS user and its MTA) to register credentials with each other.  
For simple authentication, credentials comprise the password associated 
with the entity.  For strong authentication, credentials comprise the 
entity's public key certificate.  These credentials are used primarily
when the peer entities are establishing an association.
