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).