idnits 2.17.1
draft-ietf-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 20.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1839.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1850.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1857.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1863.
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 (November 6, 2007) is 6014 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 1747, but no explicit
reference was found in the text
== Unused Reference: 'OATHRefArch' is defined on line 1750, but no explicit
reference was found in the text
== Unused Reference: 'OCRA' is defined on line 1754, but no explicit
reference was found in the text
== Unused Reference: 'PKCS1' is defined on line 1760, but no explicit
reference was found in the text
== Unused Reference: 'XMLENC' is defined on line 1783, 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 (~~), 7 warnings (==), 16 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 keyprov P. Hoyer
3 Internet-Draft ActivIdentity
4 Intended status: Standards Track M. Pei
5 Expires: May 9, 2008 VeriSign
6 S. Machani
7 Diversinet
8 S. Chang
9 Gemalto
10 November 6, 2007
12 Portable Symmetric Key Container
13 draft-ietf-keyprov-portable-symmetric-key-container-02.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 May 9, 2008.
40 Copyright Notice
42 Copyright (C) The IETF Trust (2007).
44 Abstract
46 This document specifies a symmetric key format for transport and
47 provisioning of symmetric keys (One Time Password (OTP) shared
48 secrets or symmetric cryptographic keys) to different types of strong
49 authentication devices. The standard token format enables
50 enterprises to deploy best-of-breed solutions combining components
51 from different vendors into the same infrastructure.
53 This work is a joint effort by the members of OATH (Initiative for
54 Open AuTHentication) to specify a format that can be freely
55 distributed to the technical community. The authors believe that a
56 common and shared specification will facilitate adoption of two-
57 factor authentication on the Internet by enabling interoperability
58 between commercial and open-source implementations.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. Conventions used in this document . . . . . . . . . . . . . . 5
64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
65 3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6
66 3.1.1. Credential migration by end-user . . . . . . . . . . . 6
67 3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6
68 3.1.3. Bulk migration of existing credentials . . . . . . . . 6
69 3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7
70 3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7
71 3.2.1. Online provisioning a credential to end-user's
72 authentication token . . . . . . . . . . . . . . . . . 7
73 3.2.2. Server to server provisioning of credentials . . . . . 8
74 3.2.3. Online update of an existing authentication token
75 credential . . . . . . . . . . . . . . . . . . . . . . 8
76 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
77 5. Symmetric Key Attributes . . . . . . . . . . . . . . . . . . . 11
78 5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11
79 5.1.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11
80 5.1.2. KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11
81 5.1.3. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 12
82 5.1.4. KeyId (MANDATORY) . . . . . . . . . . . . . . . . . . 13
83 5.1.5. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 13
84 5.1.6. FriendlyName (OPTIONAL) . . . . . . . . . . . . . . . 13
85 5.1.7. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 13
86 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute
87 is encrypted)) . . . . . . . . . . . . . . . . . . . . 13
88 5.1.9. DigestMethod (MANDATORY when Digest is present) . . . 14
89 5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 14
90 5.1.11. Logo (OPTIONAL) . . . . . . . . . . . . . . . . . . . 17
92 6. Key container XML schema definitions . . . . . . . . . . . . . 18
93 6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 18
94 6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 19
95 6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 21
96 6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22
97 6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 23
98 6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 24
99 6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 25
100 6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 26
101 6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 28
102 6.2. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 29
103 6.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . . . 29
104 6.4. Data elements . . . . . . . . . . . . . . . . . . . . . . 29
105 6.4.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 29
106 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 31
107 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39
108 8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 39
109 8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 40
110 8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 40
111 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
112 10. Appendix A - Example Symmetric Key Containers . . . . . . . . 42
113 10.1. Symmetric Key Container with a single Non-Encrypted
114 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 42
115 10.2. Symmetric Key Container with a single Password-based
116 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 42
117 11. Normative References . . . . . . . . . . . . . . . . . . . . . 44
118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
119 Intellectual Property and Copyright Statements . . . . . . . . . . 47
121 1. Introduction
123 With increasing use of symmetric key based authentication systems
124 such as systems based one time password (OTP) and challenge response
125 mechanisms, there is a need for vendor interoperability and a
126 standard format for importing, exporting or provisioning symmetric
127 key based credentials from one system to another. Traditionally
128 authentication server vendors and service providers have used
129 proprietary formats for importing, exporting and provisioning these
130 credentials into their systems making it hard to use tokens from
131 vendor A with a server from vendor B.
133 This Internet draft describes a standard format for serializing
134 symmetric key based credentials such as OTP shared secrets for system
135 import, export or network/protocol transport. The goal is that the
136 format will facilitate dynamic provisioning and transfer of a
137 symmetric key such as an OTP shared secret or an encryption key of
138 different types. In the case of OTP shared secrets, the format will
139 facilitate dynamic provisioning using an OTP provisioning protocol to
140 different flavors of embedded tokens for OTP credentials or allow
141 customers to import new or existing tokens in batch or single
142 instances into a compliant system.
144 This draft also specifies the token attributes required for
145 interoperability such as the initial event counter used in the HOTP
146 algorithm [HOTP]. It is also applicable for other time-based or
147 proprietary algorithms.
149 To provide an analogy, in public key environments the PKCS#12 format
150 [PKCS12] is commonly used for importing and exporting private keys
151 and certificates between systems. In the environments outlined in
152 this document where OTP credentials may be transported directly down
153 to smartcards or devices with limited computing capabilities, a
154 format with small (size in bytes) and explicit shared secret
155 configuration attribute information is desirable, avoiding complexity
156 of PKCS#12. For example, one would have to use opaque data within
157 PKCS#12 to carry shared secret attributes used for OTP calculations,
158 whereas a more explicit attribute schema definition is better for
159 interoperability and efficiency.
161 2. Conventions used in this document
163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
165 document are to be interpreted as described in [RFC2119].
167 In examples, "C:" and "S:" indicate lines sent by the client and
168 server respectively.
170 In the text below, OTP refers to one time password.
172 3. Use Cases
174 This section describes a comprehensive list of use cases that
175 inspired the development of this specification. These requirements
176 were used to derive the primary requirement that drove the design.
177 These requirements are covered in the next section.
179 These use cases also help in understanding the applicability of this
180 specification to real world situations.
182 3.1. Offline Use Cases
184 This section describes the use cases relating to offline transport of
185 credentials from one system to another, using some form of export and
186 import model.
188 3.1.1. Credential migration by end-user
190 A user wants to migrate a credential from one authentication token
191 (container) to a different authentication token. For example, the
192 authentication tokens may be soft tokens on two different systems
193 (computers or mobile phones). The user can export the credential in
194 a standard format for import into the other authentication token.
196 The key protection mechanism may rely on password-based encryption
197 for soft tokens, a pre-placed hardware-protected transfer key shared
198 between the two systems or may also rely on asymmetric keys/ PKI if
199 available.
201 3.1.2. Bulk import of new credentials
203 Tokens are manufactured in bulk and associated credentials (key
204 records) need to be loaded into the validation system through a file
205 on portable media. The manufacturer provides the credentials in the
206 form of a file containing records in standard format, typically on a
207 CD. Note that the token manufacturer and the vendor for the
208 validation system may be the same or different.
210 In this case the file usually is protected by a symmetric transport
211 key which was communicated separately outside of the file between the
212 two parties.
214 3.1.3. Bulk migration of existing credentials
216 An enterprise wants to port credentials from an existing validation
217 system A into a different validation system B. The existing
218 validation system provides the enterprise with a functionality that
219 enables export of credentials (OTP tokens) in a standard format.
221 Since the OTP tokens are in the standard format, the enterprise can
222 import the token records into the new validation system B and start
223 using the existing tokens. Note that the vendors for the two
224 validation systems may be the same or different.
226 In this case the file usually is protected by a symmetric transport
227 key which was communicated separately outside of the file between the
228 two validation systems.
230 3.1.4. Credential upload case
232 User wants to activate and use a new credential against a validation
233 system that is not aware of this credential. This credential may be
234 embedded in the authentication token (e.g. SD card, USB drive) that
235 the user has purchased at the local electronics retailer. Along with
236 the authentication token, the user may get the credential on a CD or
237 a floppy in a standard format. The user can now upload via a secure
238 online channel or import this credential into the new validation
239 system and start using the credential.
241 The key protection mechanism may rely on password-based encryption,
242 or a pre-placed hardware-protected transfer key shared between the
243 token manufacturer and the validation system(s) if available.
245 3.2. Online Use Cases
247 This section describes the use cases related to provisioning the
248 credentials using some form of a online provisioning protocol.
250 3.2.1. Online provisioning a credential to end-user's authentication
251 token
253 A mobile device user wants to obtain an OTP credential (shared
254 secret) for use with an OTP soft token on the device. The soft token
255 client from vendor A initiates the provisioning process against a
256 provisioning system from vendor B using a standards-based
257 provisioning protocol such as [DSKPP]. The provisioning system
258 delivers one or more OTP credential(s) in a standard format that can
259 be processed by the mobile device. The user can download a payload
260 that contains more than one credential.
262 In a variation of the above, instead of the user's mobile phone, a
263 credential is provisioned in the user's soft token application on a
264 laptop using a network-based online protocol. As before, the
265 provisioning system delivers an OTP credential in a standard format
266 that can be processed by the soft token on the PC.
268 3.2.2. Server to server provisioning of credentials
270 Sometimes, instead of importing token information from manufacturer
271 using a file, an OTP validation server may download the credential
272 seed records using an online protocol. The credentials can be
273 downloaded in a standard format that can be processed by a validation
274 system.
276 In another scenario, an OTA (over-the-air) credential provisioning
277 gateway that provisions credentials to mobile phones may obtain
278 credentials from the credential issuer using an online protocol. The
279 credentials are delivered in a standard format that can be processed
280 by the OTA credential provisioning gateway and subsequently sent to
281 the end-user's mobile phone.
283 3.2.3. Online update of an existing authentication token credential
285 The end-user or the credential issuer wants to update or configure an
286 existing credential in the authentication token and requests a
287 replacement credential container. The container may or may not
288 include a new secret key and may include new or updated secret key
289 attributes such as a new counter value in HOTP credential case, a new
290 logo, a modified response format or length, a new friendly name, etc.
292 4. Requirements
294 This section outlines the most relevant requirements that are the
295 basis of this work. Several of the requirements were derived from
296 use cases described above.
298 R1: The format MUST support transport of multiple types of
299 symmetric key credentials including HOTP, other OTP, challenge-
300 response, etc.
302 R2: The format MUST handle the symmetric key itself as well of
303 attributes that are typically associated with symmetric keys.
304 Some of these attributes may be
306 * Unique Key Identifier
308 * Issuer information
310 * Algorithm ID
312 * Algorithm mode
314 * Issuer Name
316 * Issuer logo
318 * Credential friendly name
320 * Event counter value (moving factor for OTP algorithms)
322 * Time value
324 R3: The format SHOULD support both offline and online scenarios.
325 That is it should be serializable to a file as well as it
326 should be possible to use this format in online provisioning
327 protocols
329 R4: The format SHOULD allow bulk representation of symmetric key
330 credentials.
332 R5: The format SHOULD be portable to various platforms.
333 Furthermore, it SHOULD be computationally efficient to process.
335 R6: The format MUST provide appropriate level of security in terms
336 of data encryption and data integrity.
338 R7: For online scenarios the format SHOULD NOT rely on transport
339 level security (e.g., SSL/TLS) for core security requirements.
341 R8: The format SHOULD be extensible. It SHOULD enable extension
342 points allowing vendors to specify additional attributes in the
343 future.
345 R9: The format SHOULD allow for distribution of key derivation data
346 without the actual symmetric key itself. This is to support
347 symmetric key management schemes that rely on key derivation
348 algorithms based on a pre-placed master key. The key
349 derivation data typically consists of a reference to the key,
350 rather than the key value itself.
352 R10: The format SHOULD allow for additional lifecycle management
353 operations such as counter resynchronization. Such processes
354 require confidentiality between client and server, thus could
355 use a common secure container format, without the transfer of
356 key material.
358 R11: The format MUST support the use of pre-shared symmetric keys to
359 ensure confidentiality of sensitive data elements.
361 R12: The format MUST support a password-based encryption (PBE)
362 [PKCS5] scheme to ensure security of sensitive data elements.
363 This is a widely used method for various provisioning
364 scenarios.
366 R13: The format SHOULD support asymmetric encryption algorithms such
367 as RSA to ensure end-to-end security of sensitive data
368 elements. This is to support scenarios where a pre-set shared
369 encryption key is difficult to use.
371 5. Symmetric Key Attributes
373 The symmetric key includes a number of data attributes that define
374 the type of the key its usage and associated meta-information
375 required during the provisioning, configuration, access or usage in
376 the host device.
378 5.1. Common Attributes
380 5.1.1. Data (OPTIONAL)
382 Defines the data attributes of the symmetric key. Each is a name
383 value pair which has both a base64 encoded value and a base 64
384 encoded ValueDigest. The value can be encrypted. If the container
385 has been encrypted the ValueDigest MUST be populated with the digest
386 of the unencrypted value.
388 This is also where the key value is held, therefore the following
389 list of attribute names have been reserved:
391 SECRET: the shared secret key value in binary, base64 encoded
393 COUNTER: the event counter for event based OTP algorithms. 8 bytes
394 unsigned integer in big endian (i.e. network byte order) form
395 base64 encoded
397 TIME: the time for time based OTP algorithms. 8 bytes unsigned
398 integer in big endian (i.e. network byte order) form base64
399 encoded (Number of seconds since 1970)
401 TIME_INTERVAL: the time interval value for time based OTP
402 algorithms. 8 bytes unsigned integer in big endian (i.e. network
403 byte order) form base64 encoded.
405 TIME_DRIFT: the device clock drift value for time based OTP
406 algorithms. The value indicates number of seconds that the device
407 clock may drift each day. 2 bytes unsigned integer in big endian
408 (i.e. network byte order) form base64 encoded.
410 5.1.2. KeyAlgorithm (MANDATORY)
412 Defines the type of algorithm of the secret key. The following
413 algorithm URIs are among the default support list.
415 o http://www.w3.org/2001/04/xmlenc#tripledes-cbc
417 o http://www.w3.org/2001/04/xmlenc#aes128-cbc
418 o http://www.w3.org/2001/04/xmlenc#aes192-cbc
420 o http://www.w3.org/2001/04/xmlenc#aes256-cbc
422 o http://www.ietf.org/keyprov/pskc#hotp
424 5.1.2.1. OTP Key Algorithm Identifiers
426 OTP key algorithm URIs have not been defined in a commonly available
427 standard specification. This document defines the following URIs for
428 the known open standard OTP algorithms.
430 5.1.2.1.1. HOTP
432 Standard document: RFC4226
434 Identifier: http://www.ietf.org/keyprov/pskc#hotp
436 Note that the actual URL will be finalized once a URL for this
437 document is determined.
439 5.1.2.1.2. Other OTP Algorithms
441 An implementation should refer to vendor supplied OTP key algorithm
442 URIs for proprietary algorithms.
444 5.1.3. Usage (MANDATORY)
446 Defines the intended usage of the key and is a combination of one or
447 more of the following (set to true):
449 OTP: the key will be used for OTP generation
451 CR: the key will be used for Challenge/Response purposes
453 Encrypt: the key will be used for data encryption purposes
455 Sign: the key will be used to generate a signature or keyed
456 hashing for data integrity or authentication purposes.
458 Unlock: the key will be used for an inverse challenge response in
459 the case a user has locked the device by entering a wrong PIN too
460 many times (for devices with PIN-input capability)
462 Additional attributes that are specific to the usage type MAY be
463 required. Section 6.1 describes OTP and CR specific attributes.
465 5.1.4. KeyId (MANDATORY)
467 A unique and global identifier of the symmetric key. The identifier
468 is defined as a string of alphanumeric characters.
470 5.1.5. Issuer (MANDATORY)
472 The key issuer name, this is normally the name of the organization
473 that issues the key to the end user of the key. For example MyBank
474 issuing hardware tokens to their retail banking users 'MyBank' would
475 be the issuer. The Issuer is defined as a String.
477 5.1.6. FriendlyName (OPTIONAL)
479 The user friendly name that is assigned to the secret key for easy
480 reference. The FriendlyName is defined as a String.
482 5.1.7. AccessRules (OPTIONAL)
484 Defines a set of access rules and policies for the protection of the
485 key on the host Device. Currently only the UserPIN policy is
486 defined. The UserPIN policy specifies whether the user MUST enter a
487 PIN (for devices with PIN input capability) in order to unlock or
488 authenticate to the device hosting the key container. The UserPIN is
489 defined as a Boolean (TRUE or FALSE). When the user PIN is required,
490 the policy MUST be set to TRUE. If the UserPIN is NOT provided,
491 implementations SHALL default the value to FALSE.
493 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute is encrypted))
495 Identifies the encryption algorithm and possible parameters used to
496 protect the Secret Key data in the container. The encryption
497 algorithm URI can be one of the following.
499 o http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2
501 o http://www.w3.org/2001/04/xmlenc#tripledes-cbc
503 o http://www.w3.org/2001/04/xmlenc#aes128-cbc
505 o http://www.w3.org/2001/04/xmlenc#aes192-cbc
507 o http://www.w3.org/2001/04/xmlenc#aes256-cbc
509 o http://www.w3.org/2001/04/xmlenc#rsa-1_5
511 o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
512 o http://www.w3.org/2001/04/xmlenc#kw-tripledes
514 o http://www.w3.org/2001/04/xmlenc#kw-aes128
516 o http://www.w3.org/2001/04/xmlenc#kw-aes256
518 o http://www.w3.org/2001/04/xmlenc#kw-aes512
520 When an PBE algorithm is used for encryption, the URI
521 http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 and the
522 encryption algorithm in PBEEncryptionParamType defines the exact PBE
523 key derivation and encryption algorithms.
525 When the value is not provided, implementations SHALL ensure the
526 privacy of the key data through other standard mechanisms e.g.
527 transport level encryption.
529 When the container (payload) contains more than one key and
530 EncryptionMethod is specified, the same encryption key MUST be used
531 to encrypt all the key data elements in the container.
533 5.1.9. DigestMethod (MANDATORY when Digest is present)
535 Identifies the algorithm and possible parameters used to generate a
536 digest of the the Secret Key data. The digest guarantees the
537 integrity and the authenticity of the key data.
539 See Section 6.1.8 for more information on Digest data value type.
541 5.1.10. OTP and CR specific Attributes (OPTIONAL)
543 When the key usage is set to OTP or CR, additional attributes MUST be
544 provided to support the OTP and/or the response computation as
545 required by the underlying algorithm and to customize or configure
546 the outcome of the computation (format, length and usage modes).
548 5.1.10.1. ChallengeFormat (MANDATORY)
550 The ChallengeFormat attribute defines the characteristics of the
551 challenge in a CR usage scenario. The Challenge attribute is defined
552 by the following sub-attributes:
554 1. Format (MANDATORY)
556 Defines the format of the challenge accepted by the device and
557 MUST be one of the values defined in Section 6.3
559 2. CheckDigit (OPTIONAL)
561 Defines if the device needs to check the appended Luhn check
562 digit contained in a provided challenge. This is only valid
563 if the Format attribute is 'DECIMAL'. Value MUST be:
565 TRUE device will check the appended Luhn check digit in a
566 provided challenge
568 FALSE device will not check appended Luhn check digit in
569 challenge
571 3. Min (MANDATORY)
573 Defines the minimum size of the challenge accepted by the
574 device for CR mode.
576 If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
577 'ALPHANUMERIC' this value indicates the minimum number of
578 digits/characters.
580 If the Format attribute is 'BASE64' or 'BINARY', this value
581 indicates the minimum number of bytes of the unencoded value.
583 Value MUST be:
585 Unsigned integer.
587 4. Max (MANDATORY)
589 Defines the maximum size of the challenge accepted by the
590 device for CR mode.
592 If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
593 'ALPHANUMERIC' this value indicates the maximum number of
594 digits/characters.
596 If the Format attribute is 'BASE64' or 'BINARY', this value
597 indicates the maximum number of bytes of the unencoded value.
599 Value MUST be:
601 Unsigned integer.
603 5.1.10.2. ResponseFormat (MANDATORY)
605 The ResponseFormat attribute defines the characteristics of the
606 result of a computation. This defines the format of the OTP or of
607 the response to a challenge. The Response attribute is defined by
608 the following sub-attributes:
610 1. Format (MANDATORY)
612 Defines the format of the response generated by the device and
613 MUST be one of the values defined in Section 6.3
615 2. CheckDigit (OPTIONAL)
617 Defines if the device needs to append a Luhn check digit to
618 the response. This is only valid if the Format attribute is
619 'DECIMAL'. Value MUST be:
621 TRUE device will append a Luhn check digit to the response.
623 FALSE device will not append a Luhn check digit to the
624 response.
626 3. Length (MANDATORY)
628 Defines the length of the response generated by the device.
630 If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
631 'ALPHANUMERIC' this value indicates the number of digits/
632 characters.
634 If the Format attribute is 'BASE64' or 'BINARY', this value
635 indicates the number of bytes of the unencoded value.
637 Value MUST be:
639 Unsigned integer.
641 5.1.10.3. AppProfileId (OPTIONAL)
643 Defines the application profile id related to attributes present on a
644 smart card that have influence when computing a response. An example
645 could be an EMV MasterCard CAP [CAP] application on a card that
646 contains attributes or uses fixed data for a specific batch of cards
647 such as:
649 IAF Internet authentication flag
651 CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA
652 13, VISA14)
654 AIP (Application Interchange Profile), 2 bytes
656 TVR Terminal Verification Result, 5 bytes
658 CVR The card verification result
660 AmountOther
662 TransactionDate
664 TerminalCountryCode
666 TransactionCurrencyCode
668 AmountAuthorised
670 IIPB
672 These values are not contained within attributes in the container but
673 are shared between the manufacturing and the validation service
674 through this unique AppProfileId.
676 5.1.11. Logo (OPTIONAL)
678 Specifies the logo image information associated with a key. The logo
679 type is defined in a separate schema file with namespace
680 urn:ietf:params:xml:ns:keyprov:logo:1.0.
682 6. Key container XML schema definitions
684 The portable key container is defined by the following entities:
686 1. KeyContainer entity
688 2. Device entity
690 3. Key entity
692 4. User entity
694 A KeyContainer MAY contain one or more Device entities. A Device MAY
695 contain one or more Key entities and may be associated to one or more
696 User entities.
698 The figure below indicates a possible relationship diagram of a
699 container.
701 --------------------------------------------
702 | KeyContainer |
703 | |
704 | ------------------ ----------------- |
705 | | Device 1 | | Device n | |
706 | | | | | |
707 | | ------------ | | ------------ | |
708 | | | Key 1 | | | | Key n | | |
709 | | ------------ | | ------------ | |
710 | | | | | |
711 | | | | | |
712 | | ------------ | | ------------ | |
713 | | | Key m | | | | Key p | | |
714 | | ------------ | | ------------ | |
715 | ------------------ ----------------- |
716 | | | | |
717 | | | | |
718 | ---------- ---------- ---------- |
719 | | User 1 | | User 1 | | User n | |
720 | ---------- ---------- ---------- |
721 | |
722 --------------------------------------------
724 6.1. XML Schema Types
726 The following types are defined to represent the portable key
727 container entities and associated attributes.
729 6.1.1. KeyType
731 The KeyType represents the key entity in the KeyContainer. The
732 KeyType is defined as follows:
734
735
736
737
738
739
741
742
743
744
745
747
748
749
750
751
752
753
754
755
757
759 The components of the KeyType have the following meanings (see
760 Section 5 for further information):
762 o of type UsageType defines the usage of the Secret Key. The
763 Usage attribute is described in Section 5.1.3.
765 o identifies the issuer of the Secret Key. The Issuer
766 attribute is described in Section 5.1.5.
768 o is a user friendly name that is assigned to the
769 Secret Key for easy reference.
771 o conveys the data attributes (eg the Secret Key) in name
772 (string) value (base64 encoded) pairs. The value can be
773 encrypted, in this case a digest of the non-encrypted data is
774 present. The component is further described below.
776 o Defines the rules for accessing the credential on
777 the device e.g. a password must be provided by the user to view
778 credential info or use the credential to generate an OTP response
780 o KeyId is a global identifier of the Secret Key. See Section 5.1.4.
782 o KeyAlgorithm defines the algorithm used with the Secret Key. The
783 type values are defined in Section 6.2.
785 o Logo of type LogoType associates display logos with this Secret
786 Key
788 o Expiry defines the expiry date of the Secret Key in format DD/MM/
789 YYYY
791 The element is of type and is defined as follows:
793
794
795
796
797
798
799
801 The 'Name' attribute defines the name of the name-value pair, the
802 following list of attribute names have been reserved:
804 SECRET: the key key value in binary, base64 encoded
806 COUNTER: the event counter for event based OTP algorithms. 8 bytes
807 unsigned integer in big endian (i.e. network byte order) form
808 base64 encoded
810 TIME: the time for time based OTP algorithms. 8 bytes unsigned
811 integer in big endian (i.e. network byte order) form base64
812 encoded (Number of seconds since 1970)
814 TIME_INTERVAL: the time interval value for time based OTP
815 algorithms. 8 bytes unsigned integer in big endian (i.e. network
816 byte order) form base64 encoded.
818 The element in the DataType conveys the value of the name-
819 value pair in base 64 encoding. The value MAY be encrypted or in
820 clear text as per the EncryptionMethod data element in the
821 KeyContainer (see Section 6.1.6 for details about KeyContainerType).
822 When the value is encrypted, the digest value in 'ValueDigest' MUST
823 be provided. The digest MUST be calculated on the unencrypted value
824 and MUST use the Digest algorithms specified in DigestMethodType
825 element of the KeyContainer. The MAC key for the MAC calculation
826 should use the same key as the encryption key specified in the
827 EncryptionMethod unless a separate MAC key is specified. When PBE
828 method is used for encryption, a different password is recommended
829 for the MAC key derivation. When the key data is in clear text, the
830 KeyContainer payload signature MAY be used to check the integrity of
831 the key octets.
833 6.1.2. UsageType
835 The UsageType defines the usage attribute of the key entity. The
836 UsageType is defined as follows:
838
839
840
841
842
844
846
848
849
850
851
852
854
855
856
858
859
860
861
862
864
866
867
868
869
871 The UsageType components have the following meanings:
873 o holds the algorithm response attributes.
875 o hold the challenge attributes in CR based
876 algorithm computations.
878 o Is the unique shared identifier for out of band
879 shared common parameters.
881 6.1.3. DeviceType
883 The DeviceType type represents the Device entity in the Container. A
884 Device MAY be bound to a user and MAY contain more than one keys. It
885 is recommended that a key is bound to one and only one Device.
887 The DeviceType is defined as follows:
889
890
891
893
895
896
897
899 The components of the DeviceType have the following meanings:
901 o , a unique identifier for the device, defined by the
902 DeviceId type.
904 o , represents the key entity defined by the KeyType.
906 o , optionally identifies the owner or the user of the Device,
907 as defined by the UserType .
909 6.1.4. DeviceIdType
911 The DeviceId type represents the identifying criteria to uniquely
912 identify the device that contains the associated keys. Since devices
913 can come in different form factors such as hardware tokens,
914 smartcards, soft tokens in a mobile phone or PC etc this type allows
915 different criteria to be used. Combined though the criteria MUST
916 uniquely identify the device. For example for hardware tokens the
917 combination of SerialNo and Manufacturer will uniquely identify a
918 device but not SerialNo alone since two different token manufacturers
919 might issue devices with the same serial number (similar to the
920 IssuerDN and serial number of a certificate). For keys hold on
921 banking cards the identification of the device is often done via the
922 Primary Account Number (PAN, the big number printed on the front of
923 the card) and an expiry date of the card. DeviceId is an extensible
924 type that allows all these different ways to uniquely identify a
925 specific key containing device.
927 The DeviceIdType is defined as follows:
929
930
931
932
933
934
935
936
937
939 The components of the DeviceId type have the following meanings:
941 o , the manufacturer of the device.
943 o , the model of the device (e.g one-button-HOTP-token-V1)
945 o , the serial number of the device or the PAN (primary
946 account number) in case of EMV (Europay-MasterCard-Visa) smart
947 cards.
949 o , the issue number in case of smart cards with the same
950 PAN, equivalent to a PSN (PAN Sequence Number).
952 o , the expiry date of a device (such as the one on an EMV
953 card,used when issue numbers are not printed on cards). In format
954 DD/MM/YYYY
956 6.1.5. UserType Type
958 The UserType represents the identifying criteria to uniquely identify
959 the user who is bound to this device.
961 The UserType is defined as follows:
963
964
965
966
967
968
969
970
971
972
974 The components of the UserType type have the following meanings:
976 o , user first name.
978 o , user last name.
980 o , user id (UID) or user name.
982 o , user organization name.
984 6.1.6. KeyContainerType
986 The KeyContainerType represents the key container entity. A
987 Container MAY contain more than one Device entity; each Device entity
988 MAY contain more than one Key entity.
990 The KeyContainerType is defined as follows:
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1010
1012
1013
1014
1016 The components of the KeyContainer have the following meanings:
1018 o Version, the version number for the portable key container format
1019 (the XML schema defined in this document).
1021 o , the encryption method used to protect the Key
1022 data attributes
1024 o , the digest method used to sign the unencrypted the
1025 Secret Key data attributes
1027 o , the host Device for one or more Keys.
1029 o , contains the signature value of the Container. When
1030 the signature is applied to the entire container, it MUST use XML
1031 Signature methods as defined in [XMLSIG]. The signature is
1032 enveloped.
1034 6.1.7. EncryptionMethodType
1036 The EncryptionMethodType defines the algorithm and parameters used to
1037 encrypt the Secret Key data attributes in the Container. The
1038 encryption is applied on each individual Secret Key data in the
1039 Container. The encryption method MUST be the same for all Secret Key
1040 data in the container.
1042 The EncryptionMethodType is defined as follows:
1044
1045
1046
1047
1048
1049
1051
1053
1054
1055
1057
1058
1059
1060
1061
1062
1064
1066
1067
1068
1070
1072
1073
1074
1076 The components of the EncryptionMethodType have the following
1077 meanings:
1079 o : identifies a unique label for a pre-shared
1080 encryption key.
1082 o Algorithm: identifies the encryption algorithm used to protect the
1083 Secret Key data. If EncryptionMethod is absent in
1084 KeyContainerType, implementations MUST guarantee the privacy of
1085 the Secret Key Data through other mechanisms e.g. through
1086 transport level security.
1088 o : conveys the information of the key if an RSA algorithm
1089 has been used.
1091 o : conveys the OAEP parameters if an RSA algorithm has
1092 been used.
1094 o : conveys the PBE parameters if a password-
1095 based encryption (PBE) algorithm has been used.
1097 o
1099 * : conveys the Salt when [PKCS5] password-based
1100 encryption is applied.
1102 * : conveys the iteration count value in
1103 [PKCS5] password-based encryption if it is different from the
1104 default value.
1106 * : specifies the encryption algorithm after
1107 a PBE key is derived. For example, PBE-AES128-CBC should use
1108 URI http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc
1110 o : conveys the initialization vector for CBC based encryption
1111 algorithms. It is recommended for security reasons to transmit
1112 this value out of band and treat it the same manner as the key
1113 value.
1115 6.1.8. DigestMethodType
1117 The DigestMethodType defines the algorithm and parameters used to
1118 create the digest on the unencrypted Secret Key data in the
1119 Container. The digest is applied on each individual Secret Key data
1120 in the Container before encryption. The digest method MUST be the
1121 same for all Secret Key data in the container. Unless a different
1122 digest key is specified it is assumed that keyed digest algorithms
1123 will use the same key as for encryption
1125 The DigestMethodType is defined as follows:
1127
1128
1129
1130
1131
1133
1135 The components of the DigestMethodType have the following meanings:
1137 o Algorithm, identifies the digest algorithm used to protect the
1138 Secret Key data.
1140 o : identifies a unique label for a pre-shared
1141 digest key.
1143 6.2. KeyAlgorithmType
1145 The KeyAlgorithmType defines the algorithms in which the Secret Key
1146 data is used. It refers to anyURI.
1148 6.3. ValueFormat
1150 The ValueFormat defines allowed formats for challenges or responses
1151 in the OTP algorithms.
1153 The ValueFormat is defined as follows:
1155
1156
1157
1158
1159
1160
1161
1162
1163
1165 DECIMAL Only numerical digits
1167 HEXADECIMAL Hexadecimal response
1169 ALPHANUMERIC All letters and numbers (case sensitive)
1171 BASE64 Base 64 encoded
1173 BINARY Binary data, this is mainly used in case of connected
1174 devices
1176 6.4. Data elements
1178 6.4.1. KeyContainer
1180 The KeyContainer data element is defined as:
1182
1184 The KeyContainer data element is of type KeyContainerType defined in
1185 Section 6.1.6.
1187 The EncryptionMethod data element in the KeyContainer defines the
1188 encryption algorithm used to protect the Key data. In a multi-key
1189 KeyContainer, the same encryption method and the same encryption key
1190 MUST be used for all key data elements.
1192 The KeyContainer data element MAY contain multiple Device data
1193 elements, allowing for bulk provisioning of keys.
1195 The Signature data element is of type as defined in
1196 [XMLSIG] and MAY be omitted in the KeyContainer data element when
1197 application layer provisioning or transport layer provisioning
1198 protocols provide the integrity and authenticity of the payload
1199 between the sender and the recipient of the container. When
1200 required, this specification recommends using a symmetric key based
1201 signature with the same key used in the encryption of the secret key
1202 data. The signature is enveloped.
1204 7. Formal Syntax
1206 The following syntax specification uses the widely adopted XML schema
1207 format as defined by a W3C recommendation
1208 (http://www.w3.org/TR/xmlschema-0/). It is a complete syntax
1209 definition in the XML Schema Definition format (XSD)
1211 All implementations of this standard must comply with the schema
1212 below.
1214
1216
1224
1228
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1249
1252
1253
1255
1257
1258
1259
1260
1261
1263
1264
1265
1266
1267
1268
1270
1271
1272
1273
1274
1276
1277
1278
1279
1280
1281
1282
1283
1284
1286
1288
1289
1290
1291
1292
1293
1294
1295
1296
1298
1299
1300
1302
1304
1306
1307
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1320
1321
1322
1323
1324
1326
1328
1330
1331
1332
1333
1334
1336
1338
1340
1342
1343
1344
1345
1346
1349
1351
1353
1355
1357
1359
1360
1361
1362
1363
1364
1366
1368
1369
1370
1372
1373
1374
1375
1376
1377
1379
1381
1382
1383
1385
1387
1388
1389
1391
1392
1393
1394
1395
1398
1400
1401
1402
1404
1405
1406
1407
1408
1409
1410
1411
1412
1414
1417
1418
1419
1420
1422
1423
1425
1427
1429 LogoType is defined in the following schema.
1431
1433
1439
1440
1441
1442
1443 Type to include logo information.
1444
1446
1447
1448
1450
1452
1454
1455
1457
1458
1459
1460 Define logo information for a given logo. It can either embed
1461 full logo data information, or includes only a reference URI
1462 where the full log data information with type LogoDataType
1463 can be downloaded.
1464
1465
1466
1467
1468
1469
1470
1471
1472
1474
1475
1476
1477 Define logo data information for a given logo image.
1478
1479
1480
1481
1483
1485
1486
1488
1489
1490
1491 Define logo image data for a given logo image.
1492
1493
1494
1495
1496
1497
1498
1499
1500
1502
1504
1505
1506
1507 Define logo image parameters for a given logo image.
1508
1509
1510
1511
1512
1513
1514
1516
1517
1518
1519
1521
1522
1523
1524 Define logo image resolution parameters.
1525
1526
1527
1528
1529
1530
1531
1533
1534
1535
1536
1537 Can be one of the following supported image content types.
1538
1539
1540
1541
1542
1543
1544
1545
1547 8. Security Considerations
1549 The portable key container carries sensitive information (e.g.,
1550 cryptographic keys) and may be transported across the boundaries of
1551 one secure perimeter to another. For example, a container residing
1552 within the secure perimeter of a back-end provisioning server in a
1553 secure room may be transported across the internet to an end-user
1554 device attached to a personal computer. This means that special care
1555 must be taken to ensure the confidentiality, integrity, and
1556 authenticity of the information contained within.
1558 8.1. Payload confidentiality
1560 By design, the container allows two main approaches to guaranteeing
1561 the confidentiality of the information it contains while transported.
1563 First, the container key data payload may be encrypted.
1565 In this case no transport layer security is required. However,
1566 standard security best practices apply when selecting the strength of
1567 the cryptographic algorithm for payload encryption. Symmetric
1568 cryptographic cipher should be used - the longer the cryptographic
1569 key, the stronger the protection. At the time of this writing both
1570 3DES and AES are recommended algorithms but 3DES may be dropped in
1571 the relatively near future. Applications concerned with algorithm
1572 longevity are advised to use AES. In cases where the exchange of
1573 encryption keys between the sender and the receiver is not possible,
1574 asymmetric encryption of the secret key payload may be employed.
1575 Similarly to symmetric key cryptography, the stronger the asymmetric
1576 key, the more secure the protection is.
1578 If the payload is encrypted with a method that uses one of the
1579 password-based encryption methods provided above, the payload may be
1580 subjected to password dictionary attacks to break the encryption
1581 password and recover the information. Standard security best
1582 practices for selection of strong encryption passwords apply
1583 [Schneier].
1585 Practical implementations should use PBESalt and PBEIterationCount
1586 when PBE encryption is used. Different PBESalt value per credential
1587 record should be used for best protection.
1589 The second approach to protecting the confidentiality of the payload
1590 is based on using transport layer security. The secure channel
1591 established between the source secure perimeter (the provisioning
1592 server from the example above) and the target perimeter (the device
1593 attached to the end-user computer) utilizes encryption to transport
1594 the messages that travel across. No payload encryption is required
1595 in this mode. Secure channels that encrypt and digest each message
1596 provide an extra measure of security, especially when the signature
1597 of the payload does not encompass the entire payload.
1599 Because of the fact that the plain text payload is protected only by
1600 the transport layer security, practical implementation must ensure
1601 protection against man-in-the-middle attacks [Schneier]. Validating
1602 the secure channel end-points is critically important for eliminating
1603 intruders that may compromise the confidentiality of the payload.
1605 8.2. Payload integrity
1607 The portable symmetric key container provides a mean to guarantee the
1608 integrity of the information it contains through digital signatures.
1609 For best security practices, the digital signature of the container
1610 should encompass the entire payload. This provides assurances for
1611 the integrity of all attributes. It also allows verification of the
1612 integrity of a given payload even after the container is delivered
1613 through the communication channel to the target perimeter and channel
1614 message integrity check is no longer possible.
1616 8.3. Payload authenticity
1618 The digital signature of the payload is the primary way of showing
1619 its authenticity. The recipient of the container may use the public
1620 key associated with the signature to assert the authenticity of the
1621 sender by tracing it back to a preloaded public key or certificate.
1622 Note that the digital signature of the payload can be checked even
1623 after the container has been delivered through the secure channel of
1624 communication.
1626 A weaker payload authenticity guarantee may be provided by the
1627 transport layer if it is configured to digest each message it
1628 transports. However, no authenticity verification is possible once
1629 the container is delivered at the recipient end. This approach may
1630 be useful in cases where the digital signature of the container does
1631 not encompass the entire payload.
1633 9. Acknowledgements
1635 The authors of this draft would like to thank the following people
1636 for their contributions and support to make this a better
1637 specification: Apostol Vassilev, Jon Martinson, Siddhart Bajaj, Stu
1638 Veath, Kevin Lewis, Philip Hallam-Baker, Hannes Tschofenig, Andrea
1639 Doherty, Magnus Nystrom, Tim Moses, and Anders Rundgren.
1641 10. Appendix A - Example Symmetric Key Containers
1643 All examples are syntactically correct and compatible with the XML
1644 schema in section 7. However, , Key and Key
1645 data values are fictitious
1647 10.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret
1648 Key
1650
1651
1657
1658
1659 Token Manufacturer
1660 98765432188
1661 12/31/2012
1662
1663
1665 Credential Issuer
1666
1667
1668
1669 MyFirstToken
1670
1671
1672 zOkqJENSsh6b2hdXz1WBK/oprbY=
1673
1674
1675
1676 AAAAAAAAAAA=
1677
1678 10/30/2012
1679
1680
1681
1683 10.2. Symmetric Key Container with a single Password-based Encrypted
1684 HOTP Secret Key
1686
1687
1693
1695
1697 y6TzckeLRQw=
1698 1024
1699
1700 c2FtcGxlaXY=
1701
1702
1704
1705
1706 Token Manufacturer
1707 98765432187
1708 12/31/2012
1709
1710
1712 Credential Issuer
1713
1714
1715
1716 MyFirstToken
1717
1718
1719 JSPUyp3azOkqJENSsh6b2hdXz1WBYypzJxEr+ikQAa22M6V/BgZhRg==
1720
1721
1722 i8j+kpbfKQsSlwmJYS99lQ==
1723
1724
1725
1726 AAAAAAAAAAA=
1727
1728 10/30/2012
1729
1730
1731
1733 11. Normative References
1735 [CAP] MasterCard International, "Chip Authentication Program
1736 Functional Architecture", September 2004.
1738 [DSKPP] "Dynamic Symmetric Key Provisioning Protocol", Internet
1739 Draft Informational, URL: http://tools.ietf.org/wg/
1740 keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007.
1742 [HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password
1743 Algorithm", RFC 4226,
1744 URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
1745 December 2005.
1747 [OATH] "Initiative for Open AuTHentication",
1748 URL: http://www.openauthentication.org.
1750 [OATHRefArch]
1751 OATH, "Reference Architecture",
1752 URL: http://www.openauthentication.org, Version 1.0, 2005.
1754 [OCRA] MRaihi, D., "OCRA: OATH Challenge Response Algorithm",
1755 Internet Draft Informational, URL: http://www.ietf.org/
1756 internet-drafts/
1757 draft-mraihi-mutual-oath-hotp-variants-01.txt,
1758 December 2005.
1760 [PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
1761 Specifications Version 2.0.",
1762 URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,
1763 October 1998.
1765 [PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange
1766 Syntax Standard", Version 1.0,
1767 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/.
1769 [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
1770 Standard", Version 2.0,
1771 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/,
1772 March 1999.
1774 [RFC2119] "Key words for use in RFCs to Indicate Requirement
1775 Levels", BCP 14, RFC 2119, March 1997,
1776 .
1778 [Schneier]
1779 Schneier, B., "Secrets and Lies: Digitial Security in a
1780 Networked World", Wiley Computer Publishing, ISBN 0-8493-
1781 8253-7, 2000.
1783 [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
1784 URL: http://www.w3.org/TR/xmlenc-core/, December 2002.
1786 [XMLSIG] Eastlake, D., "XML-Signature Syntax and Processing",
1787 URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
1788 W3C Recommendation, February 2002.
1790 Authors' Addresses
1792 Philip Hoyer
1793 ActivIdenity, Inc.
1794 109 Borough High Street
1795 London, SE1 1NL
1796 UK
1798 Phone: +44 (0) 20 7744 6455
1799 Email: Philip.Hoyer@actividentity.com
1801 Mingliang Pei
1802 VeriSign, Inc.
1803 487 E. Middlefield Road
1804 Mountain View, CA 94043
1805 USA
1807 Phone: +1 650 426 5173
1808 Email: mpei@verisign.com
1810 Salah Machani
1811 Diversinet, Inc.
1812 2225 Sheppard Avenue East
1813 Suite 1801
1814 Toronto, Ontario M2J 5C2
1815 Canada
1817 Phone: +1 416 756 2324 Ext. 321
1818 Email: smachani@diversinet.com
1820 Shuh Chang
1821 Gemalto Inc.
1823 Email: shuh.chang@gemalto.com
1825 Full Copyright Statement
1827 Copyright (C) The IETF Trust (2007).
1829 This document is subject to the rights, licenses and restrictions
1830 contained in BCP 78, and except as set forth therein, the authors
1831 retain all their rights.
1833 This document and the information contained herein are provided on an
1834 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1835 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1836 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1837 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1838 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1839 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1841 Intellectual Property
1843 The IETF takes no position regarding the validity or scope of any
1844 Intellectual Property Rights or other rights that might be claimed to
1845 pertain to the implementation or use of the technology described in
1846 this document or the extent to which any license under such rights
1847 might or might not be available; nor does it represent that it has
1848 made any independent effort to identify any such rights. Information
1849 on the procedures with respect to rights in RFC documents can be
1850 found in BCP 78 and BCP 79.
1852 Copies of IPR disclosures made to the IETF Secretariat and any
1853 assurances of licenses to be made available, or the result of an
1854 attempt made to obtain a general license or permission for the use of
1855 such proprietary rights by implementers or users of this
1856 specification can be obtained from the IETF on-line IPR repository at
1857 http://www.ietf.org/ipr.
1859 The IETF invites any interested party to bring to its attention any
1860 copyrights, patents or patent applications, or other proprietary
1861 rights that may cover technology that may be required to implement
1862 this standard. Please address the information to the IETF at
1863 ietf-ipr@ietf.org.
1865 Acknowledgment
1867 Funding for the RFC Editor function is provided by the IETF
1868 Administrative Support Activity (IASA).