< draft-osterweil-dane-ent-email-reqs-00.txt   draft-osterweil-dane-ent-email-reqs-01.txt >
Network Working Group E. Osterweil Network Working Group E. Osterweil
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Informational S. Rose Intended status: Informational S. Rose
Expires: February 27, 2015 D. Montgomery Expires: May 29, 2015 D. Montgomery
NIST NIST
August 26, 2014 November 25, 2014
Enterprise Requirements for Secure Email Key Management Enterprise Requirements for Secure Email Key Management
draft-osterweil-dane-ent-email-reqs-00 draft-osterweil-dane-ent-email-reqs-01
Abstract Abstract
Individuals and organizations have expressed a wish to have the Individuals and organizations have expressed a wish to have the
ability to send encrypted and/or digitally signed email end-to-end. 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 One key obstacle to end-to-end email security is the difficulty in
discovering, obtaining, and validating email credentials across discovering, obtaining, and validating email credentials across
administrative domains. This document addresses foreseeable adoption administrative domains. This document addresses foreseeable adoption
obstacles for DANE's cryptographic key management for email in obstacles for encrypted and digitally signed email in enterprises,
enterprises, and outlines requirements. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 27, 2015. This Internet-Draft will expire on May 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Requirements for Both . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements for Both . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Authorities . . . . . . . . . . . . . . . . . 4 3. Requirements for Authorities . . . . . . . . . . . . . . . . 3
4. Requirements for Relying Parties . . . . . . . . . . . . . . . 5 4. Requirements for Relying Parties . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The management of security protections for email constituencies can The management of security protections for email constituencies can
vary by organization and by type of organization. Some organizations vary by organization and by type of organization. Some organizations
can have large sets of users with prescribed controls and policies, 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 some may have a lot of churn in their users, and there are many other
ways in which deployments may differ. ways in which deployments may differ.
As a result of the variability of deployments, aligning key As a result of the variability of deployments, aligning key
management semantics with the behaviors of email users (and their management semantics with the behaviors of email users (and their
organizations) can be an important differentiator when administrators organizations) can be an important differentiator when administrators
choose a solution in which to invest. Designs and cryptographic choose a solution in which to invest. Designs and cryptographic
protocols that do not fit the requirements of users run the risk that protocols that do not fit the requirements of users run the risk that
deployments may falter and/or may not gain traction. deployments may falter and/or may not gain traction.
This document addresses foreseeable requirements for DANE's This document addresses foreseeable requirements for email in
cryptographic key management for email in enterprises, and outlines enterprises, and attempts to outline them. This document generally
requirements. This document generally categorizes requirements as categorizes requirements as being relevant to the domain authorities,
being relevant to the domain authorities, the Relying Parties (RPs), the Relying Parties (RPs), or both. In the following text, "domain
or both. In the following text, "domain authorities" refers to the authorities" refers to the owners of a given domain, which may not
owners of a given domain, which may not necessarily be the operators necessarily be the operators of the authoritative DNS servers for the
of the authoritative DNS servers for the zone(s) that make up the zone(s) that make up the domain.
domain.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Requirements for Both 2. Requirements for Both
REQ-1 Credentials stored can be either entire credential (i.e. the REQ-1 Credentials stored can be either entire credential (i.e. the
key/certificate) or one-way hash of the credential. key/certificate) or one-way hash of the credential.
Intuition: This can reduce the size of DNS responses. 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 REQ-2 The Protocol MUST be able to handle the use of DNS redirection
via CNAME/DNAME and wildcards. via CNAME/DNAME and wildcards.
Intuition: Managing user domain names may be a different Intuition: Managing user domain names may be a different
cardinality than number of S/MIME certificates. For cardinality than number of S/MIME certificates. For example,
example, if the domain's users employ the same certificate if the domain's users employ the same certificate for both
for both digital signature and encryption, a DNAME record digital signature and encryption, a DNAME record enables a
enables a single Resource Record (RR) for each user. single Resource Record (RR) for each user.
3. Requirements for Authorities 3. Requirements for Authorities
REQ-3 The protocol MUST support incremental rollout of DANE-centric REQ-3 The protocol MUST support incremental rollout of DANE-centric
cryptographic protections, whereby not all users in an cryptographic protections, whereby not all users in an enterprise
enterprise may be cut over to a DANE solution at the same may be cut over to a DANE solution at the same time and MUST be
time and MUST be backwards compatible backwards compatible
Intuition: Enterprise operations may wish be able to Intuition: Enterprise operations may wish be able to enroll
enroll subsets of all of their users in a DANE subsets of all of their users in a DANE architecture without
architecture without disrupting existing email disrupting existing email cryptographic services for all
cryptographic services for all users. users.
REQ-4 The protocol MUST have the ability to either scope a Use Case: This requirement is necessary for when two
Certification Authority (CA) or local Trust Anchor (TA) in enterprises merge and there will be a migration period as one
use for a given domain. 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.
Intuition: Enterprises may issue certificates from a TA REQ-4 The protocol MUST have the ability to either scope a
and prefer to authorize that certificate in DNS (instead Certification Authority (CA) or local Trust Anchor (TA) in use
of End Entity certificates for every user). for a given domain.
REQ-5 The protocol SHOULD have the ability to signal that a Intuition: Enterprises may issue certificates from a local TA
particular key/certificate is no longer to be trusted or is or global CA and prefer to authorize that certificate in DNS
revoked. (instead of End Entity certificates for every user).
Intuition: Allows default TA authorizations to be REQ-5 The protocol SHOULD have the ability to signal that a
overridden by revocation. 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.
REQ-6 The protocol SHOULD have the ability to signal that a Intuition: Allows an enterprise to associate key material with
particular email address is not (or no longer) a valid sender specific functionality.
for the given domain.
Intuition: Allows for authenticated denial of existence Use Case: An enterprise may have a general office "inbox" that
of a network identity. 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-7 The protocol MUST allow for separate management, publication, REQ-6 The protocol MUST allow for separate management, publication,
and learning of keys that are used for signing versus and learning of keys that are used for signing versus encryption.
encryption.
Intuition: Separating, scaling, delegating, and general Intuition: Separating, scaling, delegating, and general
management for different keys in different ways and in management for different keys in different ways and in
different branches of the DNS allows administrators to different branches of the DNS allows administrators to manage
manage different material in different systems if needed. different material in different systems if needed. This also
allows for an enterprise to associate credentials/key material
with specific email functions.
REQ-8 The protocol MUST have the ability to delegate authority for Use Case: An enterprise may issue separate encrypting and
user names. 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.
Intuition: Some enterprises may wish to use a service REQ-7 The protocol MUST have the ability to delegate authority for
provider. user names.
REQ-9 The protocol MUST have the ability to manage keys in Intuition: Some enterprises may wish to use a service
different ways for different user names. provider.
Intuition: Not all members of a medium/large enterprise REQ-8 The protocol MUST have the ability to manage keys in different
may be migrated onto a DANE system overnight, and must ways for different user names.
operate alongside current email key management. This
could include users that use a different email security
protocol.
REQ-10 The protocol MUST have the ability to signal that a given Intuition: Not all members of a medium/large enterprise may be
network identity (or entire zone) only sends digitally signed migrated onto a DANE system overnight, and must operate
messages. alongside current email key management. This could include
users that use a different email security protocol.
Intuition: A domain owner may wish to signal that their Use Case: This is useful when one enterprise acquires a new
email security policy is to sign all outgoing message so subsidiary or two enterprises merge. Until the two email
a receiver can infer an unsigned message is likely a systems can be reconciled, both systems must be able to co-
phishing attempt. exist and managed by the same (newly joined) enterprise.
4. Requirements for Relying Parties 4. Requirements for Relying Parties
REQ-11 Key material for DANE-enabled email users MUST be verifiably REQ-9 Key material for DANE-enabled email users MUST be verifiably
discoverable and learnable using just an email address. discoverable and learnable using just an email address.
Intuition: Email addresses are all the RP has, but may Intuition: Email addresses are all the RP has, but may point
point to external management systems. to external management systems.
REQ-12 The protocol SHOULD have the ability to provide opportunistic REQ-10 The protocol SHOULD have the ability to provide opportunistic
encryption at the user's discretion. encryption at the user's discretion.
Intuition: Compliance controls (for example) may mandate Intuition: Compliance controls (for example) may mandate the
the encryption of all messages under certain encryption of all messages under certain circumstances.
circumstances.
REQ-13 The protocol MUST support default verification configurations REQ-11 The protocol MUST support default verification configurations
(such as enterprise TA or stapling) with user-specific (such as enterprise TA or stapling) with user-specific overrides.
overrides. Overrides MUST include specifying specific Overrides MUST include specifying specific cryptographic
cryptographic information for specific users and disallowing information for specific users and disallowing users (either
users (either specific cryptographic or entirely). specific cryptographic or entirely).
REQ-14 The protocol MUST be resistant to downgrade attacks targeting REQ-12 The protocol MUST be resistant to downgrade attacks targeting
the DNS response. the DNS response.
Intuition: If DNSSEC is stripped, the protocol MUST alert Intuition: If DNSSEC is stripped, the protocol MUST alert the
the user or refuse to send an unencrypted email message. user or refuse to send an unencrypted email message.
REQ-15 The protocol MUST provide separate semantics to discover REQ-13 The protocol MUST provide separate semantics to discover
certificates that are used for specific purposes. 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: keep DNS response size minimal. Intuition: Not all certificates for a user may be needed (or
considered valid by policy) for all circumstances. Fetching
them separately can be a management, a scaling, or even a
security concern.
REQ-16 Encryption keys MUST be discoverable separately from 5. Other Requirements
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 The requirements below are enterprise level email requirements that
for all circumstances. Fetching them separately can be a may not fit a specific role, or fit multiple roles. Some of these
management, a scaling, or even a security concern. 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.
5. Acknowledgements REQ-14 There MUST be the ability to signal domain wide policies with
respect to secure email functions.
TBD Intuition: An enterprise may wish to publish its email
security policy so clients can determine the security status
of an email message.
6. IANA Considerations 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 This document only discusses requirements for publishing and querying
for security credentials used in email. No new IANA actions are for security credentials used in email. No new IANA actions are
required in this document, but specifications addressing these required in this document, but specifications addressing these
requirements may have IANA required actions. requirements may have IANA required actions.
This section should be removed in final publication. This section should be removed in final publication.
7. Security Considerations 8. Security Considerations
The motivation for this document is to outline requirements needed to The motivation for this document is to outline requirements needed to
facilitate the secure publication and learning of cryptographic keys facilitate the secure publication and learning of cryptographic keys
for email, using DANE semantics. There are numerous documents that for email, using DANE semantics. There are numerous documents that
more generally address security considerations for email. By more generally address security considerations for email. By
contrast, this document is not proposing a protocol or any facilities contrast, this document is not proposing a protocol or any facilities
that need to be secured. Instead, these requirements are intended to that need to be secured. Instead, these requirements are intended to
inform security considerations in follow-on works. inform security considerations in follow-on works.
8. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses Authors' Addresses
Eric Osterweil Eric Osterweil
Verisign Labs Verisign Labs
Reston, VA Reston, VA
US US
Email:
Scott Rose Scott Rose
NIST NIST
100 Bureau Dr. 100 Bureau Dr.
Gaithersburg, MD 20899 Gaithersburg, MD 20899
US US
Email: scottr@nist.gov Email: scottr@nist.gov
Doug Montgomery Doug Montgomery
NIST NIST
 End of changes. 45 change blocks. 
117 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/