Internet Draft                                            T Dean
draft-ietf-smime-domsec-00.txt                            W Ottaway
July 15, 1998                                             DERA
Expires in six months

                    Domain Security Services using S/MIME


Status of this memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To view the entire list of Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net ( Northern Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu(US West Coast).

Abstract

This document describes how the S/MIME protocol can be processed and
generated by a number of components of a messaging system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely - for example when two domains use incompatible
messaging technologies such as X.400 and SMTP/MIME. This document is
also applicable to organisations and enterprises that do not have
encryption or signing capabilities at the desktop, but wish to
interoperate securely using the S/MIME protocol.

This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to:
     ietf-smime-request@imc.org
with the single word
     subscribe
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.

Acknowledgements

Significant comments were made by Trevor Freeman, Russ Housley, Dave Kemp
and Jim Schaad.

1. Introduction

The S/MIME [1] series of standards define a data encapsulation format
for the provision of a number of security services including data
integrity, confidentiality, and authentication. S/MIME is designed for
use by messaging clients to deliver security services to distributed
messaging applications.

There are many circumstances when it is not feasible or practical to
provide end-to-end (ædesktop-to-desktopÆ) security services,
particularly between different security domains. An organisation which
is considering providing end-to-end security services will typically
have to deal with some if not all of the following issues:

1) Heterogeneous Message Access Methods: users are accessing mail using
   mechanisms which re-format messages, such as using Web browsers.
   Message reformatting in the Message Store makes end-to-end encryption
   and signature validation impossible.

2) Message screening and audit: server-based mechanisms such as
   searching for prohibited words or other content, virus scanning, and
   audit, are incompatible with end-to-end encryption.

3) Cross-certification problems: There may not be any cross-certificate
   links between two organisations. Or an organisation may be sensitive
   about parts of its PKI and unwilling to expose them to outside
   access. For either of these reasons, end-to-end encryption and
   signature validation are impossible.

4) Heterogeneous Message transports: one organisation using X.400 wishes
   to communicate with another using SMTP. Message reformatting at
   gateways makes end-to-end encryption and signature validation
   impossible.

5) Cost: providing the necessary key management infrastructure and other
   items such as hardware tokens for all users may be too expensive.

One solution to these problems is to provide message security services
at the level of a domain or an organisation. This document specifies how
these ædomain security servicesÆ can be provided using the S/MIME
protocol. Domain security services may replace or complement mechanisms
at the desktop. For example, a domain may decide to provide desktop-to-
desktop signatures but domain-to-domain encryption services. Or it may
allow desktop-to-desktop services for intra-domain use, but enforce
domain-based services for communication with other domains.

Messages can be processed and generated by a number of components of a
messaging system, such as message transfer agents, guards and gateways.
Any of these agents may provide domain security services.

The term 'Third Party' as used in this document means any entity in a
messaging system other than the originator and final recipient(s) that
processes messages. This includes Message Transfer Agents (MTAs),
domain mail servers, guards and firewalls operating at security
boundaries, and gateways that translate between different protocol
formats. A third party may sign, encrypt, decrypt, and check signatures
on a message.

Throughout this draft the terms MUST, MUST NOT and SHOULD NOT are used
in capital letters. This conforms to the definitions in [2].

2. Overview of Domain Security Services

In a distributed system, a message is sent from an originator to a set
of recipients that may be in the same or different security domains.
This section first defines what is meant by a security domain. It then
gives an informal overview of the security services that are provided by
S/MIME between different security domains. These services are provided
by a combination of mechanisms in the sender's and recipient's domains.
Later sections describe definitively how these services map onto
elements of the S/MIME protocol.

2.1 Definition of a Security Domain

A 'security domain' is defined as a collection of hardware and personnel
operating under a single security authority and performing a common
business function. Members of a security domain will of necessity share
a high degree of mutual trust, due to their shared aims and objectives.
A security domain is typically protected from direct outside attack by
physical measures and from indirect (electronic) attack by a combination
of firewalls and guards at network boundaries. The interface between two
security domains is termed a 'security boundary'. One example of a
security domain is an organisational network ('Intranet').

2.2 Domain Signature

A domain signature is a S/MIME SignerInfo [3] created on behalf of a
collection of users in a domain. A domain signature can be used when
end users do not have signing capabilities at the desktop. It can also
be used to bridge between two domains that have incompatible or
disconnected signature systems, such as when there are no cross-
certificate links between their Public Key Infrastructures (PKIs). In
this case a process which creates a Domain Signature first checks the
originator's signature using the source Domain's PKI. It then re-signs
the message using its key and certificate from the destination Domain's
PKI, which can then be verified by the recipient(s).

