rfc3183.txt

RFC 的详细文档！

Network Working Group                                            T. Dean
Request for Comments: 3183                                    W. Ottaway
Category: Experimental                                           QinetiQ
                                                            October 2001


                 Domain Security Services using S/MIME

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes how the S/MIME (Secure/Multipurpose Internet
   Mail Extensions) protocol can be processed and generated by a number
   of components of a communication system, such as message transfer
   agents, guards and gateways to deliver security services.  These
   services are collectively referred to as 'Domain Security Services'.

Acknowledgements

   Significant comments were made by Luis Barriga, Greg Colla, Trevor
   Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev.

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.

   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 the X.400 series and SMTP/MIME, or when a single domain
   wishes to communicate securely with one of its members residing on an
   untrusted domain.  The scenarios covered by this document are
   domain-to-domain, individual-to-domain and domain-to-individual



Dean & Ottaway                Experimental                      [Page 1]

RFC 3183         Domain Security Services using S/MIME      October 2001


   communications.  This document is also applicable to organizations
   and enterprises that have internal PKIs which are not accessible by
   the outside world, but wish to interoperate securely using the S/MIME
   protocol.

   There are many circumstances when it is not desirable or practical to
   provide end-to-end (desktop-to-desktop) security services,
   particularly between different security domains.  An organization
   that 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) PKI deployment issues: There may not be any certificate paths
      between two organizations.  Or an organization may be sensitive
      about aspects of its PKI and unwilling to expose them to outside
      access.  Also, full PKI deployment for all employees, may be
      expensive, not necessary or impractical for large organizations.
      For any of these reasons, direct end-to-end signature validation
      and encryption are impossible.

   4) Heterogeneous message formats: One organization using X.400 series
      protocols wishes to communicate with another using SMTP.  Message
      reformatting at gateways makes end-to-end encryption and signature
      validation impossible.

   This document describes an approach to solving these problems by
   providing message security services at the level of a domain or an
   organization.  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.

   Domain services can also be used by individual members of a
   corporation who are geographically remote and who wish to exchange
   encrypted and/or signed messages with their base.





Dean & Ottaway                Experimental                      [Page 2]

RFC 3183         Domain Security Services using S/MIME      October 2001


   Whether or not a domain based service is inherently better or worse
   than desktop based solutions is an open question.  Some experts
   believe that only end-to-end solutions can be truly made secure,
   while others believe that the benefits offered by such things as
   content checking at domain boundaries offers considerable increase in
   practical security for many real systems.  The additional service of
   allowing signature checking at several points on a communications
   path is also an extra benefit in many situations.  This debate is
   outside the scope of this document.  What is offered here is a set of
   tools that integrators can tailor in different ways to meet different
   needs in different circumstances.

   Message transfer agents (MTAs), guards, firewalls and protocol
   translation gateways all provide domain security services.  As with
   desktop based solutions, these components must be resilient against a
   wide variety of attacks intended to subvert the security services.
   Therefore, careful consideration should be given to security of these
   components, to make sure that their siting and configuration
   minimises the possibility of attack.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [2].

2. Overview of Domain Security Services

   This section 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.

   The following security mechanisms are specified in this document:

   1. Domain signature
   2. Review signature
   3. Additional attributes signature
   4. Domain encryption and decryption

   The signature types defined in this document are referred to as
   DOMSEC defined signatures.








Dean & Ottaway                Experimental                      [Page 3]

RFC 3183         Domain Security Services using S/MIME      October 2001


   The term 'security domain' as used in this document 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 organizational
   network ('Intranet').

2.1 Domain Signature

   A domain signature is an S/MIME signature generated on behalf of a
   set of users in a domain.  A domain signature can be used to
   authenticate information sent between domains or between a certain
   domain and one of its individuals, for example, when two 'Intranets'
   are connected using the Internet, or when an Intranet is connected to
   a remote user over the Internet.  It can be used when two domains
   employ incompatible signature schemes internally or when there are no
   certification links between their PKIs.  In both cases messages from
   the originator's domain are signed over the original message and
   signature (if present) using an algorithm, key, and certificate which
   can be processed by the recipient(s) or the recipient(s) domain.  A
   domain signature is sometimes referred to as an "organizational
   signature".

