Network Working Group R. Reddy Internet Draft National Security Agency Intended Status: Informational C. Wallace Cygnacom Solutions Expires: November 25, 2007 May 25, 2007 Trust Anchor Management Problem Statement draft-wallace-ta-mgmt-problem-statement-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 November 25, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides a problem statement for the Trust Anchor Management Birds of a Feather (BOF). Trust anchors are trusted public keys, and associated information, that are used to verify digital signatures on a variety of objects including public key certificates, certificate management protocol exchanges and firmware Turner Expires November 25, 2007 [Page 1] Internet-Draft Trust Anchor Management Problem Statement May 2007 packages. At present, there exists no standards-based protocol for distributing and managing trust anchors. This document describes some of the problems associated with the lack of a standards-based trust anchor management mechanism as well as problems that must be addressed by such a mechanism. Conventions used in this document 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]. Table of Contents 1. Introduction...................................................2 2. Problem Statement..............................................3 3. Functional Properties..........................................4 4. Using Cryptographic Message Syntax.............................5 5. Security Considerations........................................6 6. IANA Considerations............................................8 7. References.....................................................8 1. Introduction Digital signatures are used in many applications. One particular usage is the verification of signatures on firmware packages loaded into hardware modules, such as cryptographic modules, cable boxes, routers, etc. Since such devices are often managed remotely, the devices need to be able to authenticate the source of management interactions. Digital signatures are used to provide integrity and authentication for the delivery of software, e-mail, cryptographic keys, configuration updates, and other transactions. The public key used to verify the digital signature must be trusted. Trust in the public key may be explicit or established by building and validating a certification path from the public key to an explicitly trusted public key. An explicitly trusted public key is known as a trust anchor (TA). In all cases, a device must use a trust anchor to validate digital signatures, either directly by verifying the signature or indirectly by validating a certification path. Trust anchors are also used wherever PKI is used. All devices that rely upon PKI must have some means of managing one or more sets of trust anchors. Often, these means are application-specific and rely upon out-of-band means to establish and maintain trustworthiness. Given the fact that authentication and authorization are tightly bound; trust anchors often play a significant role in authorization decisions. Reddy & Wallace Expires November 25, 2007 [Page 2] Internet-Draft Trust Anchor Management Problem Statement May 2007 In simple cases, a device may have a single trust anchor that is hard-wired or managed only through physical access to the device. However, to support the ability to delegate different functions to different authorities, a device may use multiple trust anchors. It may be desirable to manage those trust anchors in the same manner as software updates, certificate requests, etc. 2. Problem Statement Trust anchors are used to support many application scenarios. Most Internet browsers and email clients use trust anchors to authenticate TLS sessions, to verify signed email and to generate encrypted email. Many software distributions are digitally signed to enable authentication of the originator to be performed prior to installation. Trust anchors that support these applications are typically installed as part of the operating system or application, installed using an enterprise configuration management system or installed directly by the application user. For devices with greater security requirements, trust anchors are often initially installed in the device in a trusted manner with no means of managing the trust anchor store in a non-secure environment. Trust anchors are typically stored in application or operating system specific trust anchor stores. Often, a single machine may have a number of different trust anchor stores that may or may not be synchronized (or need to be synchronized). Reviewing the contents of a particular trust anchor store typically involves the use of a purpose built tool that interacts with a particular type of trust store. The presence of a trust anchor in a particular store is often implicit authorization to validate signatures in the contexts from which the store is accessed. Trust relationships between PKIs are negotiated by policy authorities. Negotiations frequently require significant time to ensure all participating parties' requirements are satisfied. These requirements are expressed, to some extent, in public key certificates. In order for these requirements to be enforced, trust anchor stores must be managed in accord with policy authority intentions. Trust anchors are often represented as self-signed certificates, which provide no useful means of establishing trust in the information contained in the certificate. Trust is established through out-of-band means, often by checking the "fingerprint" of the self-signed certificate with an authoritative source. Routine trust anchor re-key operations typically require similar out-of-band Reddy & Wallace Expires November 25, 2007 [Page 3] Internet-Draft Trust Anchor Management Problem Statement May 2007 checks. Ideally, only the initial trust anchor installed in a particular device should require out-of-band trust establishment, particularly when the costs of performing out-of-band checks commensurate with the security requirements of a device are high. Despite the prevalent use of trust anchors, there is neither a standard means for reporting the trust anchors installed in a particular device nor for managing those trust anchors. The remainder of this document describes some of the functional characteristics a solution to this problem should exhibit along with some security considerations. 3. Functional Properties A general-purpose solution for the management of trust anchors must be transport independent in order to apply to a range of device communications environments. It should also be applicable in both a session-oriented and store-and-forward context. Trust anchor configurations may be uniform across an enterprise, or they may be unique to a single device or small set of devices. Management transactions, therefore, may be generic, targeted to groups of devices, or targeted to individual devices. Once installed, a trust anchor represents an entity with authority over a device. It is important to be able to define the scope of authority, which may be very specific (e.g., a trust anchor public key may be limited to verification of firmware updates only), or it may be for a more general purpose (such as to validate certification paths to certificates issued to users or devices). It should also be possible to authorize an authority to further delegate authority or to prevent delegation. The authorities responsible for managing trust anchors (i.e., the trust anchor managers) represent the ultimate authority over a device due to the ability to control what other authorities the device recognizes. The ultimate authority is likely to be associated with the legal owner of the device in an enterprise setting or an agency authority for government devices. The trust anchor manager may be static over the life of a device, or it may change as legal ownership or other factors change. A trust anchor management protocol should enable secure transfer of a device from one trust anchor manager to another as well as delegation over specific aspects of the device without delegation of the trust anchor management capability itself. Trust anchor re-key is one type of transfer that must be supported. Reddy & Wallace Expires November 25, 2007 [Page 4] Internet-Draft Trust Anchor Management Problem Statement May 2007 A trust anchor management protocol must be capable of managing trust anchors that can be used to validate certification paths in accordance with RFC3280. Minimally, the definition of a trust anchor must include a public key, a public key algorithm and, if necessary, public key parameters. When the public key is used to validate certification paths, a distinguished name must also be included. A public key identifier should be included to enable other applications of the trust anchor, for example, verification of data signed using the Cryptographic Message Syntax SignedData structure. In some scenarios, a public key may be explicitly trusted for some purposes, but not trusted for use in validating certification paths. A trust anchor management protocol must enable the placement of trust anchors that do not serve as trust anchors in the traditional certification path validation sense. For example, a public key may be trusted only for verification of signed firmware packages. This is analogous to the basicConstraints certificate extension. Connections between PKIs can be accomplished using different means. Unilateral or bilateral cross-certification can be performed, or a community may simply elect to explicitly trust the trust anchor from another community. Typically, these decisions occur at the enterprise level. In some scenarios, it can be useful to establish these connections for a small community within an enterprise. Enterprise-wide mechanisms such as cross-certificates are ill-suited for this purpose since certificate revocation or expiration affects the entire enterprise. A trust anchor management protocol can address this issue by supporting managed installation of trust anchors, or more tightly controlled trust list management capabilities within the enterprise. Managed installation requires the ability to identify the members of the community that are authorized to rely upon a particular trust anchor, as well as the ability to query and report on the contents of the trust anchor store. 4. Using Cryptographic Message Syntax The Cryptographic Message Syntax (CMS) [RFC 3852] is a data protection encapsulation syntax that is used to digitally sign, authenticate, or encrypt arbitrary message content. The CMS is transport layer independent and is applicable to both real time and store-and-forward environments, thus providing a feature that is not found in most web-based or other application-specific protocols. A variety of protocols use the CMS, including [RFC2797], [RFC3851] and [RFC4108]. Reddy & Wallace Expires November 25, 2007 [Page 5] Internet-Draft Trust Anchor Management Problem Statement May 2007 CMS is defined using ASN.1 and encoded using BER and DER. The CMS SignedData structure supports the use of certificates for verifying digital signatures. Since a primary function of a trust anchor is to validate certification paths comprised of DER-encoded certificates, CMS is a logical choice for authenticating messages exchanged as part of a trust anchor management protocol, which will require authentication and integrity at a minimum. The CMS can be used to protect arbitrary content, which may be structured or unstructured. Content is identified using object identifiers. These object identifiers provide an opportunity for expressing the scope of authority for trust anchors. Specifically, a trust anchor can be authorized to serve as a source for selected CMS content types for which it is authoritative. The CMS SignedData content type can be employed to convey a signed trust anchor management message. Optionally, the SignedData content type may also contain the certificates needed to validate the digital signature, allowing the use of certificates as a delegation mechanism. The intent is to use CMS both as a means for providing the required security services as well as a convenient mechanism for expressing authorizations. Trust anchor management messages would be encapsulated using the CMS. Trust anchors would be defined as authoritative for a particular set of content types, e.g. software update. Through the processing of the content type constraints, the device can establish that an authoritative instruction has been issued and will act upon that instruction. In this authorization model, a CMS SignedData, will be considered valid only if the signature or message authentication code (MAC) verification process is successful and the originator is authorized for the encapsulated content type. An originator's constraints are derived from the certification path used to validate the originator's certificate. Constraints are associated with trust anchors and constraints are optionally included in public key certificates. The trust anchor structure lists the content types for which it may be used, and the trust anchor may also include constraints associated with each of the content types. 5. Security Considerations Similar to public key certificates, trust anchor configurations and management transactions are not expected to be sensitive. Therefore, confidentiality is not required for trust anchors or trust anchor management transactions. Reddy & Wallace Expires November 25, 2007 [Page 6] Internet-Draft Trust Anchor Management Problem Statement May 2007 Traditionally, trust anchors are distributed out-of-band with integrity mechanisms checked manually prior to installing the trust anchor. Installation is performed by anyone with sufficient administrative privilege on the system receiving the trust anchor. A trust anchor management protocol should enable integrity to be checked automatically by relying upon a public key that is resident on the client system participating in the protocol. The ability to manage the trust store can be transformed into the ability to engage in the trust anchor management protocol with centralized control of the trust anchor store contents being possible. The public key used to authenticate the trust anchor management transactions may have been placed on the client as the result of an earlier transaction or during an initial bootstrap configuration operation. At least one public key authorized for trust anchor management must be placed on each device to be managed during the initial configuration of the device. This public key may be transported and checked using traditional out-of-band means. An entity receiving trust anchor information must be able to authenticate the party providing the information and be able to confirm the party is authorized to provide trust anchor information. A trust anchor may be authorized to participate in trust anchor management protocol exchanges but limited to managing trust anchors within a particular scope. Alternatively, a trust anchor may be authorized to participate in trust anchor management protocol exchanges without any constraints on the types of trust anchors that may be managed. Clear subordination rules must be defined. Some devices that utilize trust anchors have no access to a reliable source of time. Trust anchor management transactions should enable such devices to obtain trust anchor information without being subject to replay attacks that could add old or no-longer-trusted trust anchors to a trust anchor store. Compromise of a trust anchor private key can have significant negative consequences. A trust anchor management protocol must include strategies to enable recovery from the compromise of a trust anchor private key, including the private key authorized to serve as a source of trust anchor information. A trust anchor manager must be able to authenticate which device produced the report listing the trust anchors that comprise a trust anchor store and be able to confirm the contents of the report have not been subsequently altered. Undetectable replay of old reports must not be possible. Reddy & Wallace Expires November 25, 2007 [Page 7] Internet-Draft Trust Anchor Management Problem Statement May 2007 A trust anchor definition should enable the representation of constraints that influence certification path validation or usage of the trust anchor public key for other purposes. Reliance on unauthorized trust anchors is the primary threat that must be countered by a trust anchor management protocol. 6. IANA Considerations None. Please remove this section prior to publication as an RFC. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119. March 1997. [RFC2797] Myers, M, Liu, X., Schaad, J., and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000. [RFC3851] Ramsdell, B., "Secure Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [RFC4108] Housley, R., "Using CMS to Protect Firmware Packages", RFC 4108, August 2005. 7.2. Informative References None. Reddy & Wallace Expires November 25, 2007 [Page 8] Internet-Draft Trust Anchor Management Problem Statement May 2007 Author's Addresses Raksha Reddy National Security Agency Email: r (dot) reddy (at) radium (dot) ncsc (dot) mil Carl Wallace Cygnacom Solutions Email: cwallace (at) cygnacom (dot) com Reddy & Wallace Expires November 25, 2007 [Page 9] Internet-Draft Trust Anchor Management Problem Statement May 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Reddy & Wallace Expires November 25, 2007 [Page 10]