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

Versions: 00

Network Working Group                                        S. Bellovin
Internet-Draft                                       Columbia University
Intended status: Informational                                   R. Bush
Expires: January 31, 2013                      Internet Initiative Japan
                                                              R. Housley
                                                     Vigil Security, LLC
                                                                 S. Kent
                                                        BBN Technologies
                                                               S. Turner
                                                              IECA, Inc.
                                                             August 2012

                    Trust Anchor Publication Advice


   Many Internet protocols and services rely on credentials which use
   asymmetric keys.  Many of these are hierarchic structures having
   certification authorities (CAs) that act as trust anchors (TAs).
   There is little general guidance on procedures for how these trust
   anchors can be distributed or otherwise published with prudence.  To
   quote a well known security expert, "It's a matter of oral tradition
   in security circles."  This document attempts to capture some of that

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 January 31, 2013.

Copyright Notice

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

Bellovin, et al.        Expires January 31, 2013                [Page 1]

Internet-Draft      Trust Anchor Publication Advice          August 2012

   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.

   This document may not be modified, and derivative works of it may not
   be created, and it may not be published except as an Internet-Draft.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Trust in the Conveyance  . . . . . . . . . . . . . . . . . . .  3
     2.1.  TLS / https  . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  In Packaged Software . . . . . . . . . . . . . . . . . . .  3
   3.  Trust in the Conveyor  . . . . . . . . . . . . . . . . . . . .  4
     3.1.  PGP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Physical Proximity . . . . . . . . . . . . . . . . . . . .  4
   4.  Advice yet to be Organized . . . . . . . . . . . . . . . . . .  5
     4.1.  Public Transport Plus Verification . . . . . . . . . . . .  5
     4.2.  TAMP . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.3.  SSH  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.4.  DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.5.  RPKI . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       4.5.1.  Hardware Security Module . . . . . . . . . . . . . . .  6
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8

1.  Introduction

   Many Internet protocols and services make use of asymmetric keys
   distributed via certificates (e.g., X.509 or OPGP) or analogous
   formats (e.g., DNSSEC records).  Many of these certificates are
   organized into hierarchic structures having one or more trust anchors
   (TAs).  In any hierarchical structure, the choice of root is
   important.  In PKIs, it is quite critical, since an untrustworthy or
   incompentent TA can issue credentials to imposters, vitiating the
   security guarantees for the entire structure.  This in turn implies
   that anyone relying on a PKI must have accurate knowledge of the root
   of the tree.  However, there is little general guidance on procedures
   for how these trust anchors can be distributed in a fashion that
   ensures their integrity and authenticity.  To quote a well known
   security expert, "It's a matter of oral tradition in security
   circles."  This document attempts to capture some of that lore.

   In particular, the issue of publication of root TA(s) for the

Bellovin, et al.        Expires January 31, 2013                [Page 2]

Internet-Draft      Trust Anchor Publication Advice          August 2012

   Resource Public Key Infrastructure (RPKI) incited this document.  We
   recommend it be handled similarly to the DNSSEC root keys, see
   Section 4.5.

   We do not address the complex matter of generating key pairs for
   trust anchors.  They range from exceedingly formal and complex, e.g.
   [icann-dnssec] for DNSSEC, to the exceedingly informal, e.g.  [pgp-
   gen].  We assume the public key material and associated date have
   been created, and address the problem of distribution and/or
   publication of the TA materiel in a secure fashion.

   The distribution/publication problem is how to give relying parties
   (RPs) who will use the TA confidence that the trust anchor is
   authentic.  In this context authentic means that the public key and
   associated data has not been modified in an unauthorized fashion, and
   the data associated with the TA accurately identifies the principle
   that it represents.  There is usually no external trust environment
   which is the same as that of the TA; after all this is a TA.  So the
   problem often devolves to issues of identity and trust in the
   conveyance or conveyor of the TA.  This is often referred to as 'Out
   Of Band' (OOB) verification of the TA.

   Fundamentally, one can trust information if it came via a trusted
   path and/or was delivered by a trustworthy source.  We refer to these
   as "conveyance" and "conveyor".  In addition, one can build up trust
   by suitable conbination of information from many different sources;
   this gives rise to a variety of hybrid schemes.

   Note carefully that there is no one solution for all situations.  The
   proper answer depends on the operational needs, and often on the
   particular hardware and software involved.

2.  Trust in the Conveyance

2.1.  TLS / https

   For some applications, an HTTP GET authenticated with TLS [RFC5785]
   may be sufficient.  Given the number of certificates in the normal
   browser, many consider this imprudent and suggest that the user
   should ensure that the certification path validates to a particular
   TA that they trust for introducing other TAs.  This may be beyond the
   average user

   Use of further authenticity such as DANE, see [I-D.ietf-dane-
   protocol] is another approach.

   Microsoft distributes new browser TAs in the same manner as software
   updates, which rely on certificate path validation.  Thus the entropy
   of the browser's certificate store can only increase.

