idnits 2.17.1 draft-hoyer-keyprov-portable-symmetric-key-container-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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1938. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1949. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1962. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Too long document name: The document name (without revision number), 'draft-hoyer-keyprov-portable-symmetric-key-container', is 52 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 9, 2007) is 6129 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 1835, but no explicit reference was found in the text == Unused Reference: 'OATHRefArch' is defined on line 1838, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSKPP' ** Downref: Normative reference to an Informational RFC: RFC 4226 (ref. 'HOTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'OATH' -- Possible downref: Non-RFC (?) normative reference: ref. 'OATHRefArch' == Outdated reference: A later version (-14) exists of draft-mraihi-mutual-oath-hotp-variants-01 ** 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 (==), 16 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 10, 2008 VeriSign 6 S. Machani 7 Diversinet 8 A. Vassilev 9 Axalto 10 J. Martinsson 11 PortWise 12 July 9, 2007 14 Portable Symmetric Key Container 15 draft-hoyer-keyprov-portable-symmetric-key-container-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 10, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document specifies a symmetric key format for transport and 49 provisioning of symmetric keys (One Time Password (OTP) shared 50 secrets or symmetric cryptographic keys) to different types of strong 51 authentication devices. The standard token format enables 52 enterprises to deploy best-of-breed solutions combining components 53 from different vendors into the same infrastructure. 55 This work is a joint effort by the members of OATH (Initiative for 56 Open AuTHentication) to specify a format that can be freely 57 distributed to the technical community. The authors believe that a 58 common and shared specification will facilitate adoption of two- 59 factor authentication on the Internet by enabling interoperability 60 between commercial and open-source implementations. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Conventions used in this document . . . . . . . . . . . . . . 5 66 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6 68 3.1.1. Credential migration by end-user . . . . . . . . . . . 6 69 3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6 70 3.1.3. Bulk migration of existing credentials . . . . . . . . 6 71 3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7 72 3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7 73 3.2.1. Online provisioning a credential to end-user's 74 authentication token . . . . . . . . . . . . . . . . . 7 75 3.2.2. Server to server provisioning of credentials . . . . . 8 76 3.2.3. Online update of an existing authentication token 77 credential . . . . . . . . . . . . . . . . . . . . . . 8 78 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 5. Symmetric Key Attributes . . . . . . . . . . . . . . . . . . . 11 80 5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11 81 5.1.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11 82 5.1.2. KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11 83 5.1.3. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 11 84 5.1.4. KeyId (MANDATORY) . . . . . . . . . . . . . . . . . . 12 85 5.1.5. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 12 86 5.1.6. FriendlyName (OPTIONAL) . . . . . . . . . . . . . . . 12 87 5.1.7. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 12 88 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute 89 is encrypted)) . . . . . . . . . . . . . . . . . . . . 12 90 5.1.9. DigestMethod (MANDATORY when Digest is present) . . . 13 91 5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 13 92 6. Key container XML schema definitions . . . . . . . . . . . . . 17 93 6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17 94 6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 18 95 6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 20 96 6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22 97 6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22 98 6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 23 99 6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 24 100 6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 25 101 6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 27 102 6.1.9. AlgorithmIdentifierType . . . . . . . . . . . . . . . 28 103 6.2. EncryptionAlgorithmType . . . . . . . . . . . . . . . . . 28 104 6.3. HashAlgorithmType . . . . . . . . . . . . . . . . . . . . 30 105 6.4. DigestAlgorithmType . . . . . . . . . . . . . . . . . . . 30 106 6.5. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 31 107 6.6. valueFormat . . . . . . . . . . . . . . . . . . . . . . . 33 108 6.7. Data elements . . . . . . . . . . . . . . . . . . . . . . 33 109 6.7.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 33 110 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35 111 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 112 8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 41 113 8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 42 114 8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 42 115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 116 10. Appendix A - Example Symmetric Key Containers . . . . . . . . 44 117 10.1. Symmetric Key Container with a single Non-Encrypted 118 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 44 119 10.2. Symmetric Key Container with a single Password-based 120 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 45 121 11. Normative References . . . . . . . . . . . . . . . . . . . . . 46 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 123 Intellectual Property and Copyright Statements . . . . . . . . . . 50 125 1. Introduction 127 With increasing use of symmetric key based authentication systems 128 such as systems based one time password (OTP) and challenge response 129 mechanisms, there is a need for vendor interoperability and a 130 standard format for importing, exporting or provisioning symmetric 131 key based credentials from one system to another. Traditionally 132 authentication server vendors and service providers have used 133 proprietary formats for importing, exporting and provisioning these 134 credentials into their systems making it hard to use tokens from 135 vendor A with a server from vendor B. 137 This Internet draft describes a standard format for serializing 138 symmetric key based credentials such as OTP shared secrets for system 139 import, export or network/protocol transport. The goal is that the 140 format will facilitate dynamic provisioning and transfer of a 141 symmetric key such as an OTP shared secret or an encryption key of 142 different types. In the case of OTP shared secrets, the format will 143 facilitate dynamic provisioning using an OTP provisioning protocol to 144 different flavors of embedded tokens for OTP credentials or allow 145 customers to import new or existing tokens in batch or single 146 instances into a compliant system. 148 This draft also specifies the token attributes required for 149 interoperability such as the initial event counter used in the HOTP 150 algorithm [HOTP]. It is also applicable for other time-based or 151 proprietary algorithms. 153 To provide an analogy, in public key environments the PKCS#12 format 154 [PKCS12] is commonly used for importing and exporting private keys 155 and certificates between systems. In the environments outlined in 156 this document where OTP credentials may be transported directly down 157 to smartcards or devices with limited computing capabilities, a 158 format with small (size in bytes) and explicit shared secret 159 configuration attribute information is desirable, avoding complexity 160 of PKCS#12. For example, one would have to use opaque data within 161 PKCS#12 to carry shared secret attributes used for OTP calculations, 162 wherears a more explicit attribute schema definition is better for 163 interoperation and efficiency. 165 2. Conventions used in this document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 In examples, "C:" and "S:" indicate lines sent by the client and 172 server respectively. 174 In the text below, OTP refers to one time password. 176 3. Use Cases 178 This section describes a comprehensive list of use cases that 179 inspired the development of this specification. These requirements 180 were used to derive the primary requirement that drove the design. 181 These requirements are covered in the next section. 183 These use cases also help in understanding the applicability of this 184 specification to real world situations. 186 3.1. Offline Use Cases 188 This section describes the use cases relating to offline transport of 189 credentials from one system to another, using some form of export and 190 import model. 192 3.1.1. Credential migration by end-user 194 A user wants to migrate a credential from one authentication token 195 (container) to a different authentication token. For example, the 196 authentication tokens may be soft tokens on two different systems 197 (computers or mobile phones). The user can export the credential in 198 a standard format for import into the other authentication token. 200 The key protection mechanism may rely on password-based encryption 201 for soft tokens, a pre-placed hardware-protected transfer key shared 202 between the two systems or may also rely on asymmetric keys/ PKI if 203 available. 205 3.1.2. Bulk import of new credentials 207 Tokens are manufactured in bulk and associated credentials (key 208 records) need to be loaded into the validation system through a file 209 on portable media. The manufacturer provides the credentials in the 210 form of a file containing records in standard format, typically on a 211 CD. Note that the token manufacturer and the vendor for the 212 validation system may be the same or different. 214 In this case the file usually is protected by a symmetric transport 215 key which was communicated separately outside of the file between the 216 two parties. 218 3.1.3. Bulk migration of existing credentials 220 An enterprise wants to port credentials from an existing validation 221 system A into a different validation system B. The existing 222 validation system provides the enterprise with a functionality that 223 enables export of credentials (OTP tokens) in a standard format. 225 Since the OTP tokens are in the standard format, the enterprise can 226 import the token records into the new validation system B and start 227 using the existing tokens. Note that the vendors for the two 228 validation systems may be the same or different. 230 In this case the file usually is protected by a symmetric transport 231 key which was communicated separately outside of the file between the 232 two validation systems. 234 3.1.4. Credential upload case 236 User wants to activate and use a new credential against a validation 237 system that is not aware of this credential. This credential may be 238 embedded in the authentication token (e.g. SD card, USB drive) that 239 the user has purchased at the local electronics retailer. Along with 240 the authentication token, the user may get the credential on a CD or 241 a floppy in a standard format. The user can now upload via a secure 242 online channel or import this credential into the new validation 243 system and start using the credential. 245 The key protection mechanism may rely on password-based encryption, 246 or a pre-placed hardware-protected transfer key shared between the 247 token manufacturer and the validation system(s) if available. 249 3.2. Online Use Cases 251 This section describes the use cases related to provisioning the 252 credentials using some form of a online provisioning protocol. 254 3.2.1. Online provisioning a credential to end-user's authentication 255 token 257 A mobile device user wants to obtain an OTP credential (shared 258 secret) for use with an OTP soft token on the device. The soft token 259 client from vendor A initiates the provisioning process against a 260 provisioning system from vendor B using a standards-based 261 provisioning protocol such as [DSKPP]. The provisioning system 262 delivers an OTP credential in a standard format that can be processed 263 by the mobile device. The user can download more than one credential 264 in a single session if the provisioning server holds multiple 265 credentials for that user. 267 In a variation of the above, instead of the user's mobile phone, a 268 credential is provisioned in the user's soft token application on a 269 laptop using a network-based online protocol. As before, the 270 provisioning system delivers an OTP credential in a standard format 271 that can be processed by the soft token on the PC. 273 3.2.2. Server to server provisioning of credentials 275 Sometimes, instead of importing token information from manufacturer 276 using a file, an OTP validation server may download the credential 277 seed records using an online protocol. The credentials can be 278 downloaded in a standard format that can be processed by a validation 279 system. 281 In another scenario, an OTA (over-the-air) credential provisioning 282 gateway that provisions credentials to mobile phones may obtain 283 credentials from the credential issuer using an online protocol. The 284 credentials are delivered in a standard format that can be processed 285 by the OTA credential provisioning gateway and subsequently sent to 286 the end-user's mobile phone. 288 3.2.3. Online update of an existing authentication token credential 290 The end-user or the credential issuer wants to update or configure an 291 existing credential in the authentication token and requests a 292 replacement credential container. The container may or may not 293 include a new secret key and may include new or updated secret key 294 attributes such as a new counter value in HOTP credential case, a new 295 logo, a modified response format or length, a new friendly name, etc. 297 4. Requirements 299 This section outlines the most relevant requirements that are the 300 basis of this work. Several of the requirements were derived from 301 use cases described above. 303 R1: The format MUST support transport of multiple types of 304 symmetric key credentials including HOTP, other OTP, challenge- 305 response, etc. 307 R2: The format MUST handle the symmetric key itself as well of 308 attributes that are typically associated with symmetric keys. 309 Some of these attributes may be 311 * Unique Key Identifier 313 * Issuer information 315 * Algorithm ID 317 * Algorithm mode 319 * Issuer Name 321 * Issuer logo 323 * Credential friendly name 325 * Event counter value (moving factor for OTP algorithms) 327 * Time value 329 R3: The format SHOULD support both offline and online scenarios. 330 That is it should be serializable to a file as well as it 331 should be possible to use this format in online provisioning 332 protocols 334 R4: The format SHOULD allow bulk representation of symmetric key 335 credentials. 337 R5: The format SHOULD be portable to various platforms. 338 Furthermore, it SHOULD be computationally efficient to process. 340 R6: The format MUST provide appropriate level of security in terms 341 of data encryption and data integrity. 343 R7: For online scenarios the format SHOULD NOT rely on transport 344 level security (e.g., SSL/TLS) for core security requirements. 346 R8: The format SHOULD be extensible. It SHOULD enable extension 347 points allowing vendors to specify additional attributes in the 348 future. 350 R9: The format SHOULD allow for distribution of key derivation data 351 without the actual symmetric key itself. This is to support 352 symmetric key management schemes that rely on key derivation 353 algorithms based on a pre-placed master key. The key 354 derivation data typically consists of a reference to the key, 355 rather than the key value itself. 357 R10: The format SHOULD allow for additional lifecycle management 358 operations such as counter resynchronization. Such processes 359 require confidentiality between client and server, thus could 360 use a common secure container format, without the transfer of 361 key material. 363 R11: The format MUST support the use of pre-shared symmetric keys to 364 ensure confidentiality of sensitive data elements. 366 R12: The format MUST support a password-based encryption (PBE) 367 [PKCS5] scheme to ensure security of sensitive data elements. 368 This is a widely used method for various provisioning 369 scenarios. 371 R13: The format SHOULD support asymmetric encryption algorithms such 372 as RSA to ensure end-to-end security of sensitive data 373 elements. This is to support scenarios where a pre-set shared 374 encryption key is difficult to use. 376 5. Symmetric Key Attributes 378 The symmetric key includes a number of data attributes that define 379 the type of the key its usage and associated meta-information 380 required during the provisioning, configuration, access or usage in 381 the host device. 383 5.1. Common Attributes 385 5.1.1. Data (OPTIONAL) 387 Defines the data attributes of the symmetric key. Each is a name 388 value pair which has both a base64 encoded value and a base 64 389 encoded valueDigest. The value can be encrypted. If the container 390 has been encrypted the valueDigest MUST be populated with the digest 391 of the unencrypted value. 393 This is also where the key value is held, therefore the follwoing 394 list of attribute names have been reserved: 396 SECRET: the shared secret key value in binary, base64 encoded 398 COUNTER: the event counter for event based OTP algorithms. 8 bytes 399 unsigned integer in big endian (i.e. network byte order) form 400 base64 encoded 402 TIME: the time for time based OTP algorithms. 8 bytes unsigned 403 integer in big endian (i.e. network byte order) form base64 404 encoded (Number of seconds since 1970) 406 TIME_INTERVAL: the time interval value for time based OTP 407 algorithms. 8 bytes unsigned integer in big endian (i.e. network 408 byte order) form base64 encoded. 410 5.1.2. KeyAlgorithm (MANDATORY) 412 Defines the type of algorithm of the secret key and MUST be set to 413 one of the values defined in Section 6.5. If 'OTHER' is specified an 414 extension value MUST be set in the 'ext-KeyAlgorithm' attribute. 416 5.1.3. Usage (MANDATORY) 418 Defines the intended usage of the key and is a combination of one or 419 more of the following (set to true): 421 OTP: the key will be used for OTP generation 423 CR: the key will be used for Challenge/Response purposes 425 ENCRYPT: the key will be used for data encryption purposes 427 SIGN: the key will be used to generate a signature or keyed 428 hashing for data integrity or authentication purposes. 430 UNLOCK: the key will be used for an inverse challenge response in 431 the case a user has locked the device by entering a wrong PIN too 432 many times (for devices with PIN-input capability) 434 Additional attributes that are specific to the usage type MAY be 435 required. Section 6.1 describes OTP and CR specific attributes. 437 5.1.4. KeyId (MANDATORY) 439 A unique and global identifier of the symmetric key. The identifier 440 is defined as a string of alphanumeric characters. 442 5.1.5. Issuer (MANDATORY) 444 The key issuer name, this is normally the name of the organisation 445 that issues the key to the end user of the key. For example MyBank 446 issuing hardware tokens to their retail banking users 'MyBank' would 447 be the issuer. The Issuer is defined as a String. 449 5.1.6. FriendlyName (OPTIONAL) 451 The user friendly name that is assigned to the secret key for easy 452 reference. The FriendlyName is defined as a String. 454 5.1.7. AccessRules (OPTIONAL) 456 Defines a set of access rules and policies for the protection of the 457 key on the host Device. Currently only the userPIN policy is 458 defined. The userPIN policy specifies whether the user MUST enter a 459 PIN (for devices with PIN input capability) in order to unlock or 460 authenticate to the device hosting the key container. The userPIN is 461 defined as a Boolean (TRUE or FALSE). When the user PIN is required, 462 the policy MUST be set to TRUE. If the userPIN is NOT provided, 463 implementations SHALL default the value to FALSE. 465 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute is encrypted)) 467 Identifies the encryption algorithm and possible parameters used to 468 protect the Secret Key data in the container and MUST be set to one 469 of the values defined in Section 6.2. If 'OTHER' is specified an 470 extension value MUST be set in the 'ext-algorithm' attribute. 472 When the value is set to NONE, implementations SHALL ensure the 473 privacy of the key data through other standard mechanisms e.g. 474 transport level encryption. 476 When the KeyContainer contains more than one key and EncryptionMethod 477 is different from NONE, the same encryption key MUST be used to 478 encrypt all the key data elements in the container. 480 5.1.9. DigestMethod (MANDATORY when Digest is present) 482 Identifies the algorithm and possible parameters used to generate a 483 digest of the the Secret Key data. The digest guarantees the 484 integrity and the authenticity of the key data. The Digest algorithm 485 MUST be set to one of the values defined in Section 6.4. If 'OTHER' 486 is specified an extension value MUST be set in the 'ext-algorithm' 487 attribute. 489 See Section 6.1.8 for more information on Digest data value type. 491 5.1.10. OTP and CR specific Attributes (OPTIONAL) 493 When the key usage is set to OTP or CR, additional attributes MUST be 494 provided to support the OTP and/or the response computation as 495 required by the underlying algorithm and to customize or configure 496 the outcome of the computation (format, length and usage modes). 498 5.1.10.1. ChallengeFormat (MANDATORY) 500 The ChallengeFormat attribute defines the characteristics of the 501 challenge in a CR usage scenario. The Challenge attribute is defined 502 by the following sub-attributes: 504 1. Format (MANDATORY) 506 Defines the format of the challenge accepted by the device and 507 MUST be one of the values defined in Section 6.6 509 2. CheckDigit (OPTIONAL) 511 Defines if the device needs to check the appended Luhn check 512 digit contained in a provided challenge. This is only valid 513 if the Format attribute is'DECIMAL'. Value MUST be: 515 TRUE device will check the appended Luhn check digit in a 516 provided challenge 518 FALSE device will not check appended Luhn check digit in 519 challenge 521 3. Min (MANDATORY) 523 Defines the minimum size of the challenge accepted by the 524 device for CR mode. 526 If the Format attribute is 'DECIMAL','HEXADECIMAL' or 527 'ALPHANUMERIC' this value indicates the minimum number of 528 digits/characters. 530 If the Format attribute is 'BASE64' or 'BINARY', this value 531 indicates the minimum number of bytes of the unencoded value. 533 Value MUST be: 535 Unsigned integer. 537 4. Max (MANDATORY) 539 Defines the maximum size of the challenge accepted by the 540 device for CR mode. 542 If the Format attribute is 'DECIMAL','HEXADECIMAL' or 543 'ALPHANUMERIC' this value indicates the maximum number of 544 digits/characters. 546 If the Format attribute is 'BASE64' or 'BINARY', this value 547 indicates the maximum number of bytes of the unencoded value. 549 Value MUST be: 551 Unsigned integer. 553 5.1.10.2. ResponseFormat (MANDATORY) 555 The ResponseFormat attribute defines the characteristics of the 556 result of a computation. This defines the format of the OTP or of 557 the response to a challenge. The Response attribute is defined by 558 the following sub-attributes: 560 1. Format (MANDATORY) 562 Defines the format of the response generated by the device and 563 MUST be one of the values defined in Section 6.6 565 2. CheckDigit (OPTIONAL) 567 Defines if the device needs to append a Luhn check digit to 568 the response. This is only valid if the Format attribute 569 is'DECIMAL'. Value MUST be: 571 TRUE device will append a Luhn check digit to the response. 573 FALSE device will not append a Luhn check digit to the 574 response. 576 3. Length (MANDATORY) 578 Defines the length of the response generated by the device. 580 If the Format attribute is 'DECIMAL','HEXADECIMAL' or 581 'ALPHANUMERIC' this value indicates the number of digits/ 582 characters. 584 If the Format attribute is 'BASE64' or 'BINARY', this value 585 indicates the number of bytes of the unencoded value. 587 Value MUST be: 589 Unsigned integer. 591 5.1.10.3. AppProfileId (OPTIONAL) 593 Defines the application profile id related to attributes present on a 594 smart card that have influence when computing a response. An example 595 could be an EMV MasterCard CAP [CAP] application on a card that 596 contains attributes or uses fixed data for a specific batch of cards 597 such as: 599 IAF Internet authentication flag 601 CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA 602 13, VISA14) 603 AIP (Application Interchange Profile), 2 bytes 605 TVR Terminal Verification Result, 5 bytes 607 CVR The card verification result 609 AmountOther 611 TransactionDate 613 TerminalCountryCode 615 TransactionCurrencyCode 617 AmountAuthorised 619 IIPB 621 These values are not contained within attributes in the container but 622 are shared between the manufacturing and the validation service 623 through this unique AppProfileId. 625 6. Key container XML schema definitions 627 The portable key container is defined by the following entities: 629 1. KeyContainer entity 631 2. Device entity 633 3. Key entity 635 4. User entity 637 A KeyContainer MAY contain one or more Device entities. A Device MAY 638 contain one or more Key entities and may be associated to one or more 639 User entities. 641 The figure below indicates a possible relationship diagram of a 642 container. 644 -------------------------------------------- 645 | KeyContainer | 646 | | 647 | ----------------- ----------------- | 648 | | Device 1 | | Device n | | 649 | | | | | | 650 | | ----------- | | ----------- | | 651 | | | Key 1 | | | | Key n | | | 652 | | ----------- | | ----------- | | 653 | | | | | | | | | 654 | | | | | | | | | 655 | | ----------- | | ----------- | | 656 | | | Key m | | | | Key p | | | 657 | | ----------- | | ----------- | | 658 | ----------------- ----------------- | 659 | | | | | 660 | | | | | 661 | --------- --------- --------- | 662 | | User 1 | | User 1 | | User n | | 663 | --------- --------- --------- | 664 | | 665 -------------------------------------------- 667 6.1. XML Schema Types 669 The following types are defined to represent the portable key 670 container entities and associated attributes. 672 6.1.1. KeyType 674 The KeyType represents the key entity in the KeyContainer. The 675 KeyType is defined as follows: 677 678 679 680 681 682 684 685 686 687 688 690 691 692 693 694 695 696 697 698 700 701 703 The components of the KeyType have the following meanings (see 704 Section 5 for further information): 706 o of type UsageType defines the usage of the Secret Key. The 707 Usage attribute is described in Section 5.1.3. 709 o identifies the issuer of the Secret Key. The Issuer 710 attribute is described in Section 5.1.5. 712 o is a user friendly name that is assigned to the 713 Secret Key for easy reference. 715 o conveys the data attributes (eg the Secret Key) in name 716 (string) value (base64 encoded) pairs. The value can be 717 encrypted, in this case a digest of the non-encrypted data is 718 present. The component is further described below. 720 o Defines the rules for accessing the credential on 721 the device e.g. a password must be provided by the user to view 722 credential info or use the credential to generate an OTP response 724 o KeyId is a global identifier of the Secret Key. See Section 5.1.4. 726 o KeyAlgorithm defines the algorithm used with the Secret Key. The 727 type values are defined in Section 6.5. If 'OTHER' is specified 728 an extension value MUST be set in the 'ext-KeyAlgorithm' 729 attribute. 731 o ext-KeyAlgorithm is the extension point for KeyAlgorithms not 732 already defined Section 6.5 734 o Logo of type LogoType associates display logos with this Secret 735 Key 737 o Expiry defines the expiry date of the Secret Key in format DD/MM/ 738 YYYY 740 The element is of type and is defined as follows: 742 743 744 745 746 747 748 750 The 'Name' attribute defines the name of the name-value pair, the 751 follwoing list of attribute names have been reserved: 753 SECRET: the key key value in binary, base64 encoded 755 COUNTER: the event counter for event based OTP algorithms. 8 bytes 756 unsigned integer in big endian (i.e. network byte order) form 757 base64 encoded 759 TIME: the time for time based OTP algorithms. 8 bytes unsigned 760 integer in big endian (i.e. network byte order) form base64 761 encoded (Number of seconds since 1970) 763 TIME_INTERVAL: the time interval value for time based OTP 764 algorithms. 8 bytes unsigned integer in big endian (i.e. network 765 byte order) form base64 encoded. 767 The element in the DataType conveys the value of the name- 768 value pair in base 64 encoding. The value MAY be encrypted or in 769 clear text as per the EncryptionMethod data element in the 770 KeyContainer (see Section 6.1.6 for details about KeyContainerType). 771 When the value is encrypted, the digest value in 'ValueDigest' MUST 772 be provided. The digest MUST be calculated on the unencrypted value 773 and MUST use one of the Digest algorithms specified in 774 DigestMethodType element of the KeyContainer. The MAC key for the 775 MAC calculation should use the same key as the encryption key 776 specified in the EncryptionMethod unless a separate MAC key is 777 specified. When PBE method is used for encryption, a different 778 password is recommended for the MAC key derivation. When the key 779 data is in clear text, the KeyContainer payload signature MAY be used 780 to check the integrity of the key octets. 782 6.1.2. UsageType 784 The UsageType defines the usage attribute of the key entity. The 785 UsageType is defined as follows: 787 788 789 791 792 793 795 797 799 800 801 802 803 805 806 807 809 810 811 812 813 815 817 819 821 823 825 The UsageType components have the following meanings: 827 o the AlgorithmIdentifier as defined in 828 [OCRA]]. 830 o hold the challenge attributes in CR based 831 algorithm computations. 833 o holds the algorithm response attributes. 835 o holds a set of access rules and policies for the key 836 once provisioned on the Device. Currently only the userPIN 837 attribute is defined. The userPIN indicates whether the user MUST 838 provide a PIN to unlock the key. 840 o Is the unique shared identifier for out of band 841 shared common parameters. 843 6.1.3. DeviceType 845 The DeviceType type represents the Device entity in the Container. A 846 Device MAY be bound to a user and MAY contain more than one keys. It 847 is recommended that a key is bound to one and only one Device. 849 The DeviceType is defined as follows: 851 852 853 855 857 858 859 861 The components of the DeviceType have the following meanings: 863 o , a unique identifier for the device, defined by the 864 DeviceId type. 866 o , represents the key entity defined by the KeyType. 868 o , optionally identifies the owner or the user of the Device, 869 as defined by the UserType . 871 6.1.4. DeviceIdType 873 The DeviceId type represents the identifying criteria to uniquely 874 identify the device that contains the associated keys. Since devices 875 can come in different form factors such as hardware tokens, 876 smartcards, soft tokens in a mobile phone or PC etc this type allows 877 different criteria to be used. Combined though the criteria MUST 878 uniquely identify the device. For example for hardware tokens the 879 combination of SerialNo and Manufacturer will uniquely identify a 880 device but not serialNo alone since two different token manufacturers 881 might issue devices with the same serialnumber (similar to the 882 IssuerDN and serialnumber of a certificate). For keys hold on 883 banking cards the identification of the device is often done via the 884 Primary Account Number (PAN, the big number printed on the front of 885 the card) and an expiry date of the card. DeviceId is an extensible 886 type that allows all these different ways to uniquely identify a 887 specific key containing device. 889 The DeviceIdType is defined as follows: 891 892 893 894 895 896 897 898 899 901 The components of the DeviceId type have the following meanings: 903 o , the manufacturer of the device. 905 o , the model of the device (e.g one-button-HOTP-token-V1) 907 o , the serial number of the device or the PAN (primary 908 account number) in case of EMV (Europay-MasterCard-Visa) smart 909 cards. 911 o , the issue number in case of smart cards with the same 912 PAN, equivalent to a PSN (PAN Sequence Number). 914 o , the expiry date of a device (such as the one on an EMV 915 card,used when issue numbers are not printed on cards). In format 916 DD/MM/YYYY 918 6.1.5. UserType Type 920 The UserType represents the identifying criteria to uniquely identify 921 the user who is bound to this device. 923 The UserType is defined as follows: 925 926 927 928 929 930 931 932 933 934 936 The components of the UserType type have the following meanings: 938 o , user first name. 940 o , user last name. 942 o , user id (UID) or user name. 944 o , user organization name. 946 6.1.6. KeyContainerType 948 The KeyContainerType represents the key container entity. A 949 Container MAY contain more than one Device entity; each Device entity 950 MAY contain more than one Key entity. 952 The KeyContainerType is defined as follows: 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 972 974 975 977 979 The components of the KeyContainer have the following meanings: 981 o version, the version number for the portable key container format 982 (the XML schema defined in this document). 984 o , the encryption method used to protect the Key 985 data attributes 987 o , the digest method used to sign the unencrypted the 988 Secret Key data attributes 990 o , the host Device for one or more Keys. 992 o , contains the signature value of the Container. When 993 the signature is applied to the entire container, it MUST use XML 994 Signature methods as defined in [XMLSIG]. The signature is 995 enveloped. 997 6.1.7. EncryptionMethodType 999 The EncryptionMethodType defines the algorithm and parameters used to 1000 encrypt the Secret Key data attributes in the Container. The 1001 encryption is applied on each individual Secret Key data in the 1002 Container. The encryption method MUST be the same for all Secret Key 1003 data in the container. 1005 The EncryptionMethodType is defined as follows: 1007 1008 1009 1010 1011 1012 1013 1014 1016 1017 1018 1019 1020 1021 1022 1023 1024 1026 1027 1029 The components of the EncryptionMethodType have the following 1030 meanings: 1032 o algorithm: identifies the encryption algorithm used to protect the 1033 Secret Key data. When 'NONE' is specified, implementations MUST 1034 guarantee the privacy of the Secret Key Data through other 1035 mechanisms e.g. through transport level security. If 'OTHER' is 1036 specified an extension value MUST be set in the 'ext-algorithm' 1037 attribute. Please see EncryptionAlgorithmType for more 1038 information on supported algorithms 1040 o : conveys the Salt when [PKCS5] password-based encryption 1041 is applied. 1043 o : conveys the iteration count value in [PKCS5] 1044 password-based encryption if it is different from the default 1045 value. 1047 o : conveys the initialization vector for CBC based encryption 1048 algorithms. It is recommended for security reasons to transmit 1049 this value out of band and treat it the same manner as the key 1050 value. 1052 o : identifies a unique label for a pre-shared 1053 encryption key. 1055 o : conveys the information of the key if an RSA algorithm 1056 has been used. 1058 o : conveys the OAEP parameters if an RSA algorithm has 1059 been used. 1061 o : conveys the digest algorithm if an RSA algorithm 1062 has been used. 1064 6.1.8. DigestMethodType 1066 The DigestMethodType defines the algorithm and parameters used to 1067 create the digest on the unencrypted Secret Key data in the 1068 Container. The digest is applied on each individual Secret Key data 1069 in the Container before encryption. The digest method MUST be the 1070 same for all Secret Key data in the container. Unless a different 1071 digest key is specified it is assumed that keyed digest algorithms 1072 will use the same key as for encryption 1074 The DigestMethodType is defined as follows: 1076 1077 1078 1079 1080 1082 1084 The components of the DigestMethodType have the following meanings: 1086 o algorithm, identifies the digest algorithm used to protect the 1087 Secret Key data. Please see DigestAlgorithmType for more 1088 information on supported algorithms 1090 o : identifies a unique label for a pre-shared 1091 digest key. 1093 6.1.9. AlgorithmIdentifierType 1095 The AlgorithmIdentiferType defines the Algorithm identifier (AI) 1096 specified in [OCRA]. 1098 The AlgorithmIdentifierType is defines as follows: 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1127 See [OCRA] for a full description of the components of the 1128 AlgorithmIdentifierType. 1130 6.2. EncryptionAlgorithmType 1132 The EncryptionAlgorithmType defines the allowed algorithms for 1133 encrypting the Secret Key data in the Container. 1135 The EncryptionAlgorithmType is defined as follows: 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1156 NONE when no encryption is applied on the key 1158 PBE-3DES112-CBC when password-based encryption is applied using a 1159 112-bit 3DES key in CBC mode 1161 PBE-3DES168-CBC when password-based encryption is applied using a 1162 168-bit 3DES key in CBC mode 1164 PBE-AES128-CBC when password-based encryption is applied using a 1165 128-bit AES key in CBC mode 1167 PBE-AES192-CBC when password-based encryption is applied using a 1168 192-bit AES key in CBC mode is applied. 1170 PBE-AES256-CBC password-based encryption is applied using a 256- 1171 bit AES key in CBC mode is applied. 1173 3DES112-CBC encryption using a pre-shared 112-bit 3DES key in CBC 1174 mode is applied. 1176 3DES168-CBC encryption using a pre-shared 168-bit 3DES key in CBC 1177 mode is applied. 1179 AES128-CBC encryption using a pre-shared 128-bit AES key in CBC 1180 mode is applied. 1182 AES192-CBC encryption using a pre-shared 192-bit AES key in CBC 1183 mode is applied. 1185 AES256-CBC encryption using a pre-shared 256-bit AES key in CBC 1186 mode is applied. 1188 RSA-1_5 The RSAES-PKCS1-v1_5 algorithm, specified in [PKCS1], 1189 takes no explicit parameters. 1191 RSA-OAEP-MGF1P The same algorithm as defined in section 5.4.2 RSA- 1192 OAEP in [XMLENC] It is the RSAES-OAEP-ENCRYPT algorithm, as 1193 specified in [PKCS1], it takes three parameters. The two user 1194 specified parameters are a MANDATORY message digest function and 1195 an OPTIONAL encoding octet string OAEPparams. The message digest 1196 function is indicated by the Algorithm attribute of a child ds: 1197 DigestMethod element and the mask generation function, the third 1198 parameter, is always MGF1 with SHA1 (mgf1SHA1Identifier). 1200 OTHER extension point for not already defined algorithms in this 1201 list. 1203 6.3. HashAlgorithmType 1205 The HashAlgorithmType defines the allowed algorithms for generating a 1206 digest in the RSA algorithms. 1208 The HashAlgorithmType is defined as follows: 1210 1211 1212 1213 1214 1215 1216 1218 SHA1 when the digest was performed using the SHA1 algorithm 1220 SHA192 when the digest was performed using the SHA192 algorithm 1222 SHA256 when the digest was performed using the SHA256 algorithm 1224 6.4. DigestAlgorithmType 1226 The DigestAlgorithmType defines the allowed algorithms for generating 1227 a digest on the unencrypted Secret Key data in the Container. 1229 The DigestAlgorithmType is defined as follows: 1231 1232 1233 1234 1235 1236 1237 1238 1240 HMAC-SHA1 when the digest was performed using the HMAC-SHA1 1241 algorithm 1243 HMAC-SHA192 when the digest was performed using the HMAC-SHA192 1244 algorithm 1246 HMAC-SHA256 when the digest was performed using the HMAC-SHA256 1247 algorithm 1249 OTHER extension point for not already defined algorithms in this 1250 list. 1252 6.5. KeyAlgorithmType 1254 The KeyAlgorithmType defines the algorithms in which the Secret Key 1255 data is used. 1257 The KeyAlgorithmType is defined as follows: 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1277 3DES112, a 112-bit 3DES key (a.k.a. two-key 3DES) 1279 3DES168, a 168-bit parity-checked 3DES key 1281 ACTI, algorithm family from ActivIdentity 1283 AES128, a 128-bit AES key 1285 AES192, a 192-bit AES key 1287 AES256, a 256-bit AES key 1289 ANSIX9.9, ANSI X9.9 algorithm 1291 DES, a standard DES key 1293 HOTP, as defined in [HOTP] 1295 MKEYLABEL, master key abel or name when an embedded device key is 1296 used to derive the Key 1298 RSASECUREID, SecureId algorithm family from RSA 1300 VASCO, algorithm family from Vasco 1302 OTHER extension point for not already defined algorithms in this 1303 list. 1305 6.6. valueFormat 1307 The valueFormat defines allowed formats for challenges or responses 1308 in the OTP algorithms. 1310 The valueFormat is defined as follows: 1312 1313 1314 1315 1316 1317 1318 1319 1320 1322 DECIMAL Only numerical digits 1324 HEXADECIMAL Hexadecimal response 1326 ALPHANUMERIC All letters and numbers (case sensitive) 1328 BASE64 Base 64 encoded 1330 BINARY Binary data, this is mainly used in case of connected 1331 devices 1333 6.7. Data elements 1335 6.7.1. KeyContainer 1337 The KeyContainer data element is defined as: 1339 1341 The KeyContainer data element is of type KeyContainerType defined in 1342 Section 6.1.6. 1344 The EncryptionMethod data element in the KeyContainer defines the 1345 encryption algorithm used to protect the Key data. In a multi-key 1346 KeyContainer, the same encryption method and the same encryption key 1347 MUST be used for all key data elements. 1349 The KeyContainer data element MAY contain multiple Device data 1350 elements, allowing for bulk provisioning of keys. 1352 The Signature data element is of type as defined in 1353 [XMLSIG] and MAY be omitted in the KeyContainer data element when 1354 application layer provisioning or transport layer provisioning 1355 protocols provide the integrity and authenticity of the payload 1356 between the sender and the recipient of the container. When 1357 required, this specification recommends using a symmetric key based 1358 signature with the same key used in the encryption of the secret key 1359 data. The signature is enveloped. 1361 7. Formal Syntax 1363 The following syntax specification uses the widely adopted XML schema 1364 format as defined by a W3C recommendation 1365 (http://www.w3.org/TR/xmlschema-0/). It is a complete syntax 1366 definition in the XML Schema Definition format (XSD) 1368 All implentations of this standard must comply with the schema below. 1370 1371 1377 1380 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1400 1402 1403 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1417 1418 1419 1420 1421 1422 1423 1424 1425 1427 1429 1431 1433 1435 1436 1437 1438 1439 1440 1441 1443 1445 1446 1447 1448 1449 1451 1452 1453 1454 1455 1457 1458 1459 1460 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1477 1479 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1497 1498 1499 1501 1502 1504 1505 1506 1507 1508 1510 1511 1512 1514 1515 1516 1517 1518 1519 1521 1523 1525 1527 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1544 1546 1548 1549 1550 1552 1554 1555 1556 1557 1558 1560 1561 1562 1563 1564 1565 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 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 1626 1627 1628 1629 1630 1631 1632 1633 1634 1636 1637 1638 1639 1641 1642 1643 1645 8. Security Considerations 1647 The portable key container carries sensitive information (e.g., 1648 cryptographic keys) and may be transported across the boundaries of 1649 one secure perimeter to another. For example, a container residing 1650 within the secure perimeter of a back-end provisioning server in a 1651 secure room may be transported across the internet to an end-user 1652 device attached to a personal computer. This means that special care 1653 must be taken to ensure the confidentiality, integrity, and 1654 authenticity of the information contained within. 1656 8.1. Payload confidentiality 1658 By design, the container allows two main approaches to guaranteeing 1659 the confidentiality of the information it contains while transported. 1661 First, the container key data payload may be encrypted. 1663 In this case no transport layer security is required. However, 1664 standard security best practices apply when selecting the strength of 1665 the cryptographic algorithm for payload encryption. Symmetric 1666 cryptographic cipher should be used - the longer the cryptographic 1667 key, the stronger the protection. At the time of this writing both 1668 3DES and AES are recommended algorithms but 3DES may be dropped in 1669 the relatively near future. Applications concerned with algorithm 1670 longevity are advised to use AES. In cases where the exchange of 1671 encryption keys between the sender and the receiver is not possible, 1672 asymmetric encryption of the secret key payload may be employed. 1673 Similarly to symmetric key cryptography, the stronger the asymmetric 1674 key, the more secure the protection is. 1676 If the payload is encrypted with a method that uses one of the 1677 password-based encryption methods provided above, the payload may be 1678 subjected to password dictionary attacks to break the encryption 1679 password and recover the information. Standard security best 1680 practices for selection of strong encryption passwords apply 1681 [Schneier]. 1683 Practical implementations should use PBESalt and PBEIterationCount 1684 when PBE encryption is used. Different PBESalt value per credential 1685 record should be used for best protection. 1687 The second approach to protecting the confidentiality of the payload 1688 is based on using transport layer security. The secure channel 1689 established between the source secure perimeter (the provisioning 1690 server from the example above) and the target perimeter (the device 1691 attached to the end-user computer) utilizes encryption to transport 1692 the messages that travel across. No payload encryption is required 1693 in this mode. Secure channels that encrypt and digest each message 1694 provide an extra measure of security, especially when the signature 1695 of the payload does not encompass the entire payload. 1697 Because of the fact that the plain text payload is protected only by 1698 the transport layer security, practical implementation must ensure 1699 protection against man-in-the-middle attacks [Schneier]. Validating 1700 the secure channel end-points is critically important for eliminating 1701 intruders that may compromise the confidentiality of the payload. 1703 8.2. Payload integrity 1705 The portable symmetric key container provides a mean to guarantee the 1706 integrity of the information it contains through digital signatures. 1707 For best security practices, the digital signature of the container 1708 should encompass the entire payload. This provides assurances for 1709 the integrity of all attributes. It also allows verification of the 1710 integrity of a given payload even after the container is delivered 1711 through the communication channel to the target perimeter and channel 1712 message integrity check is no longer possible. 1714 8.3. Payload authenticity 1716 The digital signature of the payload is the primary way of showing 1717 its authenticity. The recipient of the container may use the public 1718 key associated with the signature to assert the authenticity of the 1719 sender by tracing it back to a preloaded public key or certificate. 1720 Note that the digital signature of the payload can be checked even 1721 after the container has been delivered through the secure channel of 1722 communication. 1724 A weaker payload authenticity guarantee may be provided by the 1725 transport layer if it is configured to digest each message it 1726 transports. However, no authenticity verification is possible once 1727 the container is delivered at the recipient end. This approach may 1728 be useful in cases where the digital signature of the container does 1729 not encompass the entire payload. 1731 9. Acknowledgements 1733 The authors of this draft would like to thank the following people 1734 for their contributions and support to make this a better 1735 specification: Shuh Chang, Siddhart Bajaj, Stu Veath, Kevin Lewis, 1736 and Andrea Doherty. 1738 10. Appendix A - Example Symmetric Key Containers 1740 All examples are syntactically correct and compatible with the XML 1741 schema in section 7. However, , Key and Key 1742 data values are fictitious 1744 10.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret 1745 Key 1747 1748 1755 1756 1757 1758 1759 Token Manufacturer 1760 98765432187 1761 01/01/2008 1762 1763 1764 Credential Issuer 1765 1766 1767 1768 MyFirstToken 1769 1770 WldjTHZwRm9YTkhBRytseDMrUnc= 1771 WldjTHZwRm9YTkhBRytseDM= 1772 1773 1774 WldjTHZwRm9YTkhBRytseDMrUnc= 1775 WldjTHZwRm9YTkhBRytseDM= 1776 1777 1778 1779 1781 10.2. Symmetric Key Container with a single Password-based Encrypted 1782 HOTP Secret Key 1784 1785 1792 1793 y6TzckeLRQw= 1794 999 1795 1796 1797 1798 1799 Token Manufacturer 1800 98765432187 1801 01/01/2008 1802 1803 1804 Credential Issuer 1805 1806 1807 1808 MySecondToken 1809 1810 7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA== 1811 WldjTHZwRm9YTkhBRytseDMrUnc= 1812 1813 1814 7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA== 1815 WldjTHZwRm9YTkhBRytseDMrUnc= 1816 1817 1818 1819 1821 11. Normative References 1823 [CAP] MasterCard International, "Chip Authentication Program 1824 Functional Architecture", September 2004. 1826 [DSKPP] "Dynamic Symmetric Key Provisioning Protocol", Internet 1827 Draft Informational, URL: http://tools.ietf.org/wg/ 1828 keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007. 1830 [HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password 1831 Algorithm", RFC 4226, 1832 URL: http://rfc.sunsite.dk/rfc/rfc4226.html, 1833 December 2005. 1835 [OATH] "Initiative for Open AuTHentication", 1836 URL: http://www.openauthentication.org. 1838 [OATHRefArch] 1839 OATH, "Reference Architecture", 1840 URL: http://www.openauthentication.org, Version 1.0, 2005. 1842 [OCRA] MRaihi, D., "OCRA: OATH Challenge Response Algorithm", 1843 Internet Draft Informational, URL: http://www.ietf.org/ 1844 internet-drafts/ 1845 draft-mraihi-mutual-oath-hotp-variants-01.txt, 1846 December 2005. 1848 [PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography 1849 Specifications Version 2.0.", 1850 URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0, 1851 October 1998. 1853 [PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange 1854 Syntax Standard", Version 1.0, 1855 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/. 1857 [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography 1858 Standard", Version 2.0, 1859 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/, 1860 March 1999. 1862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1863 Requirement Levels", BCP 14, RFC 2119, March 1997. 1865 [Schneier] 1866 Schneier, B., "Secrets and Lies: Digitial Security in a 1867 Networked World", Wiley Computer Publishing, ISBN 0-8493- 1868 8253-7, 2000. 1870 [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", 1871 URL: http://www.w3.org/TR/xmlenc-core/, December 2002. 1873 [XMLSIG] Eastlake, D., "XML-Signature Syntax and Processing", 1874 URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, 1875 W3C Recommendation, February 2002. 1877 Authors' Addresses 1879 Philip Hoyer 1880 ActivIdenity, Inc. 1881 109 Borough High Street 1882 London, SE1 1NL 1883 UK 1885 Phone: +44 (0) 20 7744 6455 1886 Email: Philip.Hoyer@actividentity.com 1888 Mingliang Pei 1889 VeriSign, Inc. 1890 487 E. Middlefield Road 1891 Mountain View, CA 94043 1892 USA 1894 Phone: +1 650 426 5173 1895 Email: mpei@verisign.com 1897 Salah Machani 1898 Diversinet, Inc. 1899 2225 Sheppard Avenue East 1900 Suite 1801 1901 Toronto, Ontario M2J 5C2 1902 Canada 1904 Phone: +1 416 756 2324 Ext. 321 1905 Email: smachani@diversinet.com 1907 Apostol T. Vassilev 1908 Axalto Inc. 1909 8311 N. FM 620 1910 Austin, TX 78726 1911 USA 1913 Phone: +1 512 331 3723 1914 Email: vassilev@axalto.com 1915 Jon Martinsson 1916 PortWise AB 1917 F?gatan 33 / Kista Science Tower 1918 Kista, SE 164 21 1919 Sweden 1921 Phone: +46 8 562 914 55 1922 Email: jon.martinsson@portwise.com 1924 Full Copyright Statement 1926 Copyright (C) The IETF Trust (2007). 1928 This document is subject to the rights, licenses and restrictions 1929 contained in BCP 78, and except as set forth therein, the authors 1930 retain all their rights. 1932 This document and the information contained herein are provided on an 1933 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1934 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1935 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1936 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1937 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1938 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1940 Intellectual Property 1942 The IETF takes no position regarding the validity or scope of any 1943 Intellectual Property Rights or other rights that might be claimed to 1944 pertain to the implementation or use of the technology described in 1945 this document or the extent to which any license under such rights 1946 might or might not be available; nor does it represent that it has 1947 made any independent effort to identify any such rights. Information 1948 on the procedures with respect to rights in RFC documents can be 1949 found in BCP 78 and BCP 79. 1951 Copies of IPR disclosures made to the IETF Secretariat and any 1952 assurances of licenses to be made available, or the result of an 1953 attempt made to obtain a general license or permission for the use of 1954 such proprietary rights by implementers or users of this 1955 specification can be obtained from the IETF on-line IPR repository at 1956 http://www.ietf.org/ipr. 1958 The IETF invites any interested party to bring to its attention any 1959 copyrights, patents or patent applications, or other proprietary 1960 rights that may cover technology that may be required to implement 1961 this standard. Please address the information to the IETF at 1962 ietf-ipr@ietf.org. 1964 Acknowledgment 1966 Funding for the RFC Editor function is provided by the IETF 1967 Administrative Support Activity (IASA).