A domain signature can also be used in situations when messages need to
be reformatted inside the message transfer system. Message reformatting
is needed at gateways between X.400 and SMTP-MIME domains, or on
conversion between HTTP-MIME and SMTP-MIME message representations. In
both cases the recipient is unable to verify the originator's signature.
Therefore, a Domain Signature is generated at the reformatting point to
indicate that the originator's signature has been authenticated.

2.3 Domain Encryption

Domain encryption is S/MIME encryption performed on behalf of a
collection of users in a domain. Domain encryption can be used to
protect information between domains, for example, when two 'Intranets'
are connected using the Internet. It can also be used when end users do
not have encryption capabilities at the desktop, or when two domains
employ incompatible encryption schemes. In the latter case messages
from the originator's domain are re-encrypted using an algorithm, key,
and certificate which can be decrypted by the recipient(s).

2.4 Additional Attributes

A third party in a domain may attach additional signed attributes to a
message. This is for one of the following reasons:

1) To add domain-wide attributes such as a domain security label of a
   'system-high' domain.

2) To add mapped attributes, for processing by recipients in a domain
   different from that of the originator. An example is the addition of
   the 'Equivalent Label' attribute defined in ESS [4].

2.5 Message Review and Release

A third party may review messages before they are released from a
domain. This is used when organisational policy or good security
practice require that messages be reviewed before they are released to
external recipients. Having reviewed a message, a review and release
signature is added to it. The review and release signature may be
checked by a firewall at the domain boundary, to ensure that only
reviewed messages are released.

Details of the review process are outside the scope of this document,
but may involve scanning message contents for viruses or other malicious
code, searching for prohibited words or other content, or checking for
the presence or absence of certain security labels. Review and release
may be performed by a human reviewer or an automated process.

3. Mapping of Domain Security Services to the S/MIME Protocol

This section describes the S/MIME Protocol elements that are used to
provide the security services described above. ESS [4] introduces the
concept of triple-wrapped messages that are first signed, then
encrypted, then signed again. This document also uses this concept of
triple-wrapping. In addition, this document also uses the concept of
'signature encapsulation'. 'Signature encapsulation' denotes a complete
signed message that is wrapped in a second signature, the second
signature covering both the content and the first (inner) signature.
Signature Encapsulation may be performed on the inner or the outer
signature of a triple-wrapped message. The term 'parallel signatures'
means two or more signatures calculated over the same content. This
capability is described in CMS [3], where a set of one or more
SignerInfos can be attached to signed data.

3.1 Signature Types

An authenticated attribute is used to indicate the type of signature.
The ASN.1 [5] notation of this attribute is:-

   SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

   id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
        us (840) rsadsi (113549) <TBD> }

If present, the SignatureType attribute MUST be an authenticated
attribute, as defined in CMS [3]; it MUST NOT be an unauthenticated
attribute. If the SignatureType attribute is absent the recipient
SHOULD NOT make any assumptions about the type of signature.

A SignerInfo MUST NOT include multiple instances of SignatureType. An
authenticated attribute representing a SignatureType MUST only include
a single instance of SignatureType as an AttributeValue of attrValues
[3].

This document specifies the following types of signature:

1) Originator Signature
2) Domain Signature
3) Additional Attributes Signature
4) Review and Release Signature

Each of these signature types is generated and processed exactly as
described in CMS [3]. They are distinguished by the presence of the
following values in the SignatureType authenticated attribute:

id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1}
id-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-signatureType 2 }
id-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-signatureType 3}
id-sigtype-review-release-sig OBJECT IDENTIFIER ::= { id-signatureType
 4}

Any of these signature types may encapsulate another signature of the
same or a different type, or any other type of content, as documented in
CMS [3]. The following sections describe the conditions under which
each of these types of signature may be generated, and how they are
processed.

3.1.1 Originator Signature

The 'originator signature' is used to indicate that the signer is the
originator of the message and its contents. The 'originator signature'
is indicated by the presence of the value id-sigtype-originator-sig in
the 'signature type' authenticated attribute. No other Object
Identifiers may be included in the sequence of OIDs if this value is
present.

3.1.2 Domain Signature