Bellovin, et al.        Expires January 31, 2013                [Page 3]

Internet-Draft      Trust Anchor Publication Advice          August 2012

2.2.  In Packaged Software

   Embedding a TA in software is a common method of distribution in many
   contexts.  In an enterprise context this may suffice, e.g., if
   software distribution is tightly controlled by the enterprise.  Most
   operating systems and browsers use this method, as the vendors of
   these products are dealing with a set of RPs that is large,
   geographically dispersed, and unknown to the TA management.  But,
   this approach is not without risks.

   For example, an RP who receives an OS copy on a DVD in conjunction
   with the purchase of a laptop is probably confident that the TA(s)
   embedded in that OS have not been modified and that the vendor has
   vouched for the accuracy of the TA material.  In contrast, if a copy
   of a browser is downloaded via the Internet, the set of TAs embedded
   in it may or may not be what the browser vendor intended.  Attacks on
   the DNS (absent DNSSEC), or on the server from which the browser
   image was acquired could have resulted in bogus TA material.

3.  Trust in the Conveyor

   For applications where the credential is that of an identity,
   authentication of the conveyor might be appropriate.

3.1.  PGP

   Pretty Good Privacy (PGP) [RFC4880] is based on personal identity,
   and "Uses a combination of strong public-key and symmetric
   cryptography to provide security services for electronic
   communications and data storage."

   PGP itself actually has no root of trust, but rather is a web of
   trust sans root.  It would not be of extreme interest here except it
   has some of the few well-documented rituals of authenticating
   exchange of credentials involving fingerprints (hashes) of keys [pgp-
   party].  There is also a system of coordinated key servers [REF

3.2.  Physical Proximity

   In some environments it is possible to provide good physical,
   personnel, and procedural security for TA distribution.  This is
   especially easy if the set of RPs is small, geographically local, and
   known to the TA management.

   For example, in an organization an employee might receive a smart

Bellovin, et al.        Expires January 31, 2013                [Page 4]

Internet-Draft      Trust Anchor Publication Advice          August 2012

   card loaded with a personal certificate and private key, and the TA
   for the organization.  If the organization distributes this card to
   the employee in person, e.g., as a side effect of employee (or
   student) orientation, the employee can probably rely on the
   authenticity of the TA.  The DoD Common Access Card (CAC) delivers TA
   material in this fashion, through a network of verification officers
   and associated work stations.

4.  Advice yet to be Organized

4.1.  Public Transport Plus Verification

   Less secure TA distribution mechanism are often employed when the RP
   population is very large, or geographically dispersed, or not known
   by TA management a priori.

   For example, a smart card loaded with a TA might be sent to an RP via
   the postal system.  The RP, upon receipt if the card, can't be
   absolutely sure that the TA represents the entity identified on the
   card or in accompanying documentation.  If registered mail is
   employed the likelihood of tampering en route might be considered
   very small, but the identity of the sender still would not be
   assured.  Thus some means of independently verifying that aspect of
   TA security would still be needed.  Depending on the context, such
   verification might be easy, or very difficult.  For example, if the
   card is designed to enable access to a bank account, the RP might try
   to use it and see of the bank balances reported match what the RP
   expects.  If the RP need not provide a password or other secret value
   to gain access to the account this is a reasonable way for the RP to
   verify that the card "works" and that it probably was issued by their
   bank, and thus the TA on the card is likely associated with the bank.

4.2.  TAMP

   The Trust Anchor Management Protocol (TAMP [RFC4255]) is a transport
   independent protocol for the management of trust anchors and
   community identifiers stored in a trust anchor store.

   The core concept is not complex.  Trust one signer to be the one to
   introduce other public keys as trust anchors, and those may have
   constraints (one for signed software, one for TLS, only for IPsec, or
   whatever).  Complexity comes if you want to allow that one signer to
   pass the privilege to another signer.

   More needed here.

4.3.  SSH

Bellovin, et al.        Expires January 31, 2013                [Page 5]

Internet-Draft      Trust Anchor Publication Advice          August 2012

   Secure Shell (SSH [RFC4251]) authenticates [RFC4252] over the SSH
   Transport Layer Protocol, [RFC4253].  The server may authenticate the
   user's identity by a number of means, password, asymmetric key,
   challenge response, etc.  The user authenticates the server by an
   asymmetric key.  That key may have been transmitted out of band, e.g.
   using DNSSEC [RFC4255] or some other credible (to the user) means.
   SSH also offers a 'trust the transport' key conveyance, with manual
   hash verification, for the first connection to the server.

4.4.  DNSSEC

   DNSSEC relies on a diverse public distribution mechanism to
   distribute the TA material for the DNS root, see [icann-dnssec].  The
   DNS root TA material is available in multiple formats (e.g., S/MIME,
   PEM certificate request, XML, and OPGP), and from multiple sites
   (e.g., iana.org, ???). An RP that acquires the DNS TA material from
   multiple sources can verify that the public key values it acquires
   all match.  An adversary would have to spoof replies from all of the
   queried sources to fool an RP.  Moreover, if the RP received bogus
   DNS root TA data, the RP would not be able to validate legitimate
   DNSSEC records.  Thus an adversary would have to insert itself in the
   RPs (DNESEC) communication path on a persistent basis to avoid
   detection.  This is perceived as a difficult task and thus the DNSSEC
   mechanism for distributing TA material is viewed as adequate.

4.5.  RPKI

   Trust Anchor Locators (TALs) are used to distribute TAs in the RPKI.
   A TAL is a URI and a self-signed X.509 certificate.  There is no plan
   to publish TALs in multiple formats, as the TAL format itself is
   quite simple.

   It is anticipated that the root TAL, like the DNSSEC root zone TA
   material, will be published by the IANA similarly to the DNSSEC root
   keys, see [icann-dnssec].  Until the IANA signs the root TAL for the
   RPKI, it is anticipated that the next level in the hierarchy, the
   RIRs, will each publish a TAL using analogous means.

   Unlike the certificates in browsers, the IANA and RIRs are a small
   and static set of TAL publishers.  It should be easier to distribute
   them in a more credible fashion.

4.5.1.  Hardware Security Module

Bellovin, et al.        Expires January 31, 2013                [Page 6]

Internet-Draft      Trust Anchor Publication Advice          August 2012

   If a TA is used only offline, and one employs a good HSM (e.g., FIPS
   140 level 4) then it is very, very unlikely that the private key will
   be compromised and not detected.  IANA and the RIRs can afford to
   protect their keys this way, so one should rarely have to change
   these TAs.  Thus the principle problem is how an RP can become
   confident that the TAL data it acquires is legitimate.  The same
   principle applies here as for DNSSEC. Each RP should acquire TALs
   from multiple locations and verify that the data are consistent.
   Each RP will be downloading and verifying data from multiple RPKI
   repositories.  If the TAL(s) acquired by an RP are not accurate, then
   legitimate RPKI data acquired from repositories will not validate.
   Thus an adversary would have to insert itself in the RPs RPKI
   repository communication path on a persistent basis to avoid
   detection.  This is perceived as a difficult task and thus the RPKI
   mechanism for distributing TA material is viewed as adequate.

5.  Acknowledgements

   The authors would like to thank Shane Amante for inciting this

6.  References

              Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", Internet-Draft draft-ietf-dane-
              protocol-23, June 2012.

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

   [RFC4252]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, January 2006.

   [RFC4253]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

   [RFC4255]  Schlyter, J. and W. Griffin, "Using DNS to Securely
              Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
              January 2006.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D. and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785, April

   [RFC5934]  Housley, R., Ashmore, S. and C. Wallace, "Trust Anchor
              Management Protocol (TAMP)", RFC 5934, August 2010.


Bellovin, et al.        Expires January 31, 2013                [Page 7]

Internet-Draft      Trust Anchor Publication Advice          August 2012

              Ljunggren, F., Okubo, T., Lamb, R., Schlyter, J., "DNSSEC
              Practice Statement for the Root Zone KSK Operator", 2010,

   [pgp-gen]  cets@seas.upenn.edu, "Generating PGP Keys", , <http://

              Brennen, A. V., "The Keysigning Party HOWTO", 2008, <http:

Authors' Addresses

   Steven M. Bellovin
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, New York 10027

   Phone: +1 212 939 7149
   Email: bellovin@acm.org

   Randy Bush
   Internet Initiative Japan
   5147 Crystal Springs
   Bainbridge Island, Washington 98110

   Email: randy@psg.com

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170

   Email: housley@vigilsec.com

   Stephen Kent
   BBN Technologies
   10 Moulton St.
   Cambridge, MA 02138

   Email: kent@bbn.com

Bellovin, et al.        Expires January 31, 2013                [Page 8]

Internet-Draft      Trust Anchor Publication Advice          August 2012

   Sean Turner
   IECA, Inc.
   3057 Nutley Street, Suite 106
   Fairfax, Virginia 22031

   Email: turners@ieca.com

Bellovin, et al.        Expires January 31, 2013                [Page 9]

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