[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/