2.2 Review Signature

   A third party may review messages before they are forwarded to the
   final recipient(s) who may be in the same or a different security
   domain.  Organizational policy and good security practice often
   require that messages be reviewed before they are released to
   external recipients.  Having reviewed a message, an S/MIME signature
   is added to it - a review signature.  An agent could check the review
   signature at the domain boundary, to ensure that only reviewed
   messages are released.

2.3 Additional Attributes Signature

   A third party can add additional attributes to a signed message.  An
   S/MIME signature is used for this purpose - an additional attributes
   signature.  An example of an additional attribute is the 'Equivalent
   Label' attribute defined in ESS [3].





Dean & Ottaway                Experimental                      [Page 4]

RFC 3183         Domain Security Services using S/MIME      October 2001


2.4 Domain Encryption and Decryption

   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 PKI/encryption capabilities at the
   desktop, or when two domains employ incompatible encryption schemes
   internally.  In the latter case messages from the originator's domain
   are encrypted (or re-encrypted) using an algorithm, key, and
   certificate which can be decrypted by the recipient(s) or an entity
   in their domain.  This scheme also applies to protecting information
   between a single domain and one of its members when both are
   connected using an untrusted network, e.g., the Internet.

3. Mapping of the Signature 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 [3] 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
   signed or unsigned message that is wrapped in a signature, this
   signature covering both the content and the first (inner) signature,
   if present.

   Signature encapsulation MAY be performed on the inner and/or the
   outer signature of a triple-wrapped message.

   For example, the originator signs a message which is then
   encapsulated with an 'additional attributes' signature.  This is then
   encrypted.  A reviewer then signs this encrypted data, which is then
   encapsulated by a domain signature.

   There is a possibility that some policies will require signatures to
   be added in a specific order.  By only allowing signatures to be
   added by encapsulation it is possible to determine the order in which
   the signatures have been added.

   A DOMSEC defined signature MAY encapsulate a message in one of the
   following ways:

   1) An unsigned message has an empty signature layer added to it
      (i.e., the message is wrapped in a signedData that has a
      signerInfos which contains no elements).  This is to enable
      backward compatibility with S/MIME software that does not have a
      DOMSEC capability.  Since the signerInfos will contain no signers



Dean & Ottaway                Experimental                      [Page 5]

RFC 3183         Domain Security Services using S/MIME      October 2001


      the eContentType, within the EncapsulatedContentInfo, MUST be id-
      data as described in CMS [5].  However, the eContent field will
      contain the unsigned message instead of being left empty as
      suggested in section 5.2 in CMS [5].  This is so that when the
      DOMSEC defined signature is added, as defined in method 2) below,
      the signature will cover the unsigned message.

   2) Signature Encapsulation is used to wrap the original signed
      message with a DOMSEC defined signature.  This is so that the
      DOMSEC defined signature covers the message and all the previously
      added signatures.  Also, it is possible to determine that the
      DOMSEC defined signature was added after the signatures that are
      already there.

3.1 Naming Conventions and Signature Types

   An entity receiving an S/MIME signed message would normally expect
   the signature to be that of the originator of the message.  However,
   the message security services defined in this document require the
   recipient to be able to accept messages signed by other entities
   and/or the originator.  When other entities sign the message the name
   in the certificate will not match the message sender's name.  An
   S/MIME compliant implementation would normally flag a warning if
   there were a mismatch between the name in the certificate and the
   message sender's name.  (This check prevents a number of types of
   masquerade attack.)

   In the case of domain security services, this warning condition
   SHOULD be suppressed under certain circumstances.  These
   circumstances are defined by a naming convention that specifies the
   form that the signers name SHOULD adhere to.  Adherence to this
   naming convention avoids the problems of uncontrolled naming and the
   possible masquerade attacks that this would produce.

   As an assistance to implementation, a signed attribute is defined to
   be included in the S/MIME signature - the 'signature type' attribute.
   On receiving a message containing this attribute, the naming
   convention checks are invoked.

   Implementations conforming to this standard MUST support the naming
   convention for signature generation and verification.
   Implementations conforming to this standard MUST recognize the
   signature type attribute for signature verification.  Implementations
   conforming to this standard MUST support the signature type attribute
   for signature generation.