idnits 2.17.1 draft-ietf-keyprov-portable-symmetric-key-container-00.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1937. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1944. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1950. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Too long document name: The document name (without revision number), 'draft-ietf-keyprov-portable-symmetric-key-container', is 51 characters long, but may be at most 50 characters Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (July 2007) is 6101 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'OATH' is defined on line 1831, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP' == Outdated reference: A later version (-14) exists of draft-ietf-keyprov-dskpp-00 ** Downref: Normative reference to an Informational RFC: RFC 4226 (ref. 'HOTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'OATH' == Outdated reference: A later version (-14) exists of draft-mraihi-mutual-oath-hotp-variants-05 ** Downref: Normative reference to an Informational draft: draft-mraihi-mutual-oath-hotp-variants (ref. 'OCRA') ** Obsolete normative reference: RFC 2437 (ref. 'PKCS1') (Obsoleted by RFC 3447) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS12' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS5' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSIG' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoyer 3 Internet-Draft ActivIdentity 4 Intended status: Standards Track M. Pei 5 Expires: January 2, 2008 VeriSign 6 S. Machani 7 Diversinet 8 S. Chang 9 Gemalto 10 July 2007 12 Portable Symmetric Key Container 13 draft-ietf-keyprov-portable-symmetric-key-container-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 2, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document specifies a symmetric key format for transport and 47 provisioning of symmetric keys (One Time Password (OTP) shared 48 secrets or symmetric cryptographic keys) to different types of strong 49 authentication devices. The standard token format enables 50 enterprises to deploy best-of-breed solutions combining components 51 from different vendors into the same infrastructure. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Conventions used in this document . . . . . . . . . . . . . . 5 57 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6 59 3.1.1. Credential migration by end-user . . . . . . . . . . . 6 60 3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6 61 3.1.3. Bulk migration of existing credentials . . . . . . . . 6 62 3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7 63 3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.1. Online provisioning a credential to end-user's 65 authentication token . . . . . . . . . . . . . . . . . 7 66 3.2.2. Server to server provisioning of credentials . . . . . 8 67 3.2.3. Online update of an existing authentication token 68 credential . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Symmetric Key Attributes . . . . . . . . . . . . . . . . . . . 11 71 5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11 72 5.1.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11 73 5.1.2. KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11 74 5.1.3. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 11 75 5.1.4. KeyId (MANDATORY) . . . . . . . . . . . . . . . . . . 12 76 5.1.5. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 12 77 5.1.6. FriendlyName (OPTIONAL) . . . . . . . . . . . . . . . 12 78 5.1.7. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 12 79 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute 80 is encrypted)) . . . . . . . . . . . . . . . . . . . . 12 81 5.1.9. DigestMethod (MANDATORY when Digest is present) . . . 13 82 5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 13 83 6. Key container XML schema definitions . . . . . . . . . . . . . 17 84 6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17 85 6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 18 86 6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 20 87 6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22 88 6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22 89 6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 23 90 6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 24 91 6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 25 92 6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 27 93 6.1.9. AlgorithmIdentifierType . . . . . . . . . . . . . . . 28 94 6.2. EncryptionAlgorithmType . . . . . . . . . . . . . . . . . 28 95 6.3. HashAlgorithmType . . . . . . . . . . . . . . . . . . . . 30 96 6.4. DigestAlgorithmType . . . . . . . . . . . . . . . . . . . 30 97 6.5. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 31 98 6.6. valueFormat . . . . . . . . . . . . . . . . . . . . . . . 33 99 6.7. Data elements . . . . . . . . . . . . . . . . . . . . . . 33 100 6.7.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 33 101 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 103 8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 41 104 8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 42 105 8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 42 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 107 10. Appendix A - Example Symmetric Key Containers . . . . . . . . 44 108 10.1. Symmetric Key Container with a single Non-Encrypted 109 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 44 110 10.2. Symmetric Key Container with a single Password-based 111 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 45 112 11. Normative References . . . . . . . . . . . . . . . . . . . . . 46 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 114 Intellectual Property and Copyright Statements . . . . . . . . . . 49 116 1. Introduction 118 With increasing use of symmetric key based authentication systems 119 such as systems based upon one time password (OTP) and challenge 120 response mechanisms, there is a need for vendor interoperability and 121 a standard format for importing, exporting or provisioning symmetric 122 key based credentials from one system to another. Traditionally 123 authentication server vendors and service providers have used 124 proprietary formats for importing, exporting and provisioning these 125 credentials into their systems making it hard to use tokens from 126 vendor A with a server from vendor B. 128 This Internet draft describes a standard format for serializing 129 symmetric key based credentials such as OTP shared secrets for system 130 import, export or network/protocol transport. The goal is that the 131 format will facilitate dynamic provisioning and transfer of a 132 symmetric key such as an OTP shared secret or an encryption key of 133 different types. In the case of OTP shared secrets, the format will 134 facilitate dynamic provisioning using an OTP provisioning protocol to 135 different flavors of embedded tokens for OTP credentials or allow 136 customers to import new or existing tokens in batch or single 137 instances into a compliant system. 139 This draft also specifies the token attributes required for 140 interoperability such as the initial event counter used in the HOTP 141 algorithm [HOTP]. It is also applicable for other time-based or 142 proprietary algorithms. 144 To provide an analogy, in public key environments the PKCS#12 format 145 [PKCS12] is commonly used for importing and exporting private keys 146 and certificates between systems. In the environments outlined in 147 this document where OTP credentials may be transported directly down 148 to smartcards or devices with limited computing capabilities, a 149 format with small (size in bytes) and explicit shared secret 150 configuration attribute information is desirable, avoiding complexity 151 of PKCS#12. For example, one would have to use opaque data within 152 PKCS#12 to carry shared secret attributes used for OTP calculations, 153 whereas a more explicit attribute schema definition is better for 154 interoperability and efficiency. 156 2. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 In examples, "C:" and "S:" indicate lines sent by the client and 163 server respectively. 165 In the text below, OTP refers to one time password. 167 3. Use Cases 169 This section describes a comprehensive list of use cases that 170 inspired the development of this specification. These requirements 171 were used to derive the primary requirement that drove the design. 172 These requirements are covered in the next section. 174 These use cases also help in understanding the applicability of this 175 specification to real world situations. 177 3.1. Offline Use Cases 179 This section describes the use cases relating to offline transport of 180 credentials from one system to another, using some form of export and 181 import model. 183 3.1.1. Credential migration by end-user 185 A user wants to migrate a credential from one authentication token 186 (container) to a different authentication token. For example, the 187 authentication tokens may be soft tokens on two different systems 188 (computers or mobile phones). The user can export the credential in 189 a standard format for import into the other authentication token. 191 The key protection mechanism may rely on password-based encryption 192 for soft tokens, a pre-placed hardware-protected transfer key shared 193 between the two systems or may also rely on asymmetric keys/ PKI if 194 available. 196 3.1.2. Bulk import of new credentials 198 Tokens are manufactured in bulk and associated credentials (key 199 records) need to be loaded into the validation system through a file 200 on portable media. The manufacturer provides the credentials in the 201 form of a file containing records in standard format, typically on a 202 CD. Note that the token manufacturer and the vendor for the 203 validation system may be the same or different. 205 In this case the file usually is protected by a symmetric transport 206 key which was communicated separately outside of the file between the 207 two parties. 209 3.1.3. Bulk migration of existing credentials 211 An enterprise wants to port credentials from an existing validation 212 system A into a different validation system B. The existing 213 validation system provides the enterprise with a functionality that 214 enables export of credentials (OTP tokens) in a standard format. 216 Since the OTP tokens are in the standard format, the enterprise can 217 import the token records into the new validation system B and start 218 using the existing tokens. Note that the vendors for the two 219 validation systems may be the same or different. 221 In this case the file usually is protected by a symmetric transport 222 key which was communicated separately outside of the file between the 223 two validation systems. 225 3.1.4. Credential upload case 227 User wants to activate and use a new credential against a validation 228 system that is not aware of this credential. This credential may be 229 embedded in the authentication token (e.g. SD card, USB drive) that 230 the user has purchased at the local electronics retailer. Along with 231 the authentication token, the user may get the credential on a CD or 232 a floppy in a standard format. The user can now upload via a secure 233 online channel or import this credential into the new validation 234 system and start using the credential. 236 The key protection mechanism may rely on password-based encryption, 237 or a pre-placed hardware-protected transfer key shared between the 238 token manufacturer and the validation system(s) if available. 240 3.2. Online Use Cases 242 This section describes the use cases related to provisioning the 243 credentials using some form of a online provisioning protocol. 245 3.2.1. Online provisioning a credential to end-user's authentication 246 token 248 A mobile device user wants to obtain an OTP credential (shared 249 secret) for use with an OTP soft token on the device. The soft token 250 client from vendor A initiates the provisioning process against a 251 provisioning system from vendor B using a standards-based 252 provisioning protocol such as [DSKPP]. The provisioning system 253 delivers an OTP credential in a standard format that can be processed 254 by the mobile device. The user can download more than one credential 255 in a single session if the provisioning server holds multiple 256 credentials for that user. 258 In a variation of the above, instead of the user's mobile phone, a 259 credential is provisioned in the user's soft token application on a 260 laptop using a network-based online protocol. As before, the 261 provisioning system delivers an OTP credential in a standard format 262 that can be processed by the soft token on the PC. 264 3.2.2. Server to server provisioning of credentials 266 Sometimes, instead of importing token information from a manufacturer 267 using a file, an OTP validation server may download the credential 268 seed records using an online protocol. The credentials can be 269 downloaded in a standard format that can be processed by a validation 270 system. 272 In another scenario, an OTA (over-the-air) credential provisioning 273 gateway that provisions credentials to mobile phones may obtain 274 credentials from the credential issuer using an online protocol. The 275 credentials are delivered in a standard format that can be processed 276 by the OTA credential provisioning gateway and subsequently sent to 277 the end-user's mobile phone. 279 3.2.3. Online update of an existing authentication token credential 281 The end-user or the credential issuer wants to update or configure an 282 existing credential in the authentication token and requests a 283 replacement credential container. The container may or may not 284 include a new secret key and may include new or updated secret key 285 attributes such as a new counter value in HOTP credential case, a new 286 logo, a modified response format or length, a new friendly name, etc. 288 4. Requirements 290 This section outlines the most relevant requirements that are the 291 basis of this work. Several of the requirements were derived from 292 use cases described above. 294 R1: The format MUST support transport of multiple types of 295 symmetric key credentials including HOTP, other OTP, challenge- 296 response, etc. 298 R2: The format MUST handle the symmetric key itself as well of 299 attributes that are typically associated with symmetric keys. 300 Some of these attributes may be 302 * Unique Key Identifier 304 * Issuer information 306 * Algorithm ID 308 * Algorithm mode 310 * Issuer Name 312 * Issuer logo 314 * Credential friendly name 316 * Event counter value (moving factor for OTP algorithms) 318 * Time value 320 R3: The format SHOULD support both offline and online scenarios. 321 That is it should be serializable to a file as well as it 322 should be possible to use this format in online provisioning 323 protocols 325 R4: The format SHOULD allow bulk representation of symmetric key 326 credentials. 328 R5: The format SHOULD be portable to various platforms. 329 Furthermore, it SHOULD be computationally efficient to process. 331 R6: The format MUST provide appropriate level of security in terms 332 of data encryption and data integrity. 334 R7: For online scenarios the format SHOULD NOT rely on transport 335 level security (e.g., SSL/TLS) for core security requirements. 337 R8: The format SHOULD be extensible. It SHOULD enable extension 338 points allowing vendors to specify additional attributes in the 339 future. 341 R9: The format SHOULD allow for distribution of key derivation data 342 without the actual symmetric key itself. This is to support 343 symmetric key management schemes that rely on key derivation 344 algorithms based on a pre-placed master key. The key 345 derivation data typically consists of a reference to the key, 346 rather than the key value itself. 348 R10: The format SHOULD allow for additional lifecycle management 349 operations such as counter resynchronization. Such processes 350 require confidentiality between client and server, thus could 351 use a common secure container format, without the transfer of 352 key material. 354 R11: The format MUST support the use of pre-shared symmetric keys to 355 ensure confidentiality of sensitive data elements. 357 R12: The format MUST support a password-based encryption (PBE) 358 [PKCS5] scheme to ensure security of sensitive data elements. 359 This is a widely used method for various provisioning 360 scenarios. 362 R13: The format SHOULD support asymmetric encryption algorithms such 363 as RSA to ensure end-to-end security of sensitive data 364 elements. This is to support scenarios where a pre-set shared 365 encryption key is difficult to use. 367 5. Symmetric Key Attributes 369 The symmetric key includes a number of data attributes that define 370 the type of the key its usage and associated meta-information 371 required during the provisioning, configuration, access or usage in 372 the host device. 374 5.1. Common Attributes 376 5.1.1. Data (OPTIONAL) 378 Defines the data attributes of the symmetric key. Each is a name 379 value pair which has both a base64 encoded value and a base 64 380 encoded valueDigest. The value can be encrypted. If the container 381 has been encrypted the valueDigest MUST be populated with the digest 382 of the unencrypted value. 384 This is also where the key value is held, therefore the following 385 list of attribute names have been reserved: 387 SECRET: the shared secret key value in binary, base64 encoded 389 COUNTER: the event counter for event based OTP algorithms. 8 bytes 390 unsigned integer in big endian (i.e. network byte order) form 391 base64 encoded 393 TIME: the time for time based OTP algorithms. 8 bytes unsigned 394 integer in big endian (i.e. network byte order) form base64 395 encoded (Number of seconds since 1970) 397 TIME_INTERVAL: the time interval value for time based OTP 398 algorithms. 8 bytes unsigned integer in big endian (i.e. network 399 byte order) form base64 encoded. 401 5.1.2. KeyAlgorithm (MANDATORY) 403 Defines the type of algorithm of the secret key and MUST be set to 404 one of the values defined in Section 6.5. If 'OTHER' is specified an 405 extension value MUST be set in the 'ext-KeyAlgorithm' attribute. 407 5.1.3. Usage (MANDATORY) 409 Defines the intended usage of the key and is a combination of one or 410 more of the following (set to true): 412 OTP: the key will be used for OTP generation 414 CR: the key will be used for Challenge/Response purposes 416 ENCRYPT: the key will be used for data encryption purposes 418 SIGN: the key will be used to generate a signature or keyed 419 hashing for data integrity or authentication purposes. 421 UNLOCK: the key will be used for an inverse challenge response in 422 the case a user has locked the device by entering a wrong PIN too 423 many times (for devices with PIN-input capability) 425 Additional attributes that are specific to the usage type MAY be 426 required. Section 6.1 describes OTP and CR specific attributes. 428 5.1.4. KeyId (MANDATORY) 430 A unique and global identifier of the symmetric key. The identifier 431 is defined as a string of alphanumeric characters. 433 5.1.5. Issuer (MANDATORY) 435 The key issuer name, this is normally the name of the organization 436 that issues the key to the end user of the key. For example MyBank 437 issuing hardware tokens to their retail banking users 'MyBank' would 438 be the issuer. The Issuer is defined as a String. 440 5.1.6. FriendlyName (OPTIONAL) 442 The user friendly name that is assigned to the secret key for easy 443 reference. The FriendlyName is defined as a String. 445 5.1.7. AccessRules (OPTIONAL) 447 Defines a set of access rules and policies for the protection of the 448 key on the host Device. Currently only the userPIN policy is 449 defined. The userPIN policy specifies whether the user MUST enter a 450 PIN (for devices with PIN input capability) in order to unlock or 451 authenticate to the device hosting the key container. The userPIN is 452 defined as a Boolean (TRUE or FALSE). When the user PIN is required, 453 the policy MUST be set to TRUE. If the userPIN is NOT provided, 454 implementations SHALL default the value to FALSE. 456 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute is encrypted)) 458 Identifies the encryption algorithm and possible parameters used to 459 protect the Secret Key data in the container and MUST be set to one 460 of the values defined in Section 6.2. If 'OTHER' is specified an 461 extension value MUST be set in the 'ext-algorithm' attribute. 463 When the value is set to NONE, implementations SHALL ensure the 464 privacy of the key data through other standard mechanisms e.g. 465 transport level encryption. 467 When the KeyContainer contains more than one key and EncryptionMethod 468 is different from NONE, the same encryption key MUST be used to 469 encrypt all the key data elements in the container. 471 5.1.9. DigestMethod (MANDATORY when Digest is present) 473 Identifies the algorithm and possible parameters used to generate a 474 digest of the Secret Key data. The digest guarantees the integrity 475 and the authenticity of the key data. The Digest algorithm MUST be 476 set to one of the values defined in Section 6.4. If 'OTHER' is 477 specified an extension value MUST be set in the 'ext-algorithm' 478 attribute. 480 See Section 6.1.8 for more information on Digest data value type. 482 5.1.10. OTP and CR specific Attributes (OPTIONAL) 484 When the key usage is set to OTP or CR, additional attributes MUST be 485 provided to support the OTP and/or the response computation as 486 required by the underlying algorithm and to customize or configure 487 the outcome of the computation (format, length and usage modes). 489 5.1.10.1. ChallengeFormat (MANDATORY) 491 The ChallengeFormat attribute defines the characteristics of the 492 challenge in a CR usage scenario. The Challenge attribute is defined 493 by the following sub-attributes: 495 1. Format (MANDATORY) 497 Defines the format of the challenge accepted by the device and 498 MUST be one of the values defined in Section 6.6 500 2. CheckDigit (OPTIONAL) 502 Defines if the device needs to check the appended Luhn check 503 digit contained in a provided challenge. This is only valid 504 if the Format attribute is 'DECIMAL'. Value MUST be: 506 TRUE device will check the appended Luhn check digit in a 507 provided challenge 509 FALSE device will not check appended Luhn check digit in 510 challenge 512 3. Min (MANDATORY) 514 Defines the minimum size of the challenge accepted by the 515 device for CR mode. 517 If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or 518 'ALPHANUMERIC' this value indicates the minimum number of 519 digits/characters. 521 If the Format attribute is 'BASE64' or 'BINARY', this value 522 indicates the minimum number of bytes of the unencoded value. 524 Value MUST be: 526 Unsigned integer. 528 4. Max (MANDATORY) 530 Defines the maximum size of the challenge accepted by the 531 device for CR mode. 533 If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or 534 'ALPHANUMERIC' this value indicates the maximum number of 535 digits/characters. 537 If the Format attribute is 'BASE64' or 'BINARY', this value 538 indicates the maximum number of bytes of the unencoded value. 540 Value MUST be: 542 Unsigned integer. 544 5.1.10.2. ResponseFormat (MANDATORY) 546 The ResponseFormat attribute defines the characteristics of the 547 result of a computation. This defines the format of the OTP or of 548 the response to a challenge. The Response attribute is defined by 549 the following sub-attributes: 551 1. Format (MANDATORY) 553 Defines the format of the response generated by the device and 554 MUST be one of the values defined in Section 6.6 556 2. CheckDigit (OPTIONAL) 558 Defines if the device needs to append a Luhn check digit to 559 the response. This is only valid if the Format attribute is 560 'DECIMAL'. Value MUST be: 562 TRUE device will append a Luhn check digit to the response. 564 FALSE device will not append a Luhn check digit to the 565 response. 567 3. Length (MANDATORY) 569 Defines the length of the response generated by the device. 571 If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or 572 'ALPHANUMERIC' this value indicates the number of digits/ 573 characters. 575 If the Format attribute is 'BASE64' or 'BINARY', this value 576 indicates the number of bytes of the unencoded value. 578 Value MUST be: 580 Unsigned integer. 582 5.1.10.3. AppProfileId (OPTIONAL) 584 Defines the application profile id related to attributes present on a 585 smart card that have influence when computing a response. An example 586 could be an EMV MasterCard CAP [CAP] application on a card that 587 contains attributes or uses fixed data for a specific batch of cards 588 such as: 590 IAF Internet authentication flag 592 CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA 593 13, VISA14) 594 AIP (Application Interchange Profile), 2 bytes 596 TVR Terminal Verification Result, 5 bytes 598 CVR The card verification result 600 AmountOther 602 TransactionDate 604 TerminalCountryCode 606 TransactionCurrencyCode 608 AmountAuthorised 610 IIPB 612 These values are not contained within attributes in the container but 613 are shared between the manufacturing and the validation service 614 through this unique AppProfileId. 616 6. Key container XML schema definitions 618 The portable key container is defined by the following entities: 620 1. KeyContainer entity 622 2. Device entity 624 3. Key entity 626 4. User entity 628 A KeyContainer MAY contain one or more Device entities. A Device MAY 629 contain one or more Key entities and may be associated to one or more 630 User entities. 632 The figure below indicates a possible relationship diagram of a 633 container. 635 -------------------------------------------- 636 | KeyContainer | 637 | | 638 | ----------------- ----------------- | 639 | | Device 1 | | Device n | | 640 | | | | | | 641 | | ----------- | | ----------- | | 642 | | | Key 1 | | | | Key n | | | 643 | | ----------- | | ----------- | | 644 | | | | | | | | 645 | | | | | | | | 646 | | ----------- | | ----------- | | 647 | | | Key m | | | | Key p | | | 648 | | ----------- | | ----------- | | 649 | ----------------- ----------------- | 650 | | | | | 651 | | | | | 652 | --------- --------- --------- | 653 | | User 1 | | User 1 | | User n | | 654 | --------- --------- --------- | 655 | | 656 -------------------------------------------- 658 6.1. XML Schema Types 660 The following types are defined to represent the portable key 661 container entities and associated attributes. 663 6.1.1. KeyType 665 The KeyType represents the key entity in the KeyContainer. The 666 KeyType is defined as follows: 668 669 670 671 672 673 675 676 677 678 679 681 682 683 684 685 686 687 688 689 691 692 694 The components of the KeyType have the following meanings (see 695 Section 5 for further information): 697 o of type UsageType defines the usage of the Secret Key. The 698 Usage attribute is described in Section 5.1.3. 700 o identifies the issuer of the Secret Key. The Issuer 701 attribute is described in Section 5.1.5. 703 o is a user friendly name that is assigned to the 704 Secret Key for easy reference. 706 o conveys the data attributes (e.g. the Secret Key) in name 707 (string) value (base64 encoded) pairs. The value can be 708 encrypted, in this case a digest of the non-encrypted data is 709 present. The component is further described below. 711 o Defines the rules for accessing the credential on 712 the device e.g. a password must be provided by the user to view 713 credential info or use the credential to generate an OTP response 715 o KeyId is a global identifier of the Secret Key. See Section 5.1.4. 717 o KeyAlgorithm defines the algorithm used with the Secret Key. The 718 type values are defined in Section 6.5. If 'OTHER' is specified 719 an extension value MUST be set in the 'ext-KeyAlgorithm' 720 attribute. 722 o ext-KeyAlgorithm is the extension point for KeyAlgorithms not 723 already defined Section 6.5 725 o Logo of type LogoType associates display logos with this Secret 726 Key 728 o Expiry defines the expiry date of the Secret Key in format DD/MM/ 729 YYYY 731 The element is of type and is defined as follows: 733 734 735 736 737 738 739 741 The 'Name' attribute defines the name of the name-value pair, the 742 following list of attribute names have been reserved: 744 SECRET: the key value in binary, base64 encoded 746 COUNTER: the event counter for event based OTP algorithms. 8 bytes 747 unsigned integer in big endian (i.e. network byte order) form 748 base64 encoded 750 TIME: the time for time based OTP algorithms. 8 bytes unsigned 751 integer in big endian (i.e. network byte order) form base64 752 encoded (Number of seconds since 1970) 754 TIME_INTERVAL: the time interval value for time based OTP 755 algorithms. 8 bytes unsigned integer in big endian (i.e. network 756 byte order) form base64 encoded. 758 The element in the DataType conveys the value of the name- 759 value pair in base 64 encoding. The value MAY be encrypted or in 760 clear text as per the EncryptionMethod data element in the 761 KeyContainer (see Section 6.1.6 for details about KeyContainerType). 762 When the value is encrypted, the digest value in 'ValueDigest' MUST 763 be provided. The digest MUST be calculated on the unencrypted value 764 and MUST use one of the Digest algorithms specified in 765 DigestMethodType element of the KeyContainer. The MAC key for the 766 MAC calculation should use the same key as the encryption key 767 specified in the EncryptionMethod unless a separate MAC key is 768 specified. When PBE method is used for encryption, a different 769 password is recommended for the MAC key derivation. When the key 770 data is in clear text, the KeyContainer payload signature MAY be used 771 to check the integrity of the key octets. 773 6.1.2. UsageType 775 The UsageType defines the usage attribute of the key entity. The 776 UsageType is defined as follows: 778 779 780 782 783 784 786 788 790 791 792 793 794 796 797 798 800 801 802 803 804 806 808 810 812 814 816 The UsageType components have the following meanings: 818 o the AlgorithmIdentifier as defined in 819 [OCRA]]. 821 o hold the challenge attributes in CR based 822 algorithm computations. 824 o holds the algorithm response attributes. 826 o holds a set of access rules and policies for the key 827 once provisioned on the Device. Currently only the userPIN 828 attribute is defined. The userPIN indicates whether the user MUST 829 provide a PIN to unlock the key. 831 o Is the unique shared identifier for out of band 832 shared common parameters. 834 6.1.3. DeviceType 836 The DeviceType type represents the Device entity in the Container. A 837 Device MAY be bound to a user and MAY contain more than one keys. It 838 is recommended that a key is bound to one and only one Device. 840 The DeviceType is defined as follows: 842 843 844 846 848 849 850 852 The components of the DeviceType have the following meanings: 854 o , a unique identifier for the device, defined by the 855 DeviceId type. 857 o , represents the key entity defined by the KeyType. 859 o , optionally identifies the owner or the user of the Device, 860 as defined by the UserType . 862 6.1.4. DeviceIdType 864 The DeviceId type represents the identifying criteria to uniquely 865 identify the device that contains the associated keys. Since devices 866 can come in different form factors such as hardware tokens, 867 smartcards, soft tokens in a mobile phone or PC etc this type allows 868 different criteria to be used. Combined though the criteria MUST 869 uniquely identify the device. For example for hardware tokens the 870 combination of SerialNo and Manufacturer will uniquely identify a 871 device but not serialNo alone since two different token manufacturers 872 might issue devices with the same serial number (similar to the 873 IssuerDN and serial number of a certificate). For keys hold on 874 banking cards the identification of the device is often done via the 875 Primary Account Number (PAN, the big number printed on the front of 876 the card) and an expiry date of the card. DeviceId is an extensible 877 type that allows all these different ways to uniquely identify a 878 specific key containing device. 880 The DeviceIdType is defined as follows: 882 883 884 885 886 887 888 889 890 892 The components of the DeviceId type have the following meanings: 894 o , the manufacturer of the device. 896 o , the model of the device (e.g one-button-HOTP-token-V1) 898 o , the serial number of the device or the PAN (primary 899 account number) in case of EMV (Europay-MasterCard-Visa) smart 900 cards. 902 o , the issue number in case of smart cards with the same 903 PAN, equivalent to a PSN (PAN Sequence Number). 905 o , the expiry date of a device (such as the one on an EMV 906 card,used when issue numbers are not printed on cards). In format 907 DD/MM/YYYY 909 6.1.5. UserType Type 911 The UserType represents the identifying criteria to uniquely identify 912 the user who is bound to this device. 914 The UserType is defined as follows: 916 917 918 919 920 921 922 923 924 925 927 The components of the UserType type have the following meanings: 929 o , user first name. 931 o , user last name. 933 o , user id (UID) or user name. 935 o , user organization name. 937 6.1.6. KeyContainerType 939 The KeyContainerType represents the key container entity. A 940 Container MAY contain more than one Device entity; each Device entity 941 MAY contain more than one Key entity. 943 The KeyContainerType is defined as follows: 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 963 965 966 968 970 The components of the KeyContainer have the following meanings: 972 o version, the version number for the portable key container format 973 (the XML schema defined in this document). 975 o , the encryption method used to protect the Key 976 data attributes 978 o , the digest method used to sign the unencrypted the 979 Secret Key data attributes 981 o , the host Device for one or more Keys. 983 o , contains the signature value of the Container. When 984 the signature is applied to the entire container, it MUST use XML 985 Signature methods as defined in [XMLSIG]. The signature is 986 enveloped. 988 6.1.7. EncryptionMethodType 990 The EncryptionMethodType defines the algorithm and parameters used to 991 encrypt the Secret Key data attributes in the Container. The 992 encryption is applied on each individual Secret Key data in the 993 Container. The encryption method MUST be the same for all Secret Key 994 data in the container. 996 The EncryptionMethodType is defined as follows: 998 999 1000 1001 1002 1003 1004 1005 1007 1008 1009 1010 1011 1012 1013 1014 1015 1017 1018 1020 The components of the EncryptionMethodType have the following 1021 meanings: 1023 o algorithm: identifies the encryption algorithm used to protect the 1024 Secret Key data. When 'NONE' is specified, implementations MUST 1025 guarantee the privacy of the Secret Key Data through other 1026 mechanisms e.g. through transport level security. If 'OTHER' is 1027 specified an extension value MUST be set in the 'ext-algorithm' 1028 attribute. Please see EncryptionAlgorithmType for more 1029 information on supported algorithms 1031 o : conveys the Salt when [PKCS5] password-based encryption 1032 is applied. 1034 o : conveys the iteration count value in [PKCS5] 1035 password-based encryption if it is different from the default 1036 value. 1038 o : conveys the initialization vector for CBC based encryption 1039 algorithms. It is recommended for security reasons to transmit 1040 this value out of band and treat it the same manner as the key 1041 value. 1043 o : identifies a unique label for a pre-shared 1044 encryption key. 1046 o : conveys the information of the key if an RSA algorithm 1047 has been used. 1049 o : conveys the OAEP parameters if an RSA algorithm has 1050 been used. 1052 o : conveys the digest algorithm if an RSA algorithm 1053 has been used. 1055 6.1.8. DigestMethodType 1057 The DigestMethodType defines the algorithm and parameters used to 1058 create the digest on the unencrypted Secret Key data in the 1059 Container. The digest is applied on each individual Secret Key data 1060 in the Container before encryption. The digest method MUST be the 1061 same for all Secret Key data in the container. Unless a different 1062 digest key is specified it is assumed that keyed digest algorithms 1063 will use the same key as for encryption 1065 The DigestMethodType is defined as follows: 1067 1068 1069 1070 1071 1073 1075 The components of the DigestMethodType have the following meanings: 1077 o algorithm, identifies the digest algorithm used to protect the 1078 Secret Key data. Please see DigestAlgorithmType for more 1079 information on supported algorithms 1081 o : identifies a unique label for a pre-shared 1082 digest key. 1084 6.1.9. AlgorithmIdentifierType 1086 The AlgorithmIdentiferType defines the Algorithm identifier (AI) 1087 specified in [OCRA]. 1089 The AlgorithmIdentifierType is defined as follows: 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1118 See [OCRA] for a full description of the components of the 1119 AlgorithmIdentifierType. 1121 6.2. EncryptionAlgorithmType 1123 The EncryptionAlgorithmType defines the allowed algorithms for 1124 encrypting the Secret Key data in the Container. 1126 The EncryptionAlgorithmType is defined as follows: 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1147 NONE when no encryption is applied on the key 1149 PBE-3DES112-CBC when password-based encryption is applied using a 1150 112-bit 3DES key in CBC mode 1152 PBE-3DES168-CBC when password-based encryption is applied using a 1153 168-bit 3DES key in CBC mode 1155 PBE-AES128-CBC when password-based encryption is applied using a 1156 128-bit AES key in CBC mode 1158 PBE-AES192-CBC when password-based encryption is applied using a 1159 192-bit AES key in CBC mode is applied. 1161 PBE-AES256-CBC password-based encryption is applied using a 256- 1162 bit AES key in CBC mode is applied. 1164 3DES112-CBC encryption using a pre-shared 112-bit 3DES key in CBC 1165 mode is applied. 1167 3DES168-CBC encryption using a pre-shared 168-bit 3DES key in CBC 1168 mode is applied. 1170 AES128-CBC encryption using a pre-shared 128-bit AES key in CBC 1171 mode is applied. 1173 AES192-CBC encryption using a pre-shared 192-bit AES key in CBC 1174 mode is applied. 1176 AES256-CBC encryption using a pre-shared 256-bit AES key in CBC 1177 mode is applied. 1179 RSA-1_5 The RSAES-PKCS1-v1_5 algorithm, specified in [PKCS1], 1180 takes no explicit parameters. 1182 RSA-OAEP-MGF1P The same algorithm as defined in section 5.4.2 RSA- 1183 OAEP in [XMLENC] It is the RSAES-OAEP-ENCRYPT algorithm, as 1184 specified in [PKCS1], it takes three parameters. The two user 1185 specified parameters are a MANDATORY message digest function and 1186 an OPTIONAL encoding octet string OAEPparams. The message digest 1187 function is indicated by the Algorithm attribute of a child ds: 1188 DigestMethod element and the mask generation function, the third 1189 parameter, is always MGF1 with SHA1 (mgf1SHA1Identifier). 1191 OTHER extension point for not already defined algorithms in this 1192 list. 1194 6.3. HashAlgorithmType 1196 The HashAlgorithmType defines the allowed algorithms for generating a 1197 digest in the RSA algorithms. 1199 The HashAlgorithmType is defined as follows: 1201 1202 1203 1204 1205 1206 1207 1209 SHA1 when the digest was performed using the SHA1 algorithm 1211 SHA192 when the digest was performed using the SHA192 algorithm 1213 SHA256 when the digest was performed using the SHA256 algorithm 1215 6.4. DigestAlgorithmType 1217 The DigestAlgorithmType defines the allowed algorithms for generating 1218 a digest on the unencrypted Secret Key data in the Container. 1220 The DigestAlgorithmType is defined as follows: 1222 1223 1224 1225 1226 1227 1228 1229 1231 HMAC-SHA1 when the digest was performed using the HMAC-SHA1 1232 algorithm 1234 HMAC-SHA192 when the digest was performed using the HMAC-SHA192 1235 algorithm 1237 HMAC-SHA256 when the digest was performed using the HMAC-SHA256 1238 algorithm 1240 OTHER extension point for not already defined algorithms in this 1241 list. 1243 6.5. KeyAlgorithmType 1245 The KeyAlgorithmType defines the algorithms in which the Secret Key 1246 data is used. 1248 The KeyAlgorithmType is defined as follows: 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1268 3DES112, a 112-bit 3DES key (a.k.a. two-key 3DES) 1270 3DES168, a 168-bit parity-checked 3DES key 1272 ACTI, algorithm family from ActivIdentity 1274 AES128, a 128-bit AES key 1276 AES192, a 192-bit AES key 1278 AES256, a 256-bit AES key 1280 ANSIX9.9, ANSI X9.9 algorithm 1282 DES, a standard DES key 1284 HOTP, as defined in [HOTP] 1286 MKEYLABEL, master key abel or name when an embedded device key is 1287 used to derive the Key 1289 RSASECUREID, SecureId algorithm family from RSA 1291 VASCO, algorithm family from Vasco 1293 OTHER extension point for not already defined algorithms in this 1294 list. 1296 6.6. valueFormat 1298 The valueFormat defines allowed formats for challenges or responses 1299 in the OTP algorithms. 1301 The valueFormat is defined as follows: 1303 1304 1305 1306 1307 1308 1309 1310 1311 1313 DECIMAL Only numerical digits 1315 HEXADECIMAL Hexadecimal response 1317 ALPHANUMERIC All letters and numbers (case sensitive) 1319 BASE64 Base 64 encoded 1321 BINARY Binary data, this is mainly used in case of connected 1322 devices 1324 6.7. Data elements 1326 6.7.1. KeyContainer 1328 The KeyContainer data element is defined as: 1330 1332 The KeyContainer data element is of type KeyContainerType defined in 1333 Section 6.1.6. 1335 The EncryptionMethod data element in the KeyContainer defines the 1336 encryption algorithm used to protect the Key data. In a multi-key 1337 KeyContainer, the same encryption method and the same encryption key 1338 MUST be used for all key data elements. 1340 The KeyContainer data element MAY contain multiple Device data 1341 elements, allowing for bulk provisioning of keys. 1343 The Signature data element is of type as defined in 1344 [XMLSIG] and MAY be omitted in the KeyContainer data element when 1345 application layer provisioning or transport layer provisioning 1346 protocols provide the integrity and authenticity of the payload 1347 between the sender and the recipient of the container. When 1348 required, this specification recommends using a symmetric key based 1349 signature with the same key used in the encryption of the secret key 1350 data. The signature is enveloped. 1352 7. Formal Syntax 1354 The following syntax specification uses the widely adopted XML schema 1355 format as defined by a W3C recommendation 1356 (http://www.w3.org/TR/xmlschema-0/). It is a complete syntax 1357 definition in the XML Schema Definition format (XSD) 1359 All implentations of this standard must comply with the schema below. 1361 1362 1368 1371 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1391 1393 1394 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1408 1409 1410 1411 1412 1413 1414 1415 1416 1418 1420 1422 1424 1426 1427 1428 1429 1430 1431 1432 1434 1436 1437 1438 1439 1440 1442 1443 1444 1445 1446 1448 1449 1450 1451 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1468 1470 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1488 1489 1490 1492 1493 1495 1496 1497 1498 1499 1501 1502 1503 1505 1506 1507 1508 1509 1510 1512 1514 1516 1518 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1535 1537 1539 1540 1541 1543 1545 1546 1547 1548 1549 1551 1552 1553 1554 1555 1556 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1627 1628 1629 1630 1632 1633 1634 1636 8. Security Considerations 1638 The portable key container carries sensitive information (e.g., 1639 cryptographic keys) and may be transported across the boundaries of 1640 one secure perimeter to another. For example, a container residing 1641 within the secure perimeter of a back-end provisioning server in a 1642 secure room may be transported across the internet to an end-user 1643 device attached to a personal computer. This means that special care 1644 must be taken to ensure the confidentiality, integrity, and 1645 authenticity of the information contained within. 1647 8.1. Payload confidentiality 1649 By design, the container allows two main approaches to guaranteeing 1650 the confidentiality of the information it contains while transported. 1652 First, the container key data payload may be encrypted. 1654 In this case no transport layer security is required. However, 1655 standard security best practices apply when selecting the strength of 1656 the cryptographic algorithm for payload encryption. Symmetric 1657 cryptographic cipher should be used - the longer the cryptographic 1658 key, the stronger the protection. At the time of this writing both 1659 3DES and AES are recommended algorithms but 3DES may be dropped in 1660 the relatively near future. Applications concerned with algorithm 1661 longevity are advised to use AES. In cases where the exchange of 1662 encryption keys between the sender and the receiver is not possible, 1663 asymmetric encryption of the secret key payload may be employed. 1664 Similarly to symmetric key cryptography, the stronger the asymmetric 1665 key, the more secure the protection is. 1667 If the payload is encrypted with a method that uses one of the 1668 password-based encryption methods provided above, the payload may be 1669 subjected to password dictionary attacks to break the encryption 1670 password and recover the information. Standard security best 1671 practices for selection of strong encryption passwords apply 1672 [Schneier]. 1674 Practical implementations should use PBESalt and PBEIterationCount 1675 when PBE encryption is used. Different PBESalt value per credential 1676 record should be used for best protection. 1678 The second approach to protecting the confidentiality of the payload 1679 is based on using transport layer security. The secure channel 1680 established between the source secure perimeter (the provisioning 1681 server from the example above) and the target perimeter (the device 1682 attached to the end-user computer) utilizes encryption to transport 1683 the messages that travel across. No payload encryption is required 1684 in this mode. Secure channels that encrypt and digest each message 1685 provide an extra measure of security, especially when the signature 1686 of the payload does not encompass the entire payload. 1688 Because of the fact that the plain text payload is protected only by 1689 the transport layer security, practical implementation must ensure 1690 protection against man-in-the-middle attacks [Schneier]. Validating 1691 the secure channel end-points is critically important for eliminating 1692 intruders that may compromise the confidentiality of the payload. 1694 8.2. Payload integrity 1696 The portable symmetric key container provides a means to guarantee 1697 the integrity of the information it contains through digital 1698 signatures. For best security practices, the digital signature of 1699 the container should encompass the entire payload. This provides 1700 assurances for the integrity of all attributes. It also allows 1701 verification of the integrity of a given payload even after the 1702 container is delivered through the communication channel to the 1703 target perimeter and channel message integrity check is no longer 1704 possible. 1706 8.3. Payload authenticity 1708 The digital signature of the payload is the primary way of showing 1709 its authenticity. The recipient of the container may use the public 1710 key associated with the signature to assert the authenticity of the 1711 sender by tracing it back to a preloaded public key or certificate. 1712 Note that the digital signature of the payload can be checked even 1713 after the container has been delivered through the secure channel of 1714 communication. 1716 A weaker payload authenticity guarantee may be provided by the 1717 transport layer if it is configured to digest each message it 1718 transports. However, no authenticity verification is possible once 1719 the container is delivered at the recipient end. This approach may 1720 be useful in cases where the digital signature of the container does 1721 not encompass the entire payload. 1723 9. Acknowledgements 1725 This work initiated from a joint effort by the members of OATH 1726 (Initiative for Open AuTHentication). The authors of this draft 1727 would like to thank the following people for their contributions and 1728 support to make this a better specification: Apostol Vassilev, Jon 1729 Martinson, Siddhart Bajaj, Stu Veath, Kevin Lewis, and Andrea 1730 Doherty. 1732 10. Appendix A - Example Symmetric Key Containers 1734 All examples are syntactically correct and compatible with the XML 1735 schema in section 7. However, , Key and Key 1736 data values are fictitious 1738 10.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret 1739 Key 1741 1742 1749 1750 1751 1752 1753 Token Manufacturer 1754 98765432187 1755 01/01/2008 1756 1757 1758 Credential Issuer 1759 1760 1761 1762 MyFirstToken 1763 1764 WldjTHZwRm9YTkhBRytseDMrUnc= 1765 WldjTHZwRm9YTkhBRytseDM= 1766 1767 1768 WldjTHZwRm9YTkhBRytseDMrUnc= 1769 WldjTHZwRm9YTkhBRytseDM= 1770 1771 1772 1773 1775 10.2. Symmetric Key Container with a single Password-based Encrypted 1776 HOTP Secret Key 1778 1779 1786 1787 y6TzckeLRQw= 1788 999 1789 1790 1791 1792 1793 Token Manufacturer 1794 98765432187 1795 01/01/2008 1796 1797 1798 Credential Issuer 1799 1800 1801 1802 MySecondToken 1803 1804 7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA== 1805 WldjTHZwRm9YTkhBRytseDMrUnc= 1806 1807 1808 7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA== 1809 WldjTHZwRm9YTkhBRytseDMrUnc= 1810 1811 1812 1813 1815 11. Normative References 1817 [CAP] MasterCard International, "Chip Authentication Program 1818 Functional Architecture", September 2004. 1820 [DSKPP] Doherty, A., Pei, M., Nystroem, M., and S. Machani, 1821 "Dynamic Symmetric Key Provisioning Protocol", Internet 1822 Draft Informational, URL: http://tools.ietf.org/id/ 1823 draft-ietf-keyprov-dskpp-00.txt, July 2007. 1825 [HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 1826 O. Ranen, "HOTP: An HMAC-Based One Time Password 1827 Algorithm", RFC 4226, 1828 URL: http://rfc.sunsite.dk/rfc/rfc4226.html, 1829 December 2005. 1831 [OATH] "Initiative for Open AuTHentication", 1832 URL: http://www.openauthentication.org. 1834 [OCRA] MRaihi, D., Rydell, J., Machani, S., and S. Bajaj, "OCRA: 1835 OATH Challenge Response Algorithm", Internet 1836 Draft Informational, URL: http://www.ietf.org/ 1837 internet-drafts/ 1838 draft-mraihi-mutual-oath-hotp-variants-05.txt, 1839 December 2005. 1841 [PKCS1] Kaliski, B. and J. Staddon, "RFC 2437: PKCS #1: RSA 1842 Cryptography Specifications Version 2.0.", 1843 URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0, 1844 October 1998. 1846 [PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange 1847 Syntax Standard", Version 1.0, 1848 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/. 1850 [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography 1851 Standard", Version 2.0, 1852 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/, 1853 March 1999. 1855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1856 Requirement Levels", BCP 14, RFC 2119, March 1997. 1858 [Schneier] 1859 Schneier, B., "Secrets and Lies: Digitial Security in a 1860 Networked World", Wiley Computer Publishing, ISBN 0-8493- 1861 8253-7, 2000. 1863 [XMLENC] Eastlake, D. and J. Reagle, "XML Encryption Syntax and 1864 Processing.", URL: http://www.w3.org/TR/xmlenc-core/, 1865 December 2002. 1867 [XMLSIG] Eastlake, D., Reagle, J., and D. Solo, "XML-Signature 1868 Syntax and Processing", 1869 URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, 1870 W3C Recommendation, February 2002. 1872 Authors' Addresses 1874 Philip Hoyer 1875 ActivIdenity, Inc. 1876 109 Borough High Street 1877 London, SE1 1NL 1878 UK 1880 Phone: +44 (0) 20 7744 6455 1881 Email: Philip.Hoyer@actividentity.com 1883 Mingliang Pei 1884 VeriSign, Inc. 1885 487 E. Middlefield Road 1886 Mountain View, CA 94043 1887 USA 1889 Phone: +1 650 426 5173 1890 Email: mpei@verisign.com 1892 Salah Machani 1893 Diversinet, Inc. 1894 2225 Sheppard Avenue East 1895 Suite 1801 1896 Toronto, Ontario M2J 5C2 1897 Canada 1899 Phone: +1 416 756 2324 Ext. 321 1900 Email: smachani@diversinet.com 1902 Shuh Chang 1903 Gemalto Inc. 1904 9442 Capital of Texas Hwy. North 1905 Suite 400, Arboretum Plaza II 1906 Austin, Texas 78759 1907 USA 1909 Phone: +1 512 257 3859 1910 Email: shuh.chang@gemalto.com 1912 Full Copyright Statement 1914 Copyright (C) The IETF Trust (2007). 1916 This document is subject to the rights, licenses and restrictions 1917 contained in BCP 78, and except as set forth therein, the authors 1918 retain all their rights. 1920 This document and the information contained herein are provided on an 1921 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1922 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1923 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1924 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1925 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1926 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1928 Intellectual Property 1930 The IETF takes no position regarding the validity or scope of any 1931 Intellectual Property Rights or other rights that might be claimed to 1932 pertain to the implementation or use of the technology described in 1933 this document or the extent to which any license under such rights 1934 might or might not be available; nor does it represent that it has 1935 made any independent effort to identify any such rights. Information 1936 on the procedures with respect to rights in RFC documents can be 1937 found in BCP 78 and BCP 79. 1939 Copies of IPR disclosures made to the IETF Secretariat and any 1940 assurances of licenses to be made available, or the result of an 1941 attempt made to obtain a general license or permission for the use of 1942 such proprietary rights by implementers or users of this 1943 specification can be obtained from the IETF on-line IPR repository at 1944 http://www.ietf.org/ipr. 1946 The IETF invites any interested party to bring to its attention any 1947 copyrights, patents or patent applications, or other proprietary 1948 rights that may cover technology that may be required to implement 1949 this standard. Please address the information to the IETF at 1950 ietf-ipr@ietf.org. 1952 Acknowledgment 1954 Funding for the RFC Editor function is provided by the IETF 1955 Administrative Support Activity (IASA).