Internet DRAFT - draft-ymbk-ta-publication
draft-ymbk-ta-publication
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
draft-ymbk-ta-publication-00
Abstract
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
lore.
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
NEEDED].
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
effort.
6. References
[I-D.ietf-dane-protocol]
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
2010.
[RFC5934] Housley, R., Ashmore, S. and C. Wallace, "Trust Anchor
Management Protocol (TAMP)", RFC 5934, August 2010.
[icann-dnssec]
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,
<https://www.iana.org/dnssec/icann-dps.txt>.
[pgp-gen] cets@seas.upenn.edu, "Generating PGP Keys", , <http://
www.seas.upenn.edu/cets/answers/pgp_keys.html>.
[pgp-party]
Brennen, A. V., "The Keysigning Party HOWTO", 2008, <http:
//cryptnet.net/fdp/crypto/keysigning_party/en/
keysigning_party.html>.
Authors' Addresses
Steven M. Bellovin
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, New York 10027
US
Phone: +1 212 939 7149
Email: bellovin@acm.org
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington 98110
US
Email: randy@psg.com
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
US
Email: housley@vigilsec.com
Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
US
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
US
Email: turners@ieca.com
Bellovin, et al. Expires January 31, 2013 [Page 9]
