[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                       E. Osterweil
Internet-Draft                                             Verisign Labs
Intended status: Informational                                   S. Rose
Expires: May 29, 2015                                      D. Montgomery
                                                                    NIST
                                                       November 25, 2014


        Enterprise Requirements for Secure Email Key Management
                 draft-osterweil-dane-ent-email-reqs-01

Abstract

   Individuals and organizations have expressed a wish to have the
   ability to send encrypted and/or digitally signed email end-to-end.
   One key obstacle to end-to-end email security is the difficulty in
   discovering, obtaining, and validating email credentials across
   administrative domains.  This document addresses foreseeable adoption
   obstacles for encrypted and digitally signed email in enterprises,
   and outlines requirements.  Some of the requirements below are not
   DANE specific, and all may not be solvable with a DANE solution, but
   are included for completeness and as an attempt to give a holistic
   view of enterprise email security requirements.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on May 29, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Osterweil, et al.         Expires May 29, 2015                  [Page 1]


Internet-Draft  Ent Reqs for Secure Email Key Management   November 2014


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Requirements for Both . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements for Authorities  . . . . . . . . . . . . . . . .   3
   4.  Requirements for Relying Parties  . . . . . . . . . . . . . .   5
   5.  Other Requirements  . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The management of security protections for email constituencies can
   vary by organization and by type of organization.  Some organizations
   can have large sets of users with prescribed controls and policies,
   some may have a lot of churn in their users, and there are many other
   ways in which deployments may differ.

   As a result of the variability of deployments, aligning key
   management semantics with the behaviors of email users (and their
   organizations) can be an important differentiator when administrators
   choose a solution in which to invest.  Designs and cryptographic
   protocols that do not fit the requirements of users run the risk that
   deployments may falter and/or may not gain traction.

   This document addresses foreseeable requirements for email in
   enterprises, and attempts to outline them.  This document generally
   categorizes requirements as being relevant to the domain authorities,
   the Relying Parties (RPs), or both.  In the following text, "domain
   authorities" refers to the owners of a given domain, which may not
   necessarily be the operators of the authoritative DNS servers for the
   zone(s) that make up the domain.







Osterweil, et al.         Expires May 29, 2015                  [Page 2]


Internet-Draft  Ent Reqs for Secure Email Key Management   November 2014


1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

2.  Requirements for Both

   REQ-1  Credentials stored can be either entire credential (i.e. the
       key/certificate) or one-way hash of the credential.

          Intuition and Use Case: This can reduce the size of DNS
          responses.  Some enterprises make use of large certificates or
          large cryptograpic keys.

          Use Case: Some enterprises make use of large certificates or
          large cryptograpic keys.

   REQ-2  The Protocol MUST be able to handle the use of DNS redirection
       via CNAME/DNAME and wildcards.

          Intuition: Managing user domain names may be a different
          cardinality than number of S/MIME certificates.  For example,
          if the domain's users employ the same certificate for both
          digital signature and encryption, a DNAME record enables a
          single Resource Record (RR) for each user.

3.  Requirements for Authorities

   REQ-3  The protocol MUST support incremental rollout of DANE-centric
       cryptographic protections, whereby not all users in an enterprise
       may be cut over to a DANE solution at the same time and MUST be
       backwards compatible

          Intuition: Enterprise operations may wish be able to enroll
          subsets of all of their users in a DANE architecture without
          disrupting existing email cryptographic services for all
          users.

          Use Case: This requirement is necessary for when two
          enterprises merge and there will be a migration period as one
          unit transitions its users' credentials to a DANE based
          system.  Another example is in the inital deployment of a DANE
          solution for email, which will likely happen over an extended
          period of time in large enterprises.






Osterweil, et al.         Expires May 29, 2015                  [Page 3]


Internet-Draft  Ent Reqs for Secure Email Key Management   November 2014


   REQ-4  The protocol MUST have the ability to either scope a
       Certification Authority (CA) or local Trust Anchor (TA) in use
       for a given domain.

          Intuition: Enterprises may issue certificates from a local TA
          or global CA and prefer to authorize that certificate in DNS
          (instead of End Entity certificates for every user).

   REQ-5  The protocol SHOULD have the ability to signal that a
       particular security artifact (key or certificate) MUST NOT be
       accepted for a particular function (e.g. encryption or validating
       digital signatures).  The credential is still considered valid
       for some uses, but MUST be rejected for the given function.  Note
       that this requirement would likely rely on the use of the next
       requirement below.

          Intuition: Allows an enterprise to associate key material with
          specific functionality.

          Use Case: An enterprise may have a general office "inbox" that
          has an associated certificate so customers can send encrypted
          email.  However, the same inbox address would never send
          email, so the enterprise would want to signal that the same
          certificate will never be used to send digitally signed email
          and to reject any digital signature associated with the
          certificate.

   REQ-6  The protocol MUST allow for separate management, publication,
       and learning of keys that are used for signing versus encryption.

          Intuition: Separating, scaling, delegating, and general
          management for different keys in different ways and in
          different branches of the DNS allows administrators to manage
          different material in different systems if needed.  This also
          allows for an enterprise to associate credentials/key material
          with specific email functions.

          Use Case: An enterprise may issue separate encrypting and
          signature certificates to each member, and wish to denote
          their usage in the DNS so external email clients can obtain
          and use the correct certificate for a given usage.

   REQ-7  The protocol MUST have the ability to delegate authority for
       user names.

          Intuition: Some enterprises may wish to use a service
          provider.




Osterweil, et al.         Expires May 29, 2015                  [Page 4]


Internet-Draft  Ent Reqs for Secure Email Key Management   November 2014


   REQ-8  The protocol MUST have the ability to manage keys in different
       ways for different user names.

          Intuition: Not all members of a medium/large enterprise may be
          migrated onto a DANE system overnight, and must operate
          alongside current email key management.  This could include
          users that use a different email security protocol.

          Use Case: This is useful when one enterprise acquires a new
          subsidiary or two enterprises merge.  Until the two email
          systems can be reconciled, both systems must be able to co-
          exist and managed by the same (newly joined) enterprise.

4.  Requirements for Relying Parties

   REQ-9  Key material for DANE-enabled email users MUST be verifiably
       discoverable and learnable using just an email address.

          Intuition: Email addresses are all the RP has, but may point
          to external management systems.

   REQ-10 The protocol SHOULD have the ability to provide opportunistic
       encryption at the user's discretion.

          Intuition: Compliance controls (for example) may mandate the
          encryption of all messages under certain circumstances.

   REQ-11 The protocol MUST support default verification configurations
       (such as enterprise TA or stapling) with user-specific overrides.
       Overrides MUST include specifying specific cryptographic
       information for specific users and disallowing users (either
       specific cryptographic or entirely).

   REQ-12 The protocol MUST be resistant to downgrade attacks targeting
       the DNS response.

          Intuition: If DNSSEC is stripped, the protocol MUST alert the
          user or refuse to send an unencrypted email message.

   REQ-13 The protocol MUST provide separate semantics to discover
       certificates that are used for specific purposes.  For example,
       encryption keys MUST be discoverable separately from signature
       keys.  Possible means includes (but not limited to) naming
       conventions, sub-typing or unique RR types for each use

          Intuition: Not all certificates for a user may be needed (or
          considered valid by policy) for all circumstances.  Fetching




Osterweil, et al.         Expires May 29, 2015                  [Page 5]


Internet-Draft  Ent Reqs for Secure Email Key Management   November 2014


          them separately can be a management, a scaling, or even a
          security concern.

5.  Other Requirements

   The requirements below are enterprise level email requirements that
   may not fit a specific role, or fit multiple roles.  Some of these
   requirements may not be solvable via a DANE solution and may be
   better suited using another method.  They are included here merely to
   document them.

   REQ-14 There MUST be the ability to signal domain wide policies with
       respect to secure email functions.

          Intuition: An enterprise may wish to publish its email
          security policy so clients can determine the security status
          of an email message.

          Use Case: An enterprise has a policy that all email messages
          must be digitally signed.  The enterpise states its policy in
          the DNS so that external recipients can determine if unsigned
          messages represent a security risk or potential phishing
          attempt.

   REQ-15 The protocol SHOULD have the ability to signal that a
       particular email address is not (or no longer) a valid sender for
       the given domain.

          Intuition: Allows for authenticated denial of existence of a
          network identity.

6.  Acknowledgements

   The authors of this draft would like to acknowledge the input,
   discussions and contributions from the members of the IETF DANE
   Working Group mailing list.

7.  IANA Considerations

   This document only discusses requirements for publishing and querying
   for security credentials used in email.  No new IANA actions are
   required in this document, but specifications addressing these
   requirements may have IANA required actions.

   This section should be removed in final publication.






Osterweil, et al.         Expires May 29, 2015                  [Page 6]


Internet-Draft  Ent Reqs for Secure Email Key Management   November 2014


8.  Security Considerations

   The motivation for this document is to outline requirements needed to
   facilitate the secure publication and learning of cryptographic keys
   for email, using DANE semantics.  There are numerous documents that
   more generally address security considerations for email.  By
   contrast, this document is not proposing a protocol or any facilities
   that need to be secured.  Instead, these requirements are intended to
   inform security considerations in follow-on works.

9.  Normative References

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

Authors' Addresses

   Eric Osterweil
   Verisign Labs
   Reston, VA
   US


   Scott Rose
   NIST
   100 Bureau Dr.
   Gaithersburg, MD  20899
   US

   Email: scottr@nist.gov


   Doug Montgomery
   NIST
   100 Bureau Dr.
   Gaithersburg, MD  20899
   US

   Email: dougm@nist.gov












Osterweil, et al.         Expires May 29, 2015                  [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/