idnits 2.17.1
draft-ietf-keyprov-portable-symmetric-key-container-01.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 1907.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1918.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1925.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1931.
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 (September 28, 2007) is 6054 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 1816, but no explicit
reference was found in the text
== Unused Reference: 'OATHRefArch' is defined on line 1819, 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 keyprov P. Hoyer
3 Internet-Draft ActivIdentity
4 Intended status: Standards Track M. Pei
5 Expires: March 31, 2008 VeriSign
6 S. Machani
7 Diversinet
8 S. Chang
9 Gemalto
10 September 28, 2007
12 Portable Symmetric Key Container
13 draft-ietf-keyprov-portable-symmetric-key-container-01.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 March 31, 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 This work is a joint effort by the members of OATH (Initiative for
54 Open AuTHentication) to specify a format that can be freely
55 distributed to the technical community. The authors believe that a
56 common and shared specification will facilitate adoption of two-
57 factor authentication on the Internet by enabling interoperability
58 between commercial and open-source implementations.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. Conventions used in this document . . . . . . . . . . . . . . 5
64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
65 3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6
66 3.1.1. Credential migration by end-user . . . . . . . . . . . 6
67 3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6
68 3.1.3. Bulk migration of existing credentials . . . . . . . . 6
69 3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7
70 3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7
71 3.2.1. Online provisioning a credential to end-user's
72 authentication token . . . . . . . . . . . . . . . . . 7
73 3.2.2. Server to server provisioning of credentials . . . . . 8
74 3.2.3. Online update of an existing authentication token
75 credential . . . . . . . . . . . . . . . . . . . . . . 8
76 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
77 5. Symmetric Key Attributes . . . . . . . . . . . . . . . . . . . 11
78 5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11
79 5.1.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11
80 5.1.2. KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11
81 5.1.3. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 11
82 5.1.4. KeyId (MANDATORY) . . . . . . . . . . . . . . . . . . 12
83 5.1.5. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 12
84 5.1.6. FriendlyName (OPTIONAL) . . . . . . . . . . . . . . . 12
85 5.1.7. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 12
86 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute
87 is encrypted)) . . . . . . . . . . . . . . . . . . . . 12
88 5.1.9. DigestMethod (MANDATORY when Digest is present) . . . 13
89 5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 13
90 6. Key container XML schema definitions . . . . . . . . . . . . . 17
91 6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17
92 6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 18
93 6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 20
94 6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22
95 6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22
96 6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 23
97 6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 24
98 6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 25
99 6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 26
100 6.1.9. AlgorithmIdentifierType . . . . . . . . . . . . . . . 27
101 6.2. EncryptionAlgorithmType . . . . . . . . . . . . . . . . . 28
102 6.3. HashAlgorithmType . . . . . . . . . . . . . . . . . . . . 30
103 6.4. DigestAlgorithmType . . . . . . . . . . . . . . . . . . . 30
104 6.5. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 31
105 6.6. valueFormat . . . . . . . . . . . . . . . . . . . . . . . 33
106 6.7. Data elements . . . . . . . . . . . . . . . . . . . . . . 33
107 6.7.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 33
108 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35
109 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
110 8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 41
111 8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 42
112 8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 42
113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
114 10. Appendix A - Example Symmetric Key Containers . . . . . . . . 44
115 10.1. Symmetric Key Container with a single Non-Encrypted
116 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 44
117 10.2. Symmetric Key Container with a single Password-based
118 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 45
119 11. Normative References . . . . . . . . . . . . . . . . . . . . . 46
120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
121 Intellectual Property and Copyright Statements . . . . . . . . . . 49
123 1. Introduction
125 With increasing use of symmetric key based authentication systems
126 such as systems based one time password (OTP) and challenge response
127 mechanisms, there is a need for vendor interoperability and a
128 standard format for importing, exporting or provisioning symmetric
129 key based credentials from one system to another. Traditionally
130 authentication server vendors and service providers have used
131 proprietary formats for importing, exporting and provisioning these
132 credentials into their systems making it hard to use tokens from
133 vendor A with a server from vendor B.
135 This Internet draft describes a standard format for serializing
136 symmetric key based credentials such as OTP shared secrets for system
137 import, export or network/protocol transport. The goal is that the
138 format will facilitate dynamic provisioning and transfer of a
139 symmetric key such as an OTP shared secret or an encryption key of
140 different types. In the case of OTP shared secrets, the format will
141 facilitate dynamic provisioning using an OTP provisioning protocol to
142 different flavors of embedded tokens for OTP credentials or allow
143 customers to import new or existing tokens in batch or single
144 instances into a compliant system.
146 This draft also specifies the token attributes required for
147 interoperability such as the initial event counter used in the HOTP
148 algorithm [HOTP]. It is also applicable for other time-based or
149 proprietary algorithms.
151 To provide an analogy, in public key environments the PKCS#12 format
152 [PKCS12] is commonly used for importing and exporting private keys
153 and certificates between systems. In the environments outlined in
154 this document where OTP credentials may be transported directly down
155 to smartcards or devices with limited computing capabilities, a
156 format with small (size in bytes) and explicit shared secret
157 configuration attribute information is desirable, avoding complexity
158 of PKCS#12. For example, one would have to use opaque data within
159 PKCS#12 to carry shared secret attributes used for OTP calculations,
160 wherears a more explicit attribute schema definition is better for
161 interoperation and efficiency.
163 2. Conventions used in this document
165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
167 document are to be interpreted as described in [RFC2119].
169 In examples, "C:" and "S:" indicate lines sent by the client and
170 server respectively.
172 In the text below, OTP refers to one time password.
174 3. Use Cases
176 This section describes a comprehensive list of use cases that
177 inspired the development of this specification. These requirements
178 were used to derive the primary requirement that drove the design.
179 These requirements are covered in the next section.
181 These use cases also help in understanding the applicability of this
182 specification to real world situations.
184 3.1. Offline Use Cases
186 This section describes the use cases relating to offline transport of
187 credentials from one system to another, using some form of export and
188 import model.
190 3.1.1. Credential migration by end-user
192 A user wants to migrate a credential from one authentication token
193 (container) to a different authentication token. For example, the
194 authentication tokens may be soft tokens on two different systems
195 (computers or mobile phones). The user can export the credential in
196 a standard format for import into the other authentication token.
198 The key protection mechanism may rely on password-based encryption
199 for soft tokens, a pre-placed hardware-protected transfer key shared
200 between the two systems or may also rely on asymmetric keys/ PKI if
201 available.
203 3.1.2. Bulk import of new credentials
205 Tokens are manufactured in bulk and associated credentials (key
206 records) need to be loaded into the validation system through a file
207 on portable media. The manufacturer provides the credentials in the
208 form of a file containing records in standard format, typically on a
209 CD. Note that the token manufacturer and the vendor for the
210 validation system may be the same or different.
212 In this case the file usually is protected by a symmetric transport
213 key which was communicated separately outside of the file between the
214 two parties.
216 3.1.3. Bulk migration of existing credentials
218 An enterprise wants to port credentials from an existing validation
219 system A into a different validation system B. The existing
220 validation system provides the enterprise with a functionality that
221 enables export of credentials (OTP tokens) in a standard format.
223 Since the OTP tokens are in the standard format, the enterprise can
224 import the token records into the new validation system B and start
225 using the existing tokens. Note that the vendors for the two
226 validation systems may be the same or different.
228 In this case the file usually is protected by a symmetric transport
229 key which was communicated separately outside of the file between the
230 two validation systems.
232 3.1.4. Credential upload case
234 User wants to activate and use a new credential against a validation
235 system that is not aware of this credential. This credential may be
236 embedded in the authentication token (e.g. SD card, USB drive) that
237 the user has purchased at the local electronics retailer. Along with
238 the authentication token, the user may get the credential on a CD or
239 a floppy in a standard format. The user can now upload via a secure
240 online channel or import this credential into the new validation
241 system and start using the credential.
243 The key protection mechanism may rely on password-based encryption,
244 or a pre-placed hardware-protected transfer key shared between the
245 token manufacturer and the validation system(s) if available.
247 3.2. Online Use Cases
249 This section describes the use cases related to provisioning the
250 credentials using some form of a online provisioning protocol.
252 3.2.1. Online provisioning a credential to end-user's authentication
253 token
255 A mobile device user wants to obtain an OTP credential (shared
256 secret) for use with an OTP soft token on the device. The soft token
257 client from vendor A initiates the provisioning process against a
258 provisioning system from vendor B using a standards-based
259 provisioning protocol such as [DSKPP]. The provisioning system
260 delivers one or more OTP credential(s) in a standard format that can
261 be processed by the mobile device. The user can download a payload
262 that contains more than one credential.
264 In a variation of the above, instead of the user's mobile phone, a
265 credential is provisioned in the user's soft token application on a
266 laptop using a network-based online protocol. As before, the
267 provisioning system delivers an OTP credential in a standard format
268 that can be processed by the soft token on the PC.
270 3.2.2. Server to server provisioning of credentials
272 Sometimes, instead of importing token information from manufacturer
273 using a file, an OTP validation server may download the credential
274 seed records using an online protocol. The credentials can be
275 downloaded in a standard format that can be processed by a validation
276 system.
278 In another scenario, an OTA (over-the-air) credential provisioning
279 gateway that provisions credentials to mobile phones may obtain
280 credentials from the credential issuer using an online protocol. The
281 credentials are delivered in a standard format that can be processed
282 by the OTA credential provisioning gateway and subsequently sent to
283 the end-user's mobile phone.
285 3.2.3. Online update of an existing authentication token credential
287 The end-user or the credential issuer wants to update or configure an
288 existing credential in the authentication token and requests a
289 replacement credential container. The container may or may not
290 include a new secret key and may include new or updated secret key
291 attributes such as a new counter value in HOTP credential case, a new
292 logo, a modified response format or length, a new friendly name, etc.
294 4. Requirements
296 This section outlines the most relevant requirements that are the
297 basis of this work. Several of the requirements were derived from
298 use cases described above.
300 R1: The format MUST support transport of multiple types of
301 symmetric key credentials including HOTP, other OTP, challenge-
302 response, etc.
304 R2: The format MUST handle the symmetric key itself as well of
305 attributes that are typically associated with symmetric keys.
306 Some of these attributes may be
308 * Unique Key Identifier
310 * Issuer information
312 * Algorithm ID
314 * Algorithm mode
316 * Issuer Name
318 * Issuer logo
320 * Credential friendly name
322 * Event counter value (moving factor for OTP algorithms)
324 * Time value
326 R3: The format SHOULD support both offline and online scenarios.
327 That is it should be serializable to a file as well as it
328 should be possible to use this format in online provisioning
329 protocols
331 R4: The format SHOULD allow bulk representation of symmetric key
332 credentials.
334 R5: The format SHOULD be portable to various platforms.
335 Furthermore, it SHOULD be computationally efficient to process.
337 R6: The format MUST provide appropriate level of security in terms
338 of data encryption and data integrity.
340 R7: For online scenarios the format SHOULD NOT rely on transport
341 level security (e.g., SSL/TLS) for core security requirements.
343 R8: The format SHOULD be extensible. It SHOULD enable extension
344 points allowing vendors to specify additional attributes in the
345 future.
347 R9: The format SHOULD allow for distribution of key derivation data
348 without the actual symmetric key itself. This is to support
349 symmetric key management schemes that rely on key derivation
350 algorithms based on a pre-placed master key. The key
351 derivation data typically consists of a reference to the key,
352 rather than the key value itself.
354 R10: The format SHOULD allow for additional lifecycle management
355 operations such as counter resynchronization. Such processes
356 require confidentiality between client and server, thus could
357 use a common secure container format, without the transfer of
358 key material.
360 R11: The format MUST support the use of pre-shared symmetric keys to
361 ensure confidentiality of sensitive data elements.
363 R12: The format MUST support a password-based encryption (PBE)
364 [PKCS5] scheme to ensure security of sensitive data elements.
365 This is a widely used method for various provisioning
366 scenarios.
368 R13: The format SHOULD support asymmetric encryption algorithms such
369 as RSA to ensure end-to-end security of sensitive data
370 elements. This is to support scenarios where a pre-set shared
371 encryption key is difficult to use.
373 5. Symmetric Key Attributes
375 The symmetric key includes a number of data attributes that define
376 the type of the key its usage and associated meta-information
377 required during the provisioning, configuration, access or usage in
378 the host device.
380 5.1. Common Attributes
382 5.1.1. Data (OPTIONAL)
384 Defines the data attributes of the symmetric key. Each is a name
385 value pair which has both a base64 encoded value and a base 64
386 encoded valueDigest. The value can be encrypted. If the container
387 has been encrypted the valueDigest MUST be populated with the digest
388 of the unencrypted value.
390 This is also where the key value is held, therefore the follwoing
391 list of attribute names have been reserved:
393 SECRET: the shared secret key value in binary, base64 encoded
395 COUNTER: the event counter for event based OTP algorithms. 8 bytes
396 unsigned integer in big endian (i.e. network byte order) form
397 base64 encoded
399 TIME: the time for time based OTP algorithms. 8 bytes unsigned
400 integer in big endian (i.e. network byte order) form base64
401 encoded (Number of seconds since 1970)
403 TIME_INTERVAL: the time interval value for time based OTP
404 algorithms. 8 bytes unsigned integer in big endian (i.e. network
405 byte order) form base64 encoded.
407 5.1.2. KeyAlgorithm (MANDATORY)
409 Defines the type of algorithm of the secret key and MUST be set to
410 one of the values defined in Section 6.5. If 'OTHER' is specified an
411 extension value MUST be set in the 'ext-KeyAlgorithm' attribute.
413 5.1.3. Usage (MANDATORY)
415 Defines the intended usage of the key and is a combination of one or
416 more of the following (set to true):
418 OTP: the key will be used for OTP generation
420 CR: the key will be used for Challenge/Response purposes
422 ENCRYPT: the key will be used for data encryption purposes
424 SIGN: the key will be used to generate a signature or keyed
425 hashing for data integrity or authentication purposes.
427 UNLOCK: the key will be used for an inverse challenge response in
428 the case a user has locked the device by entering a wrong PIN too
429 many times (for devices with PIN-input capability)
431 Additional attributes that are specific to the usage type MAY be
432 required. Section 6.1 describes OTP and CR specific attributes.
434 5.1.4. KeyId (MANDATORY)
436 A unique and global identifier of the symmetric key. The identifier
437 is defined as a string of alphanumeric characters.
439 5.1.5. Issuer (MANDATORY)
441 The key issuer name, this is normally the name of the organisation
442 that issues the key to the end user of the key. For example MyBank
443 issuing hardware tokens to their retail banking users 'MyBank' would
444 be the issuer. The Issuer is defined as a String.
446 5.1.6. FriendlyName (OPTIONAL)
448 The user friendly name that is assigned to the secret key for easy
449 reference. The FriendlyName is defined as a String.
451 5.1.7. AccessRules (OPTIONAL)
453 Defines a set of access rules and policies for the protection of the
454 key on the host Device. Currently only the userPIN policy is
455 defined. The userPIN policy specifies whether the user MUST enter a
456 PIN (for devices with PIN input capability) in order to unlock or
457 authenticate to the device hosting the key container. The userPIN is
458 defined as a Boolean (TRUE or FALSE). When the user PIN is required,
459 the policy MUST be set to TRUE. If the userPIN is NOT provided,
460 implementations SHALL default the value to FALSE.
462 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute is encrypted))
464 Identifies the encryption algorithm and possible parameters used to
465 protect the Secret Key data in the container and MUST be set to one
466 of the values defined in Section 6.2. If 'OTHER' is specified an
467 extension value MUST be set in the 'ext-algorithm' attribute.
469 When the value is set to NONE, implementations SHALL ensure the
470 privacy of the key data through other standard mechanisms e.g.
471 transport level encryption.
473 When the container (payload) contains more than one key and
474 EncryptionMethod is different from NONE, the same encryption key MUST
475 be used to encrypt all the key data elements in the container.
477 5.1.9. DigestMethod (MANDATORY when Digest is present)
479 Identifies the algorithm and possible parameters used to generate a
480 digest of the the Secret Key data. The digest guarantees the
481 integrity and the authenticity of the key data. The Digest algorithm
482 MUST be set to one of the values defined in Section 6.4. If 'OTHER'
483 is specified an extension value MUST be set in the 'ext-algorithm'
484 attribute.
486 See Section 6.1.8 for more information on Digest data value type.
488 5.1.10. OTP and CR specific Attributes (OPTIONAL)
490 When the key usage is set to OTP or CR, additional attributes MUST be
491 provided to support the OTP and/or the response computation as
492 required by the underlying algorithm and to customize or configure
493 the outcome of the computation (format, length and usage modes).
495 5.1.10.1. ChallengeFormat (MANDATORY)
497 The ChallengeFormat attribute defines the characteristics of the
498 challenge in a CR usage scenario. The Challenge attribute is defined
499 by the following sub-attributes:
501 1. Format (MANDATORY)
503 Defines the format of the challenge accepted by the device and
504 MUST be one of the values defined in Section 6.6
506 2. CheckDigit (OPTIONAL)
508 Defines if the device needs to check the appended Luhn check
509 digit contained in a provided challenge. This is only valid
510 if the Format attribute is'DECIMAL'. Value MUST be:
512 TRUE device will check the appended Luhn check digit in a
513 provided challenge
515 FALSE device will not check appended Luhn check digit in
516 challenge
518 3. Min (MANDATORY)
520 Defines the minimum size of the challenge accepted by the
521 device for CR mode.
523 If the Format attribute is 'DECIMAL','HEXADECIMAL' or
524 'ALPHANUMERIC' this value indicates the minimum number of
525 digits/characters.
527 If the Format attribute is 'BASE64' or 'BINARY', this value
528 indicates the minimum number of bytes of the unencoded value.
530 Value MUST be:
532 Unsigned integer.
534 4. Max (MANDATORY)
536 Defines the maximum size of the challenge accepted by the
537 device for CR mode.
539 If the Format attribute is 'DECIMAL','HEXADECIMAL' or
540 'ALPHANUMERIC' this value indicates the maximum number of
541 digits/characters.
543 If the Format attribute is 'BASE64' or 'BINARY', this value
544 indicates the maximum number of bytes of the unencoded value.
546 Value MUST be:
548 Unsigned integer.
550 5.1.10.2. ResponseFormat (MANDATORY)
552 The ResponseFormat attribute defines the characteristics of the
553 result of a computation. This defines the format of the OTP or of
554 the response to a challenge. The Response attribute is defined by
555 the following sub-attributes:
557 1. Format (MANDATORY)
559 Defines the format of the response generated by the device and
560 MUST be one of the values defined in Section 6.6
562 2. CheckDigit (OPTIONAL)
564 Defines if the device needs to append a Luhn check digit to
565 the response. This is only valid if the Format attribute
566 is'DECIMAL'. Value MUST be:
568 TRUE device will append a Luhn check digit to the response.
570 FALSE device will not append a Luhn check digit to the
571 response.
573 3. Length (MANDATORY)
575 Defines the length of the response generated by the device.
577 If the Format attribute is 'DECIMAL','HEXADECIMAL' or
578 'ALPHANUMERIC' this value indicates the number of digits/
579 characters.
581 If the Format attribute is 'BASE64' or 'BINARY', this value
582 indicates the number of bytes of the unencoded value.
584 Value MUST be:
586 Unsigned integer.
588 5.1.10.3. AppProfileId (OPTIONAL)
590 Defines the application profile id related to attributes present on a
591 smart card that have influence when computing a response. An example
592 could be an EMV MasterCard CAP [CAP] application on a card that
593 contains attributes or uses fixed data for a specific batch of cards
594 such as:
596 IAF Internet authentication flag
598 CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA
599 13, VISA14)
600 AIP (Application Interchange Profile), 2 bytes
602 TVR Terminal Verification Result, 5 bytes
604 CVR The card verification result
606 AmountOther
608 TransactionDate
610 TerminalCountryCode
612 TransactionCurrencyCode
614 AmountAuthorised
616 IIPB
618 These values are not contained within attributes in the container but
619 are shared between the manufacturing and the validation service
620 through this unique AppProfileId.
622 6. Key container XML schema definitions
624 The portable key container is defined by the following entities:
626 1. KeyContainer entity
628 2. Device entity
630 3. Key entity
632 4. User entity
634 A KeyContainer MAY contain one or more Device entities. A Device MAY
635 contain one or more Key entities and may be associated to one or more
636 User entities.
638 The figure below indicates a possible relationship diagram of a
639 container.
641 --------------------------------------------
642 | KeyContainer |
643 | |
644 | ------------------ ----------------- |
645 | | Device 1 | | Device n | |
646 | | | | | |
647 | | ------------ | | ------------ | |
648 | | | Key 1 | | | | Key n | | |
649 | | ------------ | | ------------ | |
650 | | | | | |
651 | | | | | |
652 | | ------------ | | ------------ | |
653 | | | Key m | | | | Key p | | |
654 | | ------------ | | ------------ | |
655 | ------------------ ----------------- |
656 | | | | |
657 | | | | |
658 | ---------- ---------- ---------- |
659 | | User 1 | | User 1 | | User n | |
660 | ---------- ---------- ---------- |
661 | |
662 --------------------------------------------
664 6.1. XML Schema Types
666 The following types are defined to represent the portable key
667 container entities and associated attributes.
669 6.1.1. KeyType
671 The KeyType represents the key entity in the KeyContainer. The
672 KeyType is defined as follows:
674
675
676
677
678
679
681
682
683
684
685
687
688
689
690
691
692
693
694
695
697
698
700 The components of the KeyType have the following meanings (see
701 Section 5 for further information):
703 o of type UsageType defines the usage of the Secret Key. The
704 Usage attribute is described in Section 5.1.3.
706 o identifies the issuer of the Secret Key. The Issuer
707 attribute is described in Section 5.1.5.
709 o is a user friendly name that is assigned to the
710 Secret Key for easy reference.
712 o conveys the data attributes (eg the Secret Key) in name
713 (string) value (base64 encoded) pairs. The value can be
714 encrypted, in this case a digest of the non-encrypted data is
715 present. The component is further described below.
717 o Defines the rules for accessing the credential on
718 the device e.g. a password must be provided by the user to view
719 credential info or use the credential to generate an OTP response
721 o KeyId is a global identifier of the Secret Key. See Section 5.1.4.
723 o KeyAlgorithm defines the algorithm used with the Secret Key. The
724 type values are defined in Section 6.5. If 'OTHER' is specified
725 an extension value MUST be set in the 'ext-KeyAlgorithm'
726 attribute.
728 o ext-KeyAlgorithm is the extension point for KeyAlgorithms not
729 already defined Section 6.5
731 o Logo of type LogoType associates display logos with this Secret
732 Key
734 o Expiry defines the expiry date of the Secret Key in format DD/MM/
735 YYYY
737 The element is of type and is defined as follows:
739
740
741
742
743
744
745
747 The 'Name' attribute defines the name of the name-value pair, the
748 follwoing list of attribute names have been reserved:
750 SECRET: the key key value in binary, base64 encoded
752 COUNTER: the event counter for event based OTP algorithms. 8 bytes
753 unsigned integer in big endian (i.e. network byte order) form
754 base64 encoded
756 TIME: the time for time based OTP algorithms. 8 bytes unsigned
757 integer in big endian (i.e. network byte order) form base64
758 encoded (Number of seconds since 1970)
760 TIME_INTERVAL: the time interval value for time based OTP
761 algorithms. 8 bytes unsigned integer in big endian (i.e. network
762 byte order) form base64 encoded.
764 The element in the DataType conveys the value of the name-
765 value pair in base 64 encoding. The value MAY be encrypted or in
766 clear text as per the EncryptionMethod data element in the
767 KeyContainer (see Section 6.1.6 for details about KeyContainerType).
768 When the value is encrypted, the digest value in 'ValueDigest' MUST
769 be provided. The digest MUST be calculated on the unencrypted value
770 and MUST use one of the Digest algorithms specified in
771 DigestMethodType element of the KeyContainer. The MAC key for the
772 MAC calculation should use the same key as the encryption key
773 specified in the EncryptionMethod unless a separate MAC key is
774 specified. When PBE method is used for encryption, a different
775 password is recommended for the MAC key derivation. When the key
776 data is in clear text, the KeyContainer payload signature MAY be used
777 to check the integrity of the key octets.
779 6.1.2. UsageType
781 The UsageType defines the usage attribute of the key entity. The
782 UsageType is defined as follows:
784
785
786
788
789
790
792
794
796
797
798
799
800
802
803
804
806
807
808
809
810
812
814
815
816
817
819 The UsageType components have the following meanings:
821 o the AlgorithmIdentifier as defined in
822 [OCRA]].
824 o holds the algorithm response attributes.
826 o hold the challenge attributes in CR based
827 algorithm computations.
829 o Is the unique shared identifier for out of band
830 shared common parameters.
832 6.1.3. DeviceType
834 The DeviceType type represents the Device entity in the Container. A
835 Device MAY be bound to a user and MAY contain more than one keys. It
836 is recommended that a key is bound to one and only one Device.
838 The DeviceType is defined as follows:
840
841
842
844
846
847
848
850 The components of the DeviceType have the following meanings:
852 o , a unique identifier for the device, defined by the
853 DeviceId type.
855 o , represents the key entity defined by the KeyType.
857 o , optionally identifies the owner or the user of the Device,
858 as defined by the UserType .
860 6.1.4. DeviceIdType
862 The DeviceId type represents the identifying criteria to uniquely
863 identify the device that contains the associated keys. Since devices
864 can come in different form factors such as hardware tokens,
865 smartcards, soft tokens in a mobile phone or PC etc this type allows
866 different criteria to be used. Combined though the criteria MUST
867 uniquely identify the device. For example for hardware tokens the
868 combination of SerialNo and Manufacturer will uniquely identify a
869 device but not serialNo alone since two different token manufacturers
870 might issue devices with the same serialnumber (similar to the
871 IssuerDN and serialnumber of a certificate). For keys hold on
872 banking cards the identification of the device is often done via the
873 Primary Account Number (PAN, the big number printed on the front of
874 the card) and an expiry date of the card. DeviceId is an extensible
875 type that allows all these different ways to uniquely identify a
876 specific key containing device.
878 The DeviceIdType is defined as follows:
880
881
882
883
884
885
886
887
888
890 The components of the DeviceId type have the following meanings:
892 o , the manufacturer of the device.
894 o , the model of the device (e.g one-button-HOTP-token-V1)
896 o , the serial number of the device or the PAN (primary
897 account number) in case of EMV (Europay-MasterCard-Visa) smart
898 cards.
900 o , the issue number in case of smart cards with the same
901 PAN, equivalent to a PSN (PAN Sequence Number).
903 o , the expiry date of a device (such as the one on an EMV
904 card,used when issue numbers are not printed on cards). In format
905 DD/MM/YYYY
907 6.1.5. UserType Type
909 The UserType represents the identifying criteria to uniquely identify
910 the user who is bound to this device.
912 The UserType is defined as follows:
914
915
916
917
918
919
920
921
922
923
925 The components of the UserType type have the following meanings:
927 o , user first name.
929 o , user last name.
931 o , user id (UID) or user name.
933 o , user organization name.
935 6.1.6. KeyContainerType
937 The KeyContainerType represents the key container entity. A
938 Container MAY contain more than one Device entity; each Device entity
939 MAY contain more than one Key entity.
941 The KeyContainerType is defined as follows:
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
961
963
964
966
968 The components of the KeyContainer have the following meanings:
970 o version, the version number for the portable key container format
971 (the XML schema defined in this document).
973 o , the encryption method used to protect the Key
974 data attributes
976 o , the digest method used to sign the unencrypted the
977 Secret Key data attributes
979 o , the host Device for one or more Keys.
981 o , contains the signature value of the Container. When
982 the signature is applied to the entire container, it MUST use XML
983 Signature methods as defined in [XMLSIG]. The signature is
984 enveloped.
986 6.1.7. EncryptionMethodType
988 The EncryptionMethodType defines the algorithm and parameters used to
989 encrypt the Secret Key data attributes in the Container. The
990 encryption is applied on each individual Secret Key data in the
991 Container. The encryption method MUST be the same for all Secret Key
992 data in the container.
994 The EncryptionMethodType is defined as follows:
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1013
1014
1016 The components of the EncryptionMethodType have the following
1017 meanings:
1019 o algorithm: identifies the encryption algorithm used to protect the
1020 Secret Key data. When 'NONE' is specified, implementations MUST
1021 guarantee the privacy of the Secret Key Data through other
1022 mechanisms e.g. through transport level security. If 'OTHER' is
1023 specified an extension value MUST be set in the 'ext-algorithm'
1024 attribute. Please see EncryptionAlgorithmType for more
1025 information on supported algorithms
1027 o : conveys the Salt when [PKCS5] password-based encryption
1028 is applied.
1030 o : conveys the iteration count value in [PKCS5]
1031 password-based encryption if it is different from the default
1032 value.
1034 o : conveys the initialization vector for CBC based encryption
1035 algorithms. It is recommended for security reasons to transmit
1036 this value out of band and treat it the same manner as the key
1037 value.
1039 o : identifies a unique label for a pre-shared
1040 encryption key.
1042 o : conveys the information of the key if an RSA algorithm
1043 has been used.
1045 o : conveys the OAEP parameters if an RSA algorithm has
1046 been used.
1048 6.1.8. DigestMethodType
1050 The DigestMethodType defines the algorithm and parameters used to
1051 create the digest on the unencrypted Secret Key data in the
1052 Container. The digest is applied on each individual Secret Key data
1053 in the Container before encryption. The digest method MUST be the
1054 same for all Secret Key data in the container. Unless a different
1055 digest key is specified it is assumed that keyed digest algorithms
1056 will use the same key as for encryption
1058 The DigestMethodType is defined as follows:
1060
1061
1062
1063
1064
1066
1068 The components of the DigestMethodType have the following meanings:
1070 o algorithm, identifies the digest algorithm used to protect the
1071 Secret Key data. Please see DigestAlgorithmType for more
1072 information on supported algorithms
1074 o : identifies a unique label for a pre-shared
1075 digest key.
1077 6.1.9. AlgorithmIdentifierType
1079 The AlgorithmIdentiferType defines the Algorithm identifier (AI)
1080 specified in [OCRA].
1082 The AlgorithmIdentifierType is defines as follows:
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1111 See [OCRA] for a full description of the components of the
1112 AlgorithmIdentifierType.
1114 6.2. EncryptionAlgorithmType
1116 The EncryptionAlgorithmType defines the allowed algorithms for
1117 encrypting the Secret Key data in the Container.
1119 The EncryptionAlgorithmType is defined as follows:
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1140 NONE when no encryption is applied on the key
1142 PBE-3DES112-CBC when password-based encryption is applied using a
1143 112-bit 3DES key in CBC mode
1145 PBE-3DES168-CBC when password-based encryption is applied using a
1146 168-bit 3DES key in CBC mode
1148 PBE-AES128-CBC when password-based encryption is applied using a
1149 128-bit AES key in CBC mode
1151 PBE-AES192-CBC when password-based encryption is applied using a
1152 192-bit AES key in CBC mode is applied.
1154 PBE-AES256-CBC password-based encryption is applied using a 256-
1155 bit AES key in CBC mode is applied.
1157 3DES112-CBC encryption using a pre-shared 112-bit 3DES key in CBC
1158 mode is applied.
1160 3DES168-CBC encryption using a pre-shared 168-bit 3DES key in CBC
1161 mode is applied.
1163 AES128-CBC encryption using a pre-shared 128-bit AES key in CBC
1164 mode is applied.
1166 AES192-CBC encryption using a pre-shared 192-bit AES key in CBC
1167 mode is applied.
1169 AES256-CBC encryption using a pre-shared 256-bit AES key in CBC
1170 mode is applied.
1172 RSA-1_5 The RSAES-PKCS1-v1_5 algorithm, specified in [PKCS1],
1173 takes no explicit parameters.
1175 RSA-OAEP-MGF1P The same algorithm as defined in section 5.4.2 RSA-
1176 OAEP in [XMLENC] It is the RSAES-OAEP-ENCRYPT algorithm, as
1177 specified in [PKCS1], it takes three parameters. The two user
1178 specified parameters are a MANDATORY message digest function and
1179 an OPTIONAL encoding octet string OAEPparams. The message digest
1180 function is indicated by the Algorithm attribute of a child ds:
1181 DigestMethod element and the mask generation function, the third
1182 parameter, is always MGF1 with SHA1 (mgf1SHA1Identifier).
1184 OTHER extension point for not already defined algorithms in this
1185 list.
1187 6.3. HashAlgorithmType
1189 The HashAlgorithmType defines the allowed algorithms for generating a
1190 digest in the RSA algorithms.
1192 The HashAlgorithmType is defined as follows:
1194
1195
1196
1197
1198
1199
1200
1202 SHA1 when the digest was performed using the SHA1 algorithm
1204 SHA256 when the digest was performed using the SHA256 algorithm
1206 SHA512 when the digest was performed using the SHA512 algorithm
1208 6.4. DigestAlgorithmType
1210 The DigestAlgorithmType defines the allowed algorithms for generating
1211 a digest on the unencrypted Secret Key data in the Container.
1213 The DigestAlgorithmType is defined as follows:
1215
1216
1217
1218
1219
1220
1221
1222
1224 HMAC-SHA1 when the digest was performed using the HMAC-SHA1
1225 algorithm
1227 HMAC-SHA256 when the digest was performed using the HMAC-SHA256
1228 algorithm
1230 HMAC-SHA512 when the digest was performed using the HMAC-SHA512
1231 algorithm
1233 OTHER extension point for not already defined algorithms in this
1234 list.
1236 6.5. KeyAlgorithmType
1238 The KeyAlgorithmType defines the algorithms in which the Secret Key
1239 data is used.
1241 The KeyAlgorithmType is defined as follows:
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1261 3DES112, a 112-bit 3DES key (a.k.a. two-key 3DES)
1263 3DES168, a 168-bit parity-checked 3DES key
1265 ACTI, algorithm family from ActivIdentity
1267 AES128, a 128-bit AES key
1269 AES192, a 192-bit AES key
1271 AES256, a 256-bit AES key
1273 ANSIX9.9, ANSI X9.9 algorithm
1275 DES, a standard DES key
1277 HOTP, as defined in [HOTP]
1279 MKEYLABEL, master key abel or name when an embedded device key is
1280 used to derive the Key
1282 RSASECUREID, SecureId algorithm family from RSA
1284 VASCO, algorithm family from Vasco
1286 OTHER extension point for not already defined algorithms in this
1287 list.
1289 6.6. valueFormat
1291 The valueFormat defines allowed formats for challenges or responses
1292 in the OTP algorithms.
1294 The valueFormat is defined as follows:
1296
1297
1298
1299
1300
1301
1302
1303
1304
1306 DECIMAL Only numerical digits
1308 HEXADECIMAL Hexadecimal response
1310 ALPHANUMERIC All letters and numbers (case sensitive)
1312 BASE64 Base 64 encoded
1314 BINARY Binary data, this is mainly used in case of connected
1315 devices
1317 6.7. Data elements
1319 6.7.1. KeyContainer
1321 The KeyContainer data element is defined as:
1323
1325 The KeyContainer data element is of type KeyContainerType defined in
1326 Section 6.1.6.
1328 The EncryptionMethod data element in the KeyContainer defines the
1329 encryption algorithm used to protect the Key data. In a multi-key
1330 KeyContainer, the same encryption method and the same encryption key
1331 MUST be used for all key data elements.
1333 The KeyContainer data element MAY contain multiple Device data
1334 elements, allowing for bulk provisioning of keys.
1336 The Signature data element is of type as defined in
1337 [XMLSIG] and MAY be omitted in the KeyContainer data element when
1338 application layer provisioning or transport layer provisioning
1339 protocols provide the integrity and authenticity of the payload
1340 between the sender and the recipient of the container. When
1341 required, this specification recommends using a symmetric key based
1342 signature with the same key used in the encryption of the secret key
1343 data. The signature is enveloped.
1345 7. Formal Syntax
1347 The following syntax specification uses the widely adopted XML schema
1348 format as defined by a W3C recommendation
1349 (http://www.w3.org/TR/xmlschema-0/). It is a complete syntax
1350 definition in the XML Schema Definition format (XSD)
1352 All implentations of this standard must comply with the schema below.
1354
1355
1361
1364
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1384
1386
1387
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1401
1402
1403
1404
1405
1406
1407
1408
1409
1411
1413
1415
1417
1419
1420
1421
1422
1423
1424
1425
1427
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1440
1441
1442
1443
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1460
1462
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1480
1481
1482
1484
1485
1486
1487
1488
1489
1490
1492
1493
1494
1496
1497
1498
1499
1500
1501
1503
1505
1507
1509
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1526
1528
1529
1530
1532
1534
1535
1536
1537
1538
1540
1541
1542
1543
1544
1545
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
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
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1615
1616
1617
1618
1620
1621
1623
1624
1626 8. Security Considerations
1628 The portable key container carries sensitive information (e.g.,
1629 cryptographic keys) and may be transported across the boundaries of
1630 one secure perimeter to another. For example, a container residing
1631 within the secure perimeter of a back-end provisioning server in a
1632 secure room may be transported across the internet to an end-user
1633 device attached to a personal computer. This means that special care
1634 must be taken to ensure the confidentiality, integrity, and
1635 authenticity of the information contained within.
1637 8.1. Payload confidentiality
1639 By design, the container allows two main approaches to guaranteeing
1640 the confidentiality of the information it contains while transported.
1642 First, the container key data payload may be encrypted.
1644 In this case no transport layer security is required. However,
1645 standard security best practices apply when selecting the strength of
1646 the cryptographic algorithm for payload encryption. Symmetric
1647 cryptographic cipher should be used - the longer the cryptographic
1648 key, the stronger the protection. At the time of this writing both
1649 3DES and AES are recommended algorithms but 3DES may be dropped in
1650 the relatively near future. Applications concerned with algorithm
1651 longevity are advised to use AES. In cases where the exchange of
1652 encryption keys between the sender and the receiver is not possible,
1653 asymmetric encryption of the secret key payload may be employed.
1654 Similarly to symmetric key cryptography, the stronger the asymmetric
1655 key, the more secure the protection is.
1657 If the payload is encrypted with a method that uses one of the
1658 password-based encryption methods provided above, the payload may be
1659 subjected to password dictionary attacks to break the encryption
1660 password and recover the information. Standard security best
1661 practices for selection of strong encryption passwords apply
1662 [Schneier].
1664 Practical implementations should use PBESalt and PBEIterationCount
1665 when PBE encryption is used. Different PBESalt value per credential
1666 record should be used for best protection.
1668 The second approach to protecting the confidentiality of the payload
1669 is based on using transport layer security. The secure channel
1670 established between the source secure perimeter (the provisioning
1671 server from the example above) and the target perimeter (the device
1672 attached to the end-user computer) utilizes encryption to transport
1673 the messages that travel across. No payload encryption is required
1674 in this mode. Secure channels that encrypt and digest each message
1675 provide an extra measure of security, especially when the signature
1676 of the payload does not encompass the entire payload.
1678 Because of the fact that the plain text payload is protected only by
1679 the transport layer security, practical implementation must ensure
1680 protection against man-in-the-middle attacks [Schneier]. Validating
1681 the secure channel end-points is critically important for eliminating
1682 intruders that may compromise the confidentiality of the payload.
1684 8.2. Payload integrity
1686 The portable symmetric key container provides a mean to guarantee the
1687 integrity of the information it contains through digital signatures.
1688 For best security practices, the digital signature of the container
1689 should encompass the entire payload. This provides assurances for
1690 the integrity of all attributes. It also allows verification of the
1691 integrity of a given payload even after the container is delivered
1692 through the communication channel to the target perimeter and channel
1693 message integrity check is no longer possible.
1695 8.3. Payload authenticity
1697 The digital signature of the payload is the primary way of showing
1698 its authenticity. The recipient of the container may use the public
1699 key associated with the signature to assert the authenticity of the
1700 sender by tracing it back to a preloaded public key or certificate.
1701 Note that the digital signature of the payload can be checked even
1702 after the container has been delivered through the secure channel of
1703 communication.
1705 A weaker payload authenticity guarantee may be provided by the
1706 transport layer if it is configured to digest each message it
1707 transports. However, no authenticity verification is possible once
1708 the container is delivered at the recipient end. This approach may
1709 be useful in cases where the digital signature of the container does
1710 not encompass the entire payload.
1712 9. Acknowledgements
1714 The authors of this draft would like to thank the following people
1715 for their contributions and support to make this a better
1716 specification: Apostol Vassilev, Jon Martinson, Siddhart Bajaj, Stu
1717 Veath, Kevin Lewis, and Andrea Doherty.
1719 10. Appendix A - Example Symmetric Key Containers
1721 All examples are syntactically correct and compatible with the XML
1722 schema in section 7. However, , Key and Key
1723 data values are fictitious
1725 10.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret
1726 Key
1728
1729
1736
1737
1738
1739
1740 Token Manufacturer
1741 98765432187
1742 01/01/2008
1743
1744
1745 Credential Issuer
1746
1747
1748
1749 MyFirstToken
1750
1751 WldjTHZwRm9YTkhBRytseDMrUnc=
1752 WldjTHZwRm9YTkhBRytseDM=
1753
1754
1755 WldjTHZwRm9YTkhBRytseDMrUnc=
1756 WldjTHZwRm9YTkhBRytseDM=
1757
1758
1759
1760
1762 10.2. Symmetric Key Container with a single Password-based Encrypted
1763 HOTP Secret Key
1765
1766
1773
1774 y6TzckeLRQw=
1775 999
1776
1777
1778
1779
1780 Token Manufacturer
1781 98765432187
1782 01/01/2008
1783
1784
1785 Credential Issuer
1786
1787
1788
1789 MySecondToken
1790
1791 7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA==
1792 WldjTHZwRm9YTkhBRytseDMrUnc=
1793
1794
1795 7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA==
1796 WldjTHZwRm9YTkhBRytseDMrUnc=
1797
1798
1799
1800
1802 11. Normative References
1804 [CAP] MasterCard International, "Chip Authentication Program
1805 Functional Architecture", September 2004.
1807 [DSKPP] "Dynamic Symmetric Key Provisioning Protocol", Internet
1808 Draft Informational, URL: http://tools.ietf.org/wg/
1809 keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007.
1811 [HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password
1812 Algorithm", RFC 4226,
1813 URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
1814 December 2005.
1816 [OATH] "Initiative for Open AuTHentication",
1817 URL: http://www.openauthentication.org.
1819 [OATHRefArch]
1820 OATH, "Reference Architecture",
1821 URL: http://www.openauthentication.org, Version 1.0, 2005.
1823 [OCRA] MRaihi, D., "OCRA: OATH Challenge Response Algorithm",
1824 Internet Draft Informational, URL: http://www.ietf.org/
1825 internet-drafts/
1826 draft-mraihi-mutual-oath-hotp-variants-01.txt,
1827 December 2005.
1829 [PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
1830 Specifications Version 2.0.",
1831 URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,
1832 October 1998.
1834 [PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange
1835 Syntax Standard", Version 1.0,
1836 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/.
1838 [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
1839 Standard", Version 2.0,
1840 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/,
1841 March 1999.
1843 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1844 Requirement Levels", BCP 14, RFC 2119, March 1997.
1846 [Schneier]
1847 Schneier, B., "Secrets and Lies: Digitial Security in a
1848 Networked World", Wiley Computer Publishing, ISBN 0-8493-
1849 8253-7, 2000.
1851 [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
1852 URL: http://www.w3.org/TR/xmlenc-core/, December 2002.
1854 [XMLSIG] Eastlake, D., "XML-Signature Syntax and Processing",
1855 URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
1856 W3C Recommendation, February 2002.
1858 Authors' Addresses
1860 Philip Hoyer
1861 ActivIdenity, Inc.
1862 109 Borough High Street
1863 London, SE1 1NL
1864 UK
1866 Phone: +44 (0) 20 7744 6455
1867 Email: Philip.Hoyer@actividentity.com
1869 Mingliang Pei
1870 VeriSign, Inc.
1871 487 E. Middlefield Road
1872 Mountain View, CA 94043
1873 USA
1875 Phone: +1 650 426 5173
1876 Email: mpei@verisign.com
1878 Salah Machani
1879 Diversinet, Inc.
1880 2225 Sheppard Avenue East
1881 Suite 1801
1882 Toronto, Ontario M2J 5C2
1883 Canada
1885 Phone: +1 416 756 2324 Ext. 321
1886 Email: smachani@diversinet.com
1888 Shuh Chang
1889 Gemalto Inc.
1891 Email: shuh.chang@gemalto.com
1893 Full Copyright Statement
1895 Copyright (C) The IETF Trust (2007).
1897 This document is subject to the rights, licenses and restrictions
1898 contained in BCP 78, and except as set forth therein, the authors
1899 retain all their rights.
1901 This document and the information contained herein are provided on an
1902 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1903 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1904 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1905 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1906 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1907 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1909 Intellectual Property
1911 The IETF takes no position regarding the validity or scope of any
1912 Intellectual Property Rights or other rights that might be claimed to
1913 pertain to the implementation or use of the technology described in
1914 this document or the extent to which any license under such rights
1915 might or might not be available; nor does it represent that it has
1916 made any independent effort to identify any such rights. Information
1917 on the procedures with respect to rights in RFC documents can be
1918 found in BCP 78 and BCP 79.
1920 Copies of IPR disclosures made to the IETF Secretariat and any
1921 assurances of licenses to be made available, or the result of an
1922 attempt made to obtain a general license or permission for the use of
1923 such proprietary rights by implementers or users of this
1924 specification can be obtained from the IETF on-line IPR repository at
1925 http://www.ietf.org/ipr.
1927 The IETF invites any interested party to bring to its attention any
1928 copyrights, patents or patent applications, or other proprietary
1929 rights that may cover technology that may be required to implement
1930 this standard. Please address the information to the IETF at
1931 ietf-ipr@ietf.org.
1933 Acknowledgment
1935 Funding for the RFC Editor function is provided by the IETF
1936 Administrative Support Activity (IASA).