A 'domain signature' is generated on behalf of a collection of users in
a domain. A 'domain signature' on a message authenticates the fact that
the message has originated in that domain. Before signing, a process
generating a 'domain signature' MUST first satisfy itself of the
authenticity of the message originator. This is achieved by one of two
methods. Either the 'originator's signature' is checked, if S/MIME
signatures are used inside a domain. Or if not, some mechanism external
to S/MIME is used, such as the physical address of the originating
client or an authenticated IP link.

If the originator's authenticity is successfully verified by one of the
above methods, a 'domain signature' may be added to a message in one of
the following ways:

1) An unsigned message is wrapped in a SignedData, and a SignerInfo is
   attached containing the 'domain signature'. The originator's
   information is included as part of a header field in the encapsulated
   message.

2) Signature Encapsulation is used to wrap the original signed message
   with a 'domain signature'. As stated above, the originator's
   signature MUST first be checked by the domain signer.

When a 'domain signature' is applied the mlExpansionHistory and
eSSSecurityLabel attributes MUST be copied from other signerInfos as
stated in [4].

If the originator's authenticity is not successfully verified, a 'domain
signature' MUST NOT be generated.

On reception, the 'domain signature' may be used to verify the
authenticity of a message. If it encapsulates a SignedData, the
certificate(s) of the inner SignerInfo should be used to identify the
originator. This information can then be displayed to the recipient. A
domain signer can be assumed to have verified any signatures that it
encapsulates. Therefore, it is not necessary to verify these signatures
before treating the message as authentic. However, this standard does
not preclude a recipient from attempting to verify any other signatures
that are present.

The 'domain signature' is indicated by the presence of the value Id-at-
sigtype-domain-sig in the 'signature type' authenticated attribute. No
other Object Identifiers may be included in the sequence of OIDs if this
value is present.

3.1.3 Additional Attributes Signature

The 'additional attributes' signature type indicates that the SignerInfo
contains additional attributes that are associated with the message.
All attributes in the applicable SignerInfo MUST be treated as
additional attributes. Successful verification of an 'additional
attributes' signature means only that the attributes are authentically
bound to the message. A recipient MUST NOT assume that its successful
verification also authenticates the message originator. The authenticity
of the message originator should be verified by checking an encapsulated
signature of the appropriate type.

A signer may include any of the attributes listed in CMS [3] or ESS [4]
when generating an 'additional attributes' signature. The following
attributes have a special meaning, when present in an 'additional
attributes' signature:

1) Equivalent Label: label values in this attribute are to be treated as
   equivalent to the security label contained in an encapsulated
   SignerInfo, if present.

2) Security Label: the label value indicates the aggregate sensitivity
   of the inner message content plus any encapsulated signedData and
   envelopedData containers. The label on the original data is indicated
   by the value in the originator's signature, if present.

An 'additional attributes' signature is indicated by the presence of the
value Id-at-sigtype-add-attrib-sig in the 'signature type' authenticated
attribute. No other Object Identifiers may be included in the sequence
of OIDs if this value is present. An 'additional attributes' signature
may be added in parallel with other signatures in a SET OF SignerInfos.

3.1.4 Review and Release

The 'Review And Release' signature indicates that the signer has
reviewed the message.  Successful verification of a 'Review and Release'
signature means only that the signer has approved the message for
release from a domain.  A device on a domain boundary such as a Mail
Guard or firewall may be configured to check review and release
signatures. A recipient MUST NOT assume that its successful verification
also authenticates the message originator. The authenticity of the
message originator should be verified by checking an encapsulated
signature of the appropriate type.

A 'Review and Release' signature is indicated by the presence of the
value Id-at-sigtype-review-release-sig in the 'signature type'
authenticated attribute. No other Object Identifiers may be included in
the sequence of OIDs if this value is present.

3.2 Domain Encryption and Decryption

Domain encryption is encryption performed by a third party on behalf of
a set of originators in a domain. Domain decryption is decryption
performed by a third party on behalf of a set of recipients in a domain.
These processes may be performed in combination, as shown below.

  --------------------------------------------------------------------
 |                        | Recipient Decryption |  Domain Decryption |
 |------------------------|----------------------|--------------------|
 | Originator Encryption  |       Case(a)        |       Case(c)      |
 | Domain Encryption      |       Case(b)        |       Case(d)      |
  --------------------------------------------------------------------

Case (a), encryption of messages by the originator for decryption by the
final recipient(s), is described in CMS [3]. In Cases (b) and (d),
encryption is performed not by the originator but by a third party in
the sending domain. In Cases (c) and (d), decryption is performed not
by the recipient(s) but by a third party in the destination domain.

A client implementation that conforms to this standard MUST support
cases (a) and (c) for transmission, and cases (a) and (b) for reception.
A Domain Encryption implementation that conforms to this standard MUST
support cases (b) and (d), for transmission, and cases (c) and (d) for
reception.

The process of encryption and decryption is documented in CMS [3]. The
only additional requirement introduced by domain encryption and
decryption is for greater flexibility in the management of keys, as
described in the following subsections.

The mechanisms described below are applicable both to key agreement and
key transport systems, as documented in CMS. The phrase 'encryption
key' is used as a collective term to cover the key management keys used
by both techniques.

3.2.1 Domain Encryption Key Management

Domain Encryption is shown as cases (b) and (d) in the above table.
Domain Encryption uses a domain-wide encryption key from the sender's
domain. Information about this key is conveyed to the recipient by
one of two methods:-

1) Public information about this key is held in a certificate and
   conveyed to the recipient(s) in the 'Certs' field of the
   OriginatorInfo in the Envelope.

2) The recipient(s) looks up the key for the users domain by replacing
   the originator's name within the address with the domain encryption
   name [6].

   For example :-

   a) If the originator is originator@foo.com then lookup key for
      domain-encrypting-authority@foo.com.

   b) If the originator is c=us;a=com;p=foo;s=originator then look up
      key for c=us;a=com;p=foo;s=domain-encrypting-authority.

   c) If the originator is c=gb;o=foo;cn=originator then look up key for
      c=gb;o=foo;cn=domain-encrypting-authority.

An implementation conforming to this standard MUST support both methods.

The name in the encryption certificate may not match the name in any
encapsulated signatures. For example, when a message is signed by the
originator and is encrypted by the domain. An implementation that
conforms to this standard MUST allow for this possibility. This includes
both a client and a third party implementation.

3.2.2 Domain Decryption Key Management

Domain Decryption is shown as cases (c) and (d) in the above table. In
these cases, the encryption process uses a domain-wide encryption key
for the recipient(s)' domain. The selection of this key is achieved by
one of two methods:

1) The sending process explicitly searches for a certificate containing
   the domain encryption key of the recipient(s)' domain. This is
   achieved by mapping the recipient(s)' name to a domain name and then
   locating the encryption certificate containing that domain name.
   Mapping from recipient names to Domain names, and conventions for
   domain names are outside the scope of this standard.

2) All the members of the receiving domain are issued with certificates
   containing a single key. The private component of that key is held
   by an entity in the domain that performs the decryption process
   on their behalf. By selecting the appropriate certificate, a sending
   process will implicitly encrypt for decryption by the Domain
   Decryption process.

An implementation that conforms to this standard MUST support mechanism
(1). It may also support mechanism (2). This includes both a client and a
third party implementation.

4. Security Considerations

   Domain Security Services provide a method for digitally
   signing data, digesting data, encrypting data, and authenticating
   data.

   Implementations must protect the signer's private key.  Compromise of
   the signer's private key permits masquerade.

   Implementations must protect the key management private key and the
   content-encryption key.  Compromise of the key management private key
   may result in the disclosure of all messages protected with that key.
   Similarly, compromise of the content-encryption key may result in
   disclosure of the encrypted content.

5. References

[1] Ramsdell, B., "S/MIME Version 3 Message Specification", Internet
    Draft draft-ietf-smime-msg-04, May 1998.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
    Levels", BCP 14, RFC 2119, March 1997.

[3] Housley, R., "Cryptographic Message Syntax", Internet Draft
    draft-ietf-smime-cms-05.txt, March 1998.

[4] Hoffman, P., "Enhanced Security Services for S/MIME", Internet Draft
    draft-ietf-smime-ess-06.txt, May 1998.

[5] International Telecommunications Union, Recommendation X.208, "Open
    systems interconnection: specification of Abstract Syntax Notation
    (ASN.1)", CCITT Blue Book, 1989.

[6] Ramsdell, B., "Role Names in X.509 Certificates", Internet Draft
    draft-ramsdell-role-names, April 29 1998.

6. Authors' Addresses

Tim Dean
DERA Malvern
St. Andrews Road
Malvern
Worcs
WR14 3PS

Phone: +44 (0)1684 894239
Fax:   +44 (0)1684 6113
Email: t.dean@eris.dera.gov.uk


William Ottaway
DERA Malvern
St. Andrews Road
Malvern
Worcs
WR14 3PS

Phone: +44 (0)1684 894079
Fax:   +44 (0)1684 896113
Email: w.ottaway@eris.dera.gov.uk