Network Working Group R. Housley
Internet Draft Vigil Security
Intended Status: Standards Track T. Polk
Expires: April 18, 2011 NIST
S. Turner
IECA
October 18, 2010
DNSSEC-centric PKI
draft-turner-dnssec-centric-pki-00.txt
Abstract
This draft is input to the KIDNS discussion. The procedures defined
herein provide a general Public Key Infrastructure (PKI) mechanism
that leverages DNSSEC. This is compatible with RFC 5280.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Housley, et al. Expires April 18, 2011 [Page 1]
Internet-Draft DNSSEC-centric PKI October 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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.
1. Introduction
This draft is not to be construed as direction from I*. It is the
output of an actual "interim" Bar BoF held at conference room H
located in Fairfax, Virginia after the IAB/IESG OAM workshop on 2010-
10-13.
Certification Authorities (CAs) take great care to ensure that the
private key holder is associated with the domain name contained in
the certificate. DNSSEC [RFC4033][RFC4034][RFC4035] offers an
opportunity to eliminate complicated off-line processes. This
relationship can be easily demonstrated by having the zone
administrator for the domain name in question post the certificate
[RFC5280] in the DNS and digitally sign the resulting zone.
With the following hierarchy:
+-------------+
| example.com |
+-------------+
/ \
+-----------------+ +-----------------+
| foo.example.com | | bar.example.com |
+-----------------+ +-----------------+
Administrators of foo.example.com and bar.example.com can choose to
either trust the root (i.e., the signer of example.com) or another
entity that they have included in the DNS entry they control.
1.1. Terminology
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 [RFC2119].
Housley, et al. Expires April 18, 2011 [Page 2]
Internet-Draft DNSSEC-centric PKI October 2010
2. Procedures
Perform a DNSSEC retrieval on the domain name, verifying the chain of
trust to a locally configured DNSSEC trust anchor.
If a Certification Authority (CA) certificate is returned, rather
than an end-entity (EE) certificate, construct a certification path.
It is a matter of local policy whether the CA certificate is accepted
as a trust anchor (TA) directly, or MUST chain to a currently
configured TA. To differentiate CA certificates from EE
certificates, the CA certificate MUST include basic constraints
extension and the cA boolean MUST be set to true [RFC5280].
If the application provides an EE certificate (e.g., Transport Layer
Security (TLS)) issued by this CA certificate, this means only
obtaining a Certificate Revocation List (CRL). If no EE certificate
is available (e.g., Secure Multipurpose Internet Mail Extensions
(S/MIME)), then follow the Subject Information Access (SIA) extension
to obtain other certificates. SHOULD be no more than one hop to the
EE certificate.
If an EE certificate is returned, the certificate is intended for
direct use with some application. As above, it is a matter of local
policy whether this EE certificate is accepted as trusted directly,
or MUST chain to a currently configured TA.
Verify that the dNSName in the certificate's subject alternative name
extension [RFC5280] is consistent with the expected host name.
If the certificate contains a critical External Key Usage (EKU) or
Key Usage (KU) extension [RFC5280], verify that the key usages are
consistent with this application.
3. Examples
For S/MIME [RFC5750][RFC5751], the originator wants to send to a
signed and encrypted email. (For signatures, the originator does not
need the recipient's certificate.) To encrypt the message, the
originator needs the recipient's key agreement or key transport
certificate. To obtain the recipients certificate, the originator
composes the email, selects sign and encrypt, and hit send. The mail
client/DNSSEC client reviews the local store and determines that no
certificate is available. The mail client then queries the DNS to
determine whether certificates are available for that domain.
If a CERT resource record (RR) [RFC4398] is available, the mail
client examines the certificate to determine if it is a CA
certificate or end certificate. For domains with multiple users, the
Housley, et al. Expires April 18, 2011 [Page 3]
Internet-Draft DNSSEC-centric PKI October 2010
certificate would be a CA certificate and would include a SIA
extension [RFC5280]. The mail client follows the URL in an access
description that asserts id-ad-caRepository, using the protocol
implied by the accessLocation URL. For example, the mail client can
query the repository for certificates issued to john.doe@example.com.
If an appropriate certificate is available (and validates according
to local policy), the client can encrypt the message. The originator
includes their own certificates in the message, so this process is
not required to validate or decrypt the original message or for a
response.
For TLS [RFC5246], when the TLS looks up the IP address in the DNS it
can also request the CERT RR. If the certificate that is provided in
the TLS handshake matches the one retrieved from DNSSEC, then the
client can accept it as a trusted certificate for that site, provided
local policy allows this. If the CA certificate is returned in the
TLS handshake, the TLS client can verify that the TLS server
certificate was issued under that CA.
For IPsec [RFC4301], the model is similar to TLS.
4. Security Considerations
Like [RFC5280], trust and revocation configuration decisions will
affect the security of the system.
When CA certificates are returned, the proposed solution assumes that
the entire CA certificate is returned. For EE certificates, a hash
could be returned instead of the entire certificate.
Need to say something caching versus revocation for optimization.
5. IANA Considerations
None
6. Acknowledgements
We'd like to thank the lovely Carly for bringing the libations during
the "interim" Bar BoF. In addition, we'd like to thank Yuengling,
Anheuser-Busch, and Samuel Adams for all of their efforts.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Housley, et al. Expires April 18, 2011 [Page 4]
Internet-Draft DNSSEC-centric PKI October 2010
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[RFC4301] Kent, S., and K. Seo, " Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", RFC 4398, March 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. Housley,
R., and W. Polk, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC 5280,
May 2008.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750,
January 2010.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC
5751, January 2010.
Housley, et al. Expires April 18, 2011 [Page 5]
Internet-Draft DNSSEC-centric PKI October 2010
Authors' Addresses
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Tim Polk
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD 20899-8930
USA
Email: tim.polk@nist.gov
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
EMail: turners@ieca.com
Housley, et al. Expires April 18, 2011 [Page 6]