idnits 2.17.1 draft-wallace-ta-mgmt-problem-statement-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 436. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 12, 2007) is 6069 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Reddy 3 Internet-Draft National Security Agency 4 Intended status: Informational C. Wallace 5 Expires: March 15, 2008 Cygnacom Solutions 6 September 12, 2007 8 Trust Anchor Management Problem Statement 9 draft-wallace-ta-mgmt-problem-statement-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 15, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document provides a problem statement for the Trust Anchor 43 Management Birds of a Feather (BOF). A trust anchor represents an 44 authoritative entity via a public key and associated data. The 45 public key is used to verify digital signatures and the associated 46 data is used to constrain the types of information for which the 47 trust anchor is authoritative. Relying parties use trust anchors to 48 determine if digitally signed objects are valid by verifying digital 49 signatures using the trust anchor's public key and by enforcing the 50 constraints expressed in the associated data. This document 51 describes some of the problems associated with the lack of a standard 52 trust anchor management mechanism as well as problems that must be 53 addressed by such a mechanism. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Functional Properties . . . . . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Introduction 71 Digital signatures are used in many applications. For digital 72 signatures to provide integrity and authentication, the public key 73 used to verify the digital signature must be trusted. A public key 74 used to verify a signature must be configured as a trust anchor or 75 contained in a certificate that can be transitively verified by a 76 certification path terminating at a trust anchor. Directly trusted 77 public keys are known as trust anchors. A Trust Anchor is a public 78 key and associated data used by a relying party (RP) to validate a 79 signature on a signed object where the object is either: 81 o a public key certificate that begins a certification path 82 terminated by a signature certificate or encryption certificate 84 o a non-public key certificate object that cannot be validated via 85 use of a certification path 87 Trust anchors have local significance, i.e., each RP is configured 88 with a set of trust anchors, either by the RP or by an entity that 89 manages TAs in the context in which the RP operates. The associated 90 data often is used to define the scope of a trust anchor, by imposing 91 constraints on the signatures it may be used to verify. For example, 92 if a trust anchor is used to verify signatures on X.509 certificates, 93 these constraints may include a combination of name spaces, 94 certificate policies, or application/usage types. Whenever a 95 signature is verified, a trust anchor must be used, either by 96 verifying the signature directly or by validating a certification 97 path. 99 One particular use of digital signatures is the verification of 100 signatures on firmware packages loaded into hardware modules, such as 101 cryptographic modules, cable boxes, routers, etc. Since such devices 102 are often managed remotely, the devices must be able to authenticate 103 the source of management interactions and can use trust anchors to 104 perform this authentication. However, trust anchors require 105 management as well. 107 All applications that rely upon digital signatures must have some 108 means of managing one or more sets of trust anchors. These sets of 109 trust anchors are referred to in this document as trust anchor 110 stores. Often, the means of managing trust anchor stores are 111 application-specific and rely upon out-of-band means to establish and 112 maintain trustworthiness. Applications may use multiple trust anchor 113 stores and a given trust anchor store may be used by multiple 114 applications. Trust anchor stores are managed by trust anchor 115 managers. 117 In some cases, a hardware device may have a single trust anchor that 118 is hard-wired or managed only through physical access to the device. 119 However, to support the ability to delegate different functions to 120 different authorities, the device may require multiple trust anchors. 121 It is desirable to manage those trust anchors using similar means as 122 software updates, certificate requests, etc. to enable code reuse. 124 1.1. Terminology 126 The following terms are defined in order to provide a vocabulary for 127 describing requirements for trust anchor management. 129 Trust Anchor: A trust anchor represents an authoritative entity via 130 a public key and associated data. The public key is used to 131 verify digital signatures and the associated data is used to 132 constrain the types of information for which the trust anchor is 133 authoritative. Relying parties use trust anchors to determine if 134 digitally signed objects are valid by verifying digital signatures 135 using the trust anchor's public key and by enforcing the 136 constraints expressed in the associated data. 138 Trust Anchor Manager: A trust anchor manager is responsible for 139 managing the contents of a trust anchor store. 141 Trust Anchor Store: A trust anchor store is a set of one or more 142 trust anchors. 144 2. Problem Statement 146 Trust anchors are used to support many application scenarios. Most 147 Internet browsers and email clients use trust anchors to authenticate 148 TLS sessions, to verify signed email and to generate encrypted email. 149 Many software distributions are digitally signed to enable 150 authentication of the originator to be performed prior to 151 installation. Trust anchors that support these applications are 152 typically installed as part of the operating system or application, 153 installed using an enterprise configuration management system or 154 installed directly by the application user. 156 In some devices, trust anchors are initially installed in the device 157 in a secure manner with no means of managing the trust anchor store 158 in a non-secure environment. 160 Trust anchors are typically stored in application- or operating 161 system- specific trust anchor stores. Often, a single machine may 162 have a number of different trust anchor stores that may or may not be 163 synchronized (or need to be synchronized). Reviewing the contents of 164 a particular trust anchor store typically involves the use of a 165 proprietary tool that interacts with a particular type of trust 166 store. 168 The mere presence of a trust anchor in a particular store often 169 conveys implicit authorization to validate signatures for any 170 contexts from which the store is accessed. For example, the public 171 key of a timestamp authority (TSA) may be installed in a trust anchor 172 store to validate signatures on timestamps. However, if the trust 173 anchor store is used by multiple applications that serve different 174 purposes, the same key may be used to validate other types of objects 175 such as certificates or OCSP responses. There is currently no 176 standard means of limiting the applicability (scope) of a trust 177 anchor. 179 Trust relationships between PKIs are negotiated by policy 180 authorities. Negotiations frequently require significant time to 181 ensure all participating parties' requirements are satisfied. These 182 requirements are expressed, to some extent, in public key 183 certificates. In order for these requirements to be enforced, trust 184 anchor stores must be managed in accord with policy authority 185 intentions. 187 Trust anchors are often represented as self-signed certificates, 188 which provide no useful means of establishing the validity of the 189 information contained in the certificate. Confidence in the 190 integrity of a trust anchor is typically established through out-of- 191 band means, often by checking the "fingerprint" of the self-signed 192 certificate with an authoritative source. Routine trust anchor re- 193 key operations typically require similar out-of-band checks. 194 Ideally, only the initial set of trust anchors installed in a 195 particular trust anchor store should require out-of-band 196 verification, particularly when the costs of performing out-of-band 197 checks commensurate with the security requirements of applications 198 using the trust anchor store are high. 200 Despite the prevalent use of trust anchors, there is neither a 201 standard means for reporting which trust anchors installed in a 202 particular trust anchor store nor a standard means of managing those 203 trust anchors. The remainder of this document describes some of the 204 functional characteristics a solution to this problem should exhibit 205 along with some security considerations. 207 3. Functional Properties 209 A general-purpose solution for the management of trust anchors must 210 be transport independent in order to apply to a range of device 211 communications environments. It should also be applicable in both 212 session-oriented and store-and-forward contexts. At a minimum, it 213 must enable a trust anchor manager to add trust anchors to, remove 214 trust anchors from and determine which trust anchors are installed in 215 a particular trust anchor store. 217 Trust anchor configurations may be uniform across an enterprise, or 218 they may be unique to a single application or small set of 219 applications. Management transactions, therefore, may be generic, 220 targeted to groups of trust anchor stores, or targeted to individual 221 trust anchor stores. 223 Once installed into a trust anchor store, a trust anchor represents 224 an entity with authority recognized by applications that use that 225 store. It is important to be able to define the scope of authority 226 assigned to each trust anchor, which may be very specific (e.g., a 227 trust anchor public key may be limited to verification of firmware 228 updates only), or more general (such as to validate certification 229 paths for certificates issued to users or devices). It should be 230 possible to authorize a trust anchor to delegate authority and to 231 prevent delegation. 233 Trust anchor managers have significant control over a device or 234 application due to the ability to control what other authorities are 235 recognized. As such, trust anchor managers are likely to be 236 associated with the legal owner of the device or application in an 237 enterprise setting or an agency authority for government devices. 238 The trust anchor manager may be static over the life of a device, or 239 it may change as legal ownership or other factors change. A trust 240 anchor management protocol should enable secure transfer of a device 241 from one trust anchor manager to another as well as delegation over 242 specific aspects of the device without delegation of the overall 243 trust anchor management capability itself. Trust anchor re-key is 244 one type of transfer that must be supported. 246 A trust anchor management protocol must be capable of managing trust 247 anchors that can be used to validate certification paths in 248 accordance with [RFC3280]. Minimally, the definition of a trust 249 anchor must include a public key, a public key algorithm and, if 250 necessary, public key parameters. When the public key is used to 251 validate certification paths, a distinguished name also must be 252 included. A public key identifier should be included to enable other 253 applications of the trust anchor, for example, verification of data 254 signed using the Cryptographic Message Syntax SignedData structure 256 [RFC3852]. 258 In some scenarios, a public key may be explicitly trusted for some 259 purposes, but not trusted for use in validating certification paths. 260 A trust anchor management protocol must enable the management of 261 trust anchors that do not serve as trust anchors for certification 262 path validation. For example, a public key may be used only for 263 verification of signed firmware packages [RFC4108]. 265 Connections between PKIs can be accomplished using different means. 266 Unilateral or bilateral cross-certification can be performed, or a 267 community may simply elect to explicitly trust the trust anchor from 268 another community. Typically, these decisions occur at the 269 enterprise level. In some scenarios, it can be useful to establish 270 these connections for a small community within an enterprise. 271 Enterprise-wide mechanisms such as cross-certificates are ill-suited 272 for this purpose since certificate revocation or expiration affects 273 the entire enterprise. A trust anchor management protocol can 274 address this issue by supporting managed installation of trust 275 anchors, or more tightly controlled trust list management 276 capabilities within the enterprise. Managed installation requires 277 the ability to identify the members of the community that are 278 authorized to rely upon a particular trust anchor, as well as the 279 ability to query and report on the contents of trust anchor stores. 281 There is no common format for trust anchors. A trust anchor 282 management protocol should support various representations of trust 283 anchors to simplify management across a range of application 284 scenarios. Examples of trust anchor formats include self-signed 285 X.509 certificates, Open PGP certificates [RFC2440] or DNSSEC trust 286 anchors. [RFC3280] does not mandate a particular trust anchor 287 representation, and requires only that a trust anchor public key 288 information and a distinguished name be available during 289 certification path validation. 291 A trust anchor manager must be able to authenticate which device 292 produced a report listing the trust anchors that comprise a trust 293 anchor store and be able to confirm the contents of the report have 294 not been subsequently altered. Undetectable replay of old reports 295 must not be possible. 297 A trust anchor definition should enable the representation of 298 constraints that influence certification path validation or otherwise 299 establish the scope of usage of the trust anchor public key. 300 Examples of such constraints are name constraints, certificate 301 policies and key usage. Trust anchor managers must be able to 302 establish the constraints associated with any particular trust 303 anchor. 305 4. Security Considerations 307 The integrity of trust anchor management transactions must be assured 308 and it must be possible to authenticate the originator of a 309 transactions and confirm the originator is authorized for that 310 transaction. 312 Traditionally, trust anchors are distributed out-of-band with 313 integrity mechanisms checked manually prior to installing a trust 314 anchor. Installation is performed by anyone with sufficient 315 administrative privilege on the system receiving the trust anchor. A 316 trust anchor management protocol should enable integrity to be 317 checked automatically by relying upon a public key that is resident 318 on the client system participating in the protocol. The ability to 319 manage the trust anchor store can be transformed into the ability to 320 engage in the trust anchor management protocol with remote control of 321 the trust anchor store contents being possible. 323 The public key used to authenticate the trust anchor management 324 transactions may have been placed on the client as the result of an 325 earlier transaction or during an initial bootstrap configuration 326 operation. In most scenarios, at least one public key authorized for 327 trust anchor management must be placed in each trust store to be 328 managed during the initial configuration of the trust store. This 329 public key may be transported and checked using traditional out-of- 330 band means. In all scenarios, regardless of the authentication 331 mechanism, at least one trust anchor manager must be established for 332 each trust store during the initial configuration of the trust store. 334 An entity receiving trust anchor information must be able to 335 authenticate the party providing the information and be able to 336 confirm the party is authorized to provide trust anchor information. 337 A trust anchor may be authorized to participate in trust anchor 338 management protocol exchanges but limited to managing trust anchors 339 within a particular scope. Alternatively, a trust anchor may be 340 authorized to participate in trust anchor management protocol 341 exchanges without any constraints on the types of trust anchors that 342 may be managed. Clear subordination rules must be defined. 344 Some devices that utilize trust anchors have no access to a reliable 345 source of time. Trust anchor management transactions should enable 346 such devices to obtain trust anchor information without being subject 347 to replay attacks that could add old or no-longer-trusted trust 348 anchors to a trust anchor store. 350 Compromise of a private key corresponding to a trust anchor can have 351 significant negative consequences. A trust anchor management 352 protocol must include strategies to enable recovery from the 353 compromise of a trust anchor private key, including the private key 354 authorized to serve as a source of trust anchor information. 356 Reliance on unauthorized trust anchors is the primary threat that 357 must be countered by a trust anchor management protocol. 359 5. IANA Considerations 361 None. Please remove this section prior to publication as an RFC. 363 6. References 365 6.1. Normative References 367 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 368 X.509 Public Key Infrastructure Certificate and 369 Certificate Revocation List (CRL) Profile", RFC 3280, 370 April 2002. 372 6.2. Informative References 374 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 375 "OpenPGP Message Format", RFC 2440, November 1998. 377 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 378 RFC 3852, July 2004. 380 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 381 Protect Firmware Packages", RFC 4108, August 2005. 383 Authors' Addresses 385 Raksha Reddy 386 National Security Agency 388 Email: r (dot) reddy (at) radium (dot) ncsc (dot) mil 390 Carl Wallace 391 Cygnacom Solutions 392 Suite 5200 393 7925 Jones Branch Drive 394 McLean, VA 22102 396 Email: cwallace@cygnacom.com 398 Full Copyright Statement 400 Copyright (C) The IETF Trust (2007). 402 This document is subject to the rights, licenses and restrictions 403 contained in BCP 78, and except as set forth therein, the authors 404 retain all their rights. 406 This document and the information contained herein are provided on an 407 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 408 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 409 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 410 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 411 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 412 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 414 Intellectual Property 416 The IETF takes no position regarding the validity or scope of any 417 Intellectual Property Rights or other rights that might be claimed to 418 pertain to the implementation or use of the technology described in 419 this document or the extent to which any license under such rights 420 might or might not be available; nor does it represent that it has 421 made any independent effort to identify any such rights. Information 422 on the procedures with respect to rights in RFC documents can be 423 found in BCP 78 and BCP 79. 425 Copies of IPR disclosures made to the IETF Secretariat and any 426 assurances of licenses to be made available, or the result of an 427 attempt made to obtain a general license or permission for the use of 428 such proprietary rights by implementers or users of this 429 specification can be obtained from the IETF on-line IPR repository at 430 http://www.ietf.org/ipr. 432 The IETF invites any interested party to bring to its attention any 433 copyrights, patents or patent applications, or other proprietary 434 rights that may cover technology that may be required to implement 435 this standard. Please address the information to the IETF at 436 ietf-ipr@ietf.org. 438 Acknowledgment 440 Funding for the RFC Editor function is provided by the IETF 441 Administrative Support Activity (IASA).