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