draft-ietf-keyprov-dskpp-11.txt   draft-ietf-keyprov-dskpp-12.txt 
KEYPROV Working Group A. Doherty KEYPROV Working Group A. Doherty
Internet-Draft RSA, The Security Division of EMC Internet-Draft RSA, The Security Division of EMC
Intended status: Standards Track M. Pei Intended status: Standards Track M. Pei
Expires: November 14, 2010 Verisign, Inc. Expires: March 2, 2011 VeriSign, Inc.
S. Machani S. Machani
Diversinet Corp. Diversinet Corp.
M. Nystrom M. Nystrom
Microsoft Corp. Microsoft Corp.
May 13, 2010 August 29, 2010
Dynamic Symmetric Key Provisioning Protocol (DSKPP) Dynamic Symmetric Key Provisioning Protocol (DSKPP)
draft-ietf-keyprov-dskpp-11.txt draft-ietf-keyprov-dskpp-12.txt
Abstract Abstract
DSKPP is a client-server protocol for initialization (and DSKPP is a client-server protocol for initialization (and
configuration) of symmetric keys to locally and remotely accessible configuration) of symmetric keys to locally and remotely accessible
cryptographic modules. The protocol can be run with or without cryptographic modules. The protocol can be run with or without
private-key capabilities in the cryptographic modules, and with or private-key capabilities in the cryptographic modules, and with or
without an established public-key infrastructure. without an established public-key infrastructure.
Two variations of the protocol support multiple usage scenarios. Two variations of the protocol support multiple usage scenarios.
With the four-pass variant, keys are mutually generated by the With the four-pass variant, keys are mutually generated by the
provisioning server and cryptographic module; provisioned keys are provisioning server and cryptographic module; provisioned keys are
not transferred over-the-wire or over-the-air. The two-pass variant not transferred over-the-wire or over-the-air. The two-pass variant
enables secure and efficient download and installation of pre- enables secure and efficient download and installation of pre-
generated symmetric keys to a cryptographic module. generated symmetric keys to a cryptographic module.
This document builds on information contained in [RFC4758], adding
specific enhancements in response to implementation experience and
liaison requests.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 14, 2010.
Copyright Notice This Internet-Draft will expire on March 2, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Version Support . . . . . . . . . . . . . . . . . . . . . 6
1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 7 1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 7
1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 7 1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 7
1.3.2. Identifiers Defined in Related Specifications . . . . 7 1.3.2. Identifiers Defined in Related Specifications . . . . 7
1.3.3. Referenced Identifiers . . . . . . . . . . . . . . . . 7 1.3.3. Referenced Identifiers . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 11
3. DSKPP Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 3. DSKPP Overview . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Protocol Entities . . . . . . . . . . . . . . . . . . . . 11 3.1. Protocol Entities . . . . . . . . . . . . . . . . . . . . 11
3.2. Basic DSKPP Exchange . . . . . . . . . . . . . . . . . . . 12 3.2. Basic DSKPP Exchange . . . . . . . . . . . . . . . . . . 12
3.2.1. User Authentication . . . . . . . . . . . . . . . . . 12 3.2.1. User Authentication . . . . . . . . . . . . . . . . . 12
3.2.2. Protocol Initiated by the DSKPP Client . . . . . . . . 12 3.2.2. Protocol Initiated by the DSKPP Client . . . . . . . 13
3.2.3. Protocol Triggered by the DSKPP Server . . . . . . . . 15 3.2.3. Protocol Triggered by the DSKPP Server . . . . . . . 15
3.2.4. Variants . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4. Variants . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 17 3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Basic Constructs . . . . . . . . . . . . . . . . . . . . . 18 3.4. Basic Constructs . . . . . . . . . . . . . . . . . . . . 18
3.4.1. User Authentication Data, AD . . . . . . . . . . . . . 19 3.4.1. User Authentication Data, AD . . . . . . . . . . . . 19
3.4.2. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF . . 21 3.4.2. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF . 23
3.4.3. The DSKPP Message Hash Algorithm . . . . . . . . . . . 22 3.4.3. The DSKPP Message Hash Algorithm . . . . . . . . . . 23
4. Four-Pass Protocol Usage . . . . . . . . . . . . . . . . . . . 22 4. Four-Pass Protocol Usage . . . . . . . . . . . . . . . . . . 24
4.1. The Key Agreement Mechanism . . . . . . . . . . . . . . . 22 4.1. The Key Agreement Mechanism . . . . . . . . . . . . . . . 24
4.1.1. Data Flow . . . . . . . . . . . . . . . . . . . . . . 22 4.1.1. Data Flow . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2. Computation . . . . . . . . . . . . . . . . . . . . . 24 4.1.2. Computation . . . . . . . . . . . . . . . . . . . . . 26
4.2. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 25 4.2. Message Flow . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1. KeyProvTrigger . . . . . . . . . . . . . . . . . . . . 25 4.2.1. KeyProvTrigger . . . . . . . . . . . . . . . . . . . 27
4.2.2. KeyProvClientHello . . . . . . . . . . . . . . . . . . 26 4.2.2. KeyProvClientHello . . . . . . . . . . . . . . . . . 28
4.2.3. KeyProvServerHello . . . . . . . . . . . . . . . . . . 27 4.2.3. KeyProvServerHello . . . . . . . . . . . . . . . . . 29
4.2.4. KeyProvClientNonce . . . . . . . . . . . . . . . . . . 29 4.2.4. KeyProvClientNonce . . . . . . . . . . . . . . . . . 31
4.2.5. KeyProvServerFinished . . . . . . . . . . . . . . . . 31 4.2.5. KeyProvServerFinished . . . . . . . . . . . . . . . . 33
5. Two-Pass Protocol Usage . . . . . . . . . . . . . . . . . . . 32 5. Two-Pass Protocol Usage . . . . . . . . . . . . . . . . . . . 34
5.1. Key Protection Methods . . . . . . . . . . . . . . . . . . 33 5.1. Key Protection Methods . . . . . . . . . . . . . . . . . 35
5.1.1. Key Transport . . . . . . . . . . . . . . . . . . . . 33 5.1.1. Key Transport . . . . . . . . . . . . . . . . . . . . 35
5.1.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 35
5.1.3. Passphrase-Based Key Wrap . . . . . . . . . . . . . . 34 5.1.3. Passphrase-Based Key Wrap . . . . . . . . . . . . . . 36
5.2. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 35 5.2. Message Flow . . . . . . . . . . . . . . . . . . . . . . 37
5.2.1. KeyProvTrigger . . . . . . . . . . . . . . . . . . . . 35 5.2.1. KeyProvTrigger . . . . . . . . . . . . . . . . . . . 37
5.2.2. KeyProvClientHello . . . . . . . . . . . . . . . . . . 35 5.2.2. KeyProvClientHello . . . . . . . . . . . . . . . . . 37
5.2.3. KeyProvServerFinished . . . . . . . . . . . . . . . . 40 5.2.3. KeyProvServerFinished . . . . . . . . . . . . . . . . 42
6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 41 6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 43
6.1. The ClientInfoType Extension . . . . . . . . . . . . . . . 41 6.1. The ClientInfoType Extension . . . . . . . . . . . . . . 44
6.2. The ServerInfoType Extension . . . . . . . . . . . . . . . 41 6.2. The ServerInfoType Extension . . . . . . . . . . . . . . 44
7. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 41 7. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 44
7.1. General Requirements . . . . . . . . . . . . . . . . . . . 41 7.1. General Requirements . . . . . . . . . . . . . . . . . . 44
7.2. HTTP/1.1 Binding for DSKPP . . . . . . . . . . . . . . . . 41 7.2. HTTP/1.1 Binding for DSKPP . . . . . . . . . . . . . . . 44
7.2.1. Identification of DSKPP Messages . . . . . . . . . . . 42 7.2.1. Identification of DSKPP Messages . . . . . . . . . . 45
7.2.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . 42 7.2.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . 45
7.2.3. HTTP Operations . . . . . . . . . . . . . . . . . . . 42 7.2.3. HTTP Operations . . . . . . . . . . . . . . . . . . . 45
7.2.4. HTTP Status Codes . . . . . . . . . . . . . . . . . . 43 7.2.4. HTTP Status Codes . . . . . . . . . . . . . . . . . . 46
7.2.5. HTTP Authentication . . . . . . . . . . . . . . . . . 43 7.2.5. HTTP Authentication . . . . . . . . . . . . . . . . . 46
7.2.6. Initialization of DSKPP . . . . . . . . . . . . . . . 43 7.2.6. Initialization of DSKPP . . . . . . . . . . . . . . . 46
7.2.7. Example Messages . . . . . . . . . . . . . . . . . . . 44 7.2.7. Example Messages . . . . . . . . . . . . . . . . . . 47
8. DSKPP XML Schema . . . . . . . . . . . . . . . . . . . . . . . 44 8. DSKPP XML Schema . . . . . . . . . . . . . . . . . . . . . . 47
8.1. General Processing Requirements . . . . . . . . . . . . . 44 8.1. General Processing Requirements . . . . . . . . . . . . . 47
8.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Conformance Requirements . . . . . . . . . . . . . . . . . . . 53 9. Conformance Requirements . . . . . . . . . . . . . . . . . . 56
10. Security Considerations . . . . . . . . . . . . . . . . . . . 54 10. Security Considerations . . . . . . . . . . . . . . . . . . . 58
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 54 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . . 55 10.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 58
10.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 55 10.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 58
10.2.2. Message Modifications . . . . . . . . . . . . . . . . 55 10.2.2. Message Modifications . . . . . . . . . . . . . . . . 58
10.2.3. Message Deletion . . . . . . . . . . . . . . . . . . . 56 10.2.3. Message Deletion . . . . . . . . . . . . . . . . . . 60
10.2.4. Message Insertion . . . . . . . . . . . . . . . . . . 57 10.2.4. Message Insertion . . . . . . . . . . . . . . . . . . 60
10.2.5. Message Replay . . . . . . . . . . . . . . . . . . . . 57 10.2.5. Message Replay . . . . . . . . . . . . . . . . . . . 60
10.2.6. Message Reordering . . . . . . . . . . . . . . . . . . 57 10.2.6. Message Reordering . . . . . . . . . . . . . . . . . 61
10.2.7. Man-in-the-Middle . . . . . . . . . . . . . . . . . . 57 10.2.7. Man-in-the-Middle . . . . . . . . . . . . . . . . . . 61
10.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 58 10.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 61
10.4. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 58 10.4. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 61
10.5. Attacks on the Interaction between DSKPP and User 10.5. Attacks on the Interaction between DSKPP and User
Authentication . . . . . . . . . . . . . . . . . . . . . . 58 Authentication . . . . . . . . . . . . . . . . . . . . . 62
10.6. Miscellaneous Considerations . . . . . . . . . . . . . . . 59 10.6. Miscellaneous Considerations . . . . . . . . . . . . . . 62
10.6.1. Client Contributions to K_TOKEN Entropy . . . . . . . 59 10.6.1. Client Contributions to K_TOKEN Entropy . . . . . . . 63
10.6.2. Key Confirmation . . . . . . . . . . . . . . . . . . . 59 10.6.2. Key Confirmation . . . . . . . . . . . . . . . . . . 63
10.6.3. Server Authentication . . . . . . . . . . . . . . . . 60 10.6.3. Server Authentication . . . . . . . . . . . . . . . . 63
10.6.4. User Authentication . . . . . . . . . . . . . . . . . 60 10.6.4. User Authentication . . . . . . . . . . . . . . . . . 63
10.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . . 60 10.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . 64
10.6.6. Algorithm Agility . . . . . . . . . . . . . . . . . . 61 10.6.6. Algorithm Agility . . . . . . . . . . . . . . . . . . 65
11. Internationalization Considerations . . . . . . . . . . . . . 62 11. Internationalization Considerations . . . . . . . . . . . . . 65
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 62 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 66
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 63 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 66
12.3. MIME Media Type Registration . . . . . . . . . . . . . . . 63 12.3. MIME Media Type Registration . . . . . . . . . . . . . . 66
12.4. Status Code Registry . . . . . . . . . . . . . . . . . . . 64 12.4. Status Code Registration . . . . . . . . . . . . . . . . 67
13. Intellectual Property Considerations . . . . . . . . . . . . . 64 12.5. DSKPP Version Registration . . . . . . . . . . . . . . . 68
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 64 12.6. PRF Algorithm ID Sub-Registry . . . . . . . . . . . . . . 68
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 12.6.1. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . 68
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 12.6.2. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . 69
16.1. Normative references . . . . . . . . . . . . . . . . . . . 66 12.7. Key Container Registration . . . . . . . . . . . . . . . 69
16.2. Informative references . . . . . . . . . . . . . . . . . . 67 13. Intellectual Property Considerations . . . . . . . . . . . . 70
Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . . 69 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 70
A.1. Single Key Request . . . . . . . . . . . . . . . . . . . . 69 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71
A.2. Multiple Key Requests . . . . . . . . . . . . . . . . . . 69 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.3. User Authentication . . . . . . . . . . . . . . . . . . . 69 16.1. Normative references . . . . . . . . . . . . . . . . . . 71
A.4. Provisioning Time-Out Policy . . . . . . . . . . . . . . . 70 16.2. Informative references . . . . . . . . . . . . . . . . . 73
A.5. Key Renewal . . . . . . . . . . . . . . . . . . . . . . . 70 Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . 75
A.6. Pre-Loaded Key Replacement . . . . . . . . . . . . . . . . 70 A.1. Single Key Request . . . . . . . . . . . . . . . . . . . 75
A.7. Pre-Shared Manufacturing Key . . . . . . . . . . . . . . . 70 A.2. Multiple Key Requests . . . . . . . . . . . . . . . . . . 75
A.8. End-to-End Protection of Key Material . . . . . . . . . . 71 A.3. User Authentication . . . . . . . . . . . . . . . . . . . 75
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 71 A.4. Provisioning Time-Out Policy . . . . . . . . . . . . . . 76
B.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 72 A.5. Key Renewal . . . . . . . . . . . . . . . . . . . . . . . 76
B.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . . 72 A.6. Pre-Loaded Key Replacement . . . . . . . . . . . . . . . 76
B.2.1. <KeyProvClientHello> Without a Preceding Trigger . . . 72 A.7. Pre-Shared Manufacturing Key . . . . . . . . . . . . . . 76
B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 73 A.8. End-to-End Protection of Key Material . . . . . . . . . . 77
B.2.3. <KeyProvServerHello> Without a Preceding Trigger . . . 75 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 77
B.2.4. <KeyProvServerHello> Assuming Key Renewal . . . . . . 76 B.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 78
B.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 76 B.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . 78
B.2.6. <KeyProvServerFinished> Using Default Encryption . . . 77 B.2.1. <KeyProvClientHello> Without a Preceding Trigger . . 78
B.3. Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . 79 B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 79
B.3.1. Example Using the Key Transport Method . . . . . . . . 79 B.2.3. <KeyProvServerHello> Without a Preceding Trigger . . 81
B.3.2. Example Using the Key Wrap Method . . . . . . . . . . 82 B.2.4. <KeyProvServerHello> Assuming Key Renewal . . . . . . 82
B.3.3. Example Using the Passphrase-Based Key Wrap Method . . 85 B.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 82
Appendix C. Integration with PKCS #11 . . . . . . . . . . . . . . 89 B.2.6. <KeyProvServerFinished> Using Default Encryption . . 83
C.1. The 4-pass Variant . . . . . . . . . . . . . . . . . . . . 89 B.3. Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . 84
C.2. The 2-pass Variant . . . . . . . . . . . . . . . . . . . . 89 B.3.1. Example Using the Key Transport Method . . . . . . . 84
Appendix D. Example of DSKPP-PRF Realizations . . . . . . . . . . 92 B.3.2. Example Using the Key Wrap Method . . . . . . . . . . 88
D.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 92 B.3.3. Example Using the Passphrase-Based Key Wrap Method . 91
D.2. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 92 Appendix C. Integration with PKCS #11 . . . . . . . . . . . . . 95
D.2.1. Identification . . . . . . . . . . . . . . . . . . . . 92 C.1. The 4-pass Variant . . . . . . . . . . . . . . . . . . . 96
D.2.2. Definition . . . . . . . . . . . . . . . . . . . . . . 92 C.2. The 2-pass Variant . . . . . . . . . . . . . . . . . . . 96
D.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 94 Appendix D. Example of DSKPP-PRF Realizations . . . . . . . . . 98
D.3. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . . 94 D.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 98
D.3.1. Identification . . . . . . . . . . . . . . . . . . . . 94 D.2. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 98
D.3.2. Definition . . . . . . . . . . . . . . . . . . . . . . 94 D.2.1. Identification . . . . . . . . . . . . . . . . . . . 98
D.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 95 D.2.2. Definition . . . . . . . . . . . . . . . . . . . . . 99
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96 D.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 100
D.3. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . 100
D.3.1. Identification . . . . . . . . . . . . . . . . . . . 100
D.3.2. Definition . . . . . . . . . . . . . . . . . . . . . 100
D.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 101
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102
1. Introduction 1. Introduction
Symmetric key based cryptographic systems (e.g., those providing Symmetric key based cryptographic systems (e.g., those providing
authentication mechanisms such as one-time passwords and challenge- authentication mechanisms such as one-time passwords and challenge-
response) offer performance and operational advantages over public response) offer performance and operational advantages over public
key schemes. Such use requires a mechanism for provisioning of key schemes. Such use requires a mechanism for provisioning of
symmetric keys providing equivalent functionality to mechanisms such symmetric keys providing equivalent functionality to mechanisms such
as CMP [RFC4210] and CMC [RFC5272] in a Public Key Infrastructure. as CMP [RFC4210] and CMC [RFC5272] in a Public Key Infrastructure.
skipping to change at page 6, line 45 skipping to change at page 6, line 45
randomness contributed by both the client and the server. The two- randomness contributed by both the client and the server. The two-
pass protocol requires only one round trip instead of two and permits pass protocol requires only one round trip instead of two and permits
a server specified key to be established. a server specified key to be established.
1.1. Key Words 1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Versions 1.2. Version Support
There is a provision made in the syntax for an explicit version There is a provision made in the syntax for an explicit version
number. Only version "1.0" is currently specified. number. Only version "1.0" is currently specified.
The purpose for versioning the protocol is to provide a mechanism by The purpose for versioning the protocol is to provide a mechanism by
which changes to required cryptographic algorithms (e.g., SHA-256) which changes to required cryptographic algorithms (e.g., SHA-256)
and attributes (e.g., key size) can be deployed without disrupting and attributes (e.g., key size) can be deployed without disrupting
existing implementations; likewise, out-dated implementations can be existing implementations; likewise, out-dated implementations can be
de-commissioned without disrupting operations involving newer de-commissioned without disrupting operations involving newer
protocol versions. protocol versions.
The numbering scheme for DSKPP versions is "<major>.<minor>". The
major and minor numbers MUST be treated as separate integers and each
number MAY be incremented higher than a single digit. Thus, "DSKPP
2.4" would be a lower version than "DSKPP 2.13", which in turn would
be lower than "DSKPP 12.3". Leading zeros (e.g., "DSKPP 6.01") MUST
be ignored by recipients and MUST NOT be sent.
The major version number should be incremented only if the data
formats or security algorithms have changed so dramatically that an
older version implementation would not be able to interoperate with a
newer version (e.g., removing support for a previously mandatory-to-
implement algorithm now found to be insecure). The minor version
number indicates new capabilities (e.g., introducing a new algorithm
option) and MUST be ignored by an entity with a smaller minor version
number, but used for informational purposes by the entity with the
larger minor version number.
1.3. Namespace Identifiers 1.3. Namespace Identifiers
This document uses Uniform Resource Identifiers [RFC2396] to identify This document uses Uniform Resource Identifiers [RFC3986] to identify
resources, algorithms, and semantics. resources, algorithms, and semantics.
1.3.1. Defined Identifiers 1.3.1. Defined Identifiers
The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is: The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" "urn:ietf:params:xml:ns:keyprov:dskpp"
References to qualified elements in the DSKPP schema defined herein References to qualified elements in the DSKPP schema defined herein
use the prefix "dskpp". use the prefix "dskpp", but any prefix is allowed.
1.3.2. Identifiers Defined in Related Specifications 1.3.2. Identifiers Defined in Related Specifications
This document relies on qualified elements already defined in the This document relies on qualified elements already defined in the
Portable Symmetric Key Container [PSKC] namespace, which is Portable Symmetric Key Container [PSKC] namespace, which is
represented by the prefix "pskc" and declared as: represented by the prefix "pskc" and declared as:
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
1.3.3. Referenced Identifiers 1.3.3. Referenced Identifiers
skipping to change at page 8, line 6 skipping to change at page 8, line 18
are represented by the prefix "ds". are represented by the prefix "ds".
2. Terminology 2. Terminology
2.1. Definitions 2.1. Definitions
The definitions provided below are defined as used in this document. The definitions provided below are defined as used in this document.
The same terms may be defined differently in other documents. The same terms may be defined differently in other documents.
Authentication Code (AC): User Authentication Code comprised of a Authentication Code (AC): User Authentication Code comprised of a
string of numeric characters known to the device and the server string of hexadecimal characters known to the device and the
and containing a client identifier and a password. This server and containing at a minimum a client identifier and a
ClientID/password combination is used only once, and then password. This ClientID/password combination is used only once
discarded. and may have a time limit, and then discarded.
Authentication Data (AD): User Authentication Data that is derived Authentication Data (AD): User Authentication Data that is derived
from the Authentication Code (AC) from the Authentication Code (AC)
Client ID: An identifier that the DSKPP Server uses to locate the Client ID: An identifier that the DSKPP Server uses to locate the
real user name or account identifier on the server. It can be a real user name or account identifier on the server. It can be a
short random identifier that is unrelated to any real usernames. short random identifier that is unrelated to any real usernames.
Cryptographic Module: A component of an application, which enables Cryptographic Module: A component of an application, which enables
symmetric key cryptographic functionality symmetric key cryptographic functionality
skipping to change at page 11, line 36 skipping to change at page 12, line 8
Server: The DSKPP provisioning server. Server: The DSKPP provisioning server.
Cryptographic Module: The cryptographic module to which the Cryptographic Module: The cryptographic module to which the
symmetric keys are to be provisioned, e.g., an authentication symmetric keys are to be provisioned, e.g., an authentication
token. token.
Client: The DSKPP client which manages communication between the Client: The DSKPP client which manages communication between the
cryptographic module and the key provisioning server. cryptographic module and the key provisioning server.
The principal syntax is XML and it is layered on a transport The principal syntax is XML [XML] and it is layered on a transport
mechanism such as HTTP. While it is highly desirable for the entire mechanism such as HTTP [RFC2616] and HTTP Over TLS [RFC2818]. While
communication between the DSKPP client and server to be protected by it is highly desirable for the entire communication between the DSKPP
means of a transport providing confidentiality and integrity client and server to be protected by means of a transport providing
protection such as HTTP over Transport Layer Security (TLS), such confidentiality and integrity protection such as HTTP over Transport
protection is not sufficient to protect the exchange of the symmetric Layer Security (TLS), such protection is not sufficient to protect
key data between the server and the cryptographic module and the the exchange of the symmetric key data between the server and the
DSKPP protocol is designed to permit implementations that satisfy cryptographic module and the DSKPP protocol is designed to permit
this requirement. implementations that satisfy this requirement.
The server only communicates to the client. As far as the server is The server only communicates to the client. As far as the server is
concerned, the client and cryptographic module may be considered to concerned, the client and cryptographic module may be considered to
be a single entity. be a single entity.
From a client-side security perspective, however, the client and the From a client-side security perspective, however, the client and the
cryptographic module are separate logical entities and may in some cryptographic module are separate logical entities and may in some
implementations be separate physical entities as well. implementations be separate physical entities as well.
It is assumed that a device will host an application layered above It is assumed that a device will host an application layered above
skipping to change at page 13, line 44 skipping to change at page 14, line 4
| | | | | | | |
|<-- Key | | Key -->| |<-- Key | | Key -->|
| Package | | Package | | Package | | Package |
Figure 1: Basic DSKPP Exchange Figure 1: Basic DSKPP Exchange
Before DSKPP begins: Before DSKPP begins:
o The Authentication Code is generated by the DSKPP Server, and o The Authentication Code is generated by the DSKPP Server, and
delivered to the user via an out-of-band trustworthy channel delivered to the user via an out-of-band trustworthy channel
(e.g., a paper slip delivered by IT department staff). (e.g., a paper slip delivered by IT department staff).
o The user typically enters the Client ID and Authentication Code o The user typically enters the Client ID and Authentication Code
manually, possibly on a device with only numeric keypad. Thus, manually, possibly on a device with only numeric keypad. Thus,
they are often short numeric values (for example, 8 decimal they are often short numeric values (for example, 8 decimal
digits). However, the DSKPP Server is free to generate them in digits). However, the DSKPP Server is free to generate them in
any way it wishes. any way it wishes.
o The DSKPP client needs the URL of the DSKPP server (which is not o The DSKPP client needs the URL [RFC3986] of the DSKPP server
user-specific or secret, and may be pre-configured somehow), and a (which is not user-specific or secret, and may be pre-configured
set of trust anchors for verifying the server certificate. somehow), and a set of trust anchors for verifying the server
certificate.
o There must be an account for the user that has an identifier and o There must be an account for the user that has an identifier and
long-term user name (or other account identifier) to which the long-term user name (or other account identifier) to which the
token will be associated. The DSKPP server will use the Client ID token will be associated. The DSKPP server will use the Client ID
to find the corresponding Authentication Code for user to find the corresponding Authentication Code for user
authentication. authentication.
In Step 1, the client establishes a TLS connection, and authenticates In Step 1, the client establishes a TLS connection, and authenticates
the server (that is, validates the certificate, and compares the host the server (that is, validates the certificate, and compares the host
name in the URL with the certificate). name in the URL with the certificate) as described in Section 3.1 of
[RFC2818].
Next, the DSKPP Client and DSKPP Server exchange DSKPP messages Next, the DSKPP Client and DSKPP Server exchange DSKPP messages
(which are sent over HTTPS). In these messages: (which are sent over HTTPS). In these messages:
o The client and server negotiate which cryptographic algorithms o The client and server negotiate which cryptographic algorithms
they want to use; which algorithms are supported for protecting they want to use; which algorithms are supported for protecting
DSKPP messages, and other DSKPP protocol details. DSKPP messages, and other DSKPP protocol details.
o The client sends the Client ID to the server, and proves that it o The client sends the Client ID to the server, and proves that it
knows the corresponding Authentication Code. knows the corresponding Authentication Code.
o The client and server agree on a secret key (token key or o The client and server agree on a secret key (token key or
K_TOKEN); depending on the negotiated protocol variant, this is K_TOKEN); depending on the negotiated protocol variant, this is
skipping to change at page 15, line 43 skipping to change at page 15, line 50
using an ordinary web browser and some existing credentials. using an ordinary web browser and some existing credentials.
The user then requests (by clicking a link or submitting a form) The user then requests (by clicking a link or submitting a form)
provisioning of a new key to the cryptographic module. The web provisioning of a new key to the cryptographic module. The web
server will reply with a <KeyProvTrigger> message that contains the server will reply with a <KeyProvTrigger> message that contains the
Client ID, Authentication Code, and URL of the DSKPP server. This Client ID, Authentication Code, and URL of the DSKPP server. This
information is also needed by the DSKPP server; how the web server information is also needed by the DSKPP server; how the web server
and DSKPP server interact is beyond the scope of this document. and DSKPP server interact is beyond the scope of this document.
The <KeyProvTrigger> message is sent in a HTTP response, and it is The <KeyProvTrigger> message is sent in a HTTP response, and it is
marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml". It marked with MIME type "application/dskpp+xml". It is assumed the web
is assumed the web browser has been configured to recognize this MIME browser has been configured to recognize this MIME type; the browser
type; the browser will start the DSKPP client, and provides it with will start the DSKPP client, and provides it with the
the <KeyProvTrigger> message. <KeyProvTrigger> message.
The DSKPP client then contacts the DSKPP server, and uses the Client The DSKPP client then contacts the DSKPP server, and uses the Client
ID and Authentication Code (from the <KeyProvTrigger> message) the ID and Authentication Code (from the <KeyProvTrigger> message) the
same way as in the first message flow. same way as in the first message flow.
3.2.4. Variants 3.2.4. Variants
As noted in the previous section, once the protocol has started, the As noted in the previous section, once the protocol has started, the
client and server MAY engage in either a two-pass or four-pass client and server MAY engage in either a two-pass or four-pass
message exchange. The four-pass and two-pass protocols are message exchange. The four-pass and two-pass protocols are
skipping to change at page 17, line 42 skipping to change at page 17, line 46
AccessDenied: The DSKPP client is not authorized to contact this AccessDenied: The DSKPP client is not authorized to contact this
DSKPP server DSKPP server
MalformedRequest: The DSKPP server failed to parse the DSKPP MalformedRequest: The DSKPP server failed to parse the DSKPP
client's request client's request
UnknownRequest: The DSKPP client made a request that is unknown to UnknownRequest: The DSKPP client made a request that is unknown to
the DSKPP server the DSKPP server
UnknownCriticalExtension: A critical DSKPP extension (see below) UnknownCriticalExtension: A DSKPP extension marked as "Critical"
used by the DSKPP client was not supported or recognized by the could not be interpreted by the receiving party.
DSKPP server
UnsupportedVersion: The DSKPP client used a DSKPP protocol version UnsupportedVersion: The DSKPP client used a DSKPP protocol version
not supported by the DSKPP server. This error is only valid in not supported by the DSKPP server. This error is only valid in
the DSKPP server's first response message the DSKPP server's first response message
NoSupportedKeyTypes: "NoSupportedKeyTypes" indicates that the DSKPP NoSupportedKeyTypes: "NoSupportedKeyTypes" indicates that the DSKPP
client only suggested key types that are not supported by the client only suggested key types that are not supported by the
DSKPP server. This error is only valid in the DSKPP server's DSKPP server. This error is only valid in the DSKPP server's
first response message first response message
NoSupportedEncryptionAlgorithms: The DSKPP client only suggested NoSupportedEncryptionAlgorithms: The DSKPP client only suggested
encryption algorithms that are not supported by the DSKPP server. encryption algorithms that are not supported by the DSKPP server.
This error is only valid in the DSKPP server's first response This error is only valid in the DSKPP server's first response
message message
NoSupportedMacAlgorithms: The DSKPP client only suggested MAC NoSupportedMacAlgorithms: The DSKPP client only suggested MAC
algorithms that are not supported by the DSKPP server. This algorithms that are not supported by the DSKPP server. This
error is only valid in the DSKPP server's first response message error is only valid in the DSKPP server's first response message
NoProtocolVariants: The DSKPP client only suggested a protocol NoProtocolVariants: The DSKPP client did not suggest a required
variant (either 2-pass or 4-pass) that is not supported by the protocol variant (either 2-pass or 4-pass). This error is only
DSKPP server. This error is only valid in the DSKPP server's valid in the DSKPP server's first response message.
first response message
NoSupportedKeyPackages: The DSKPP client only suggested key package NoSupportedKeyPackages: The DSKPP client only suggested key package
formats that are not supported by the DSKPP server. This error formats that are not supported by the DSKPP server. This error
is only valid in the DSKPP server's first response message is only valid in the DSKPP server's first response message
AuthenticationDataMissing: The DSKPP client didn't provide AuthenticationDataMissing: The DSKPP client didn't provide
authentication data that the DSKPP server required authentication data that the DSKPP server required
AuthenticationDataInvalid: The DSKPP client supplied user AuthenticationDataInvalid: The DSKPP client supplied user
authentication data that the DSKPP server failed to validate authentication data that the DSKPP server failed to validate
skipping to change at page 19, line 25 skipping to change at page 19, line 25
wishes. wishes.
3.4.1.1. Authentication Code Format 3.4.1.1. Authentication Code Format
AC is encoded in Type-Length-Value (TLV) format. The format consists AC is encoded in Type-Length-Value (TLV) format. The format consists
of a minimum of two TLVs and a variable number of additional TLVs, of a minimum of two TLVs and a variable number of additional TLVs,
depending on implementation. depending on implementation.
The TLV fields are defined as follows: The TLV fields are defined as follows:
Type (1 byte) The integer value identifying the type of Type (1 character) A hexadecimal character identifying the
information contained in the value field. type of information contained in the Value
field.
Length (1 byte) The length, in hexadecimal, of the value Length (2 characters) Two hexadecimal characters indicating the
field to follow. length of the Value field to follow. The
field value MAY be up to 255 characters.
The Length value 00 MAY be used to specify
custom tags without any field values.
Value (variable length) A variable-length hexadecimal value Value (variable length) A variable-length string of hexadecimal
containing the instance-specific characters containing the instance-specific
information for this TLV. information for this TLV.
A 1 byte type field identifies the specific TLV, and a 1 byte length,
in hexadecimal, indicates the length of the value field contained in
the TLV. A TLV MUST start on a 4 byte boundary. Pad bytes MUST be
placed at the end of the previous TLV in order to align the next TLV.
These pad bytes are not counted in the length field of the TLV.
The following table summarizes the TLVs defined in this document. The following table summarizes the TLVs defined in this document.
Optional TLVs are allowed for vendor-specific extensions with the Optional TLVs are allowed for vendor-specific extensions with the
constraint that the high bit MUST be set to indicate a vendor- constraint that the high bit MUST be set to indicate a vendor-
specific type. Other TLVs are left for later revisions of this specific type. Other TLVs are left for later revisions of this
protocol. protocol.
+------+------------+-------------------------------------------+ +------+------------+-------------------------------------------+
| Type | TLV Name | Conformance | Example Usage | | Type | TLV Name | Conformance | Example Usage |
+------+------------+-------------------------------------------+ +------+------------+-------------------------------------------+
| 1 | Client ID | Mandatory | { "AC00000A" } | | 1 | Client ID | Mandatory | { "AC00000A" } |
+------+------------+-------------+-----------------------------+ +------+------------+-------------+-----------------------------+
| 2 | Password | Mandatory | { "3582" } | | 2 | Password | Mandatory | { "3582AF0C3E" } |
+------+------------+-------------+-----------------------------+ +------+------------+-------------+-----------------------------+
| 3 | Checksum | Optional | { 0x5F8D } | | 3 | Checksum | Optional | { "4D5" } |
+------+------------+-------------+-----------------------------+ +------+------------+-------------+-----------------------------+
The Client ID is a mandatory TLV that represents the requester's The Client ID is a mandatory TLV that represents the requester's
identifier of maximum length 128. The value is represented as an identifier of maximum length 255. The value is represented as a
ASCII string that identifies the key request. The ClientID MUST be string of hexadecimal characters that identifies the key request.
HEX encoded. For example, suppose ClientID is set to "AC00000A", the For example, suppose Client ID is set to "AC00000A", the Client ID
hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of TLV in the AC will be represented as "108AC00000A".
{0x1, 0x8, 0x4143303030303041}.
The Password is a mandatory TLV the contains a one-time use shared The Password is a mandatory TLV the contains a one-time use shared
secret known by the user and the Provisioning Server. The password secret known by the user and the Provisioning Server. The password
value is unique and SHOULD be a random string to make AC more value is unique and SHOULD be a random string to make AC more
difficult to guess. The string MUST be UTF-8 encoded in accordance difficult to guess. The string MUST contain hexadecimal characters
with [RFC3629]. For example, suppose password is set to "3582", then only. For example, suppose password is set to "3582AF0C3E", then the
the TLV would be {0x2, 0x4, UTF-8("3582")}. Password TLV would be "20A3582AF0C3E".
The Checksum is an OPTIONAL TLV, which is generated by the issuing The Checksum is an OPTIONAL TLV, which is generated by the issuing
server and sent to the user as part of the AC. If the TLV is server and sent to the user as part of the AC. If the TLV is
provided, the checksum value MUST be computed using the CRC16 provided, the checksum value MUST be computed using the CRC16
algorithm [ISO3309]. When the user enters the AC, the typed password algorithm [ISO3309]. When the user enters the AC, the typed AC
is verified with the checksum to ensure it is correctly entered by string of characters is verified with the checksum to ensure it is
the user. For example, suppose the Password is set to "3582", then correctly entered by the user. For example, suppose the AC with
the CRC16 calculation would generate a checksum of 0x5F8D, resulting combined Client ID tag and Password tag is set to
in TLV {0x3, 0x2, 0x5F8D}. "108AC00000A20A3582AF0C3E", then the CRC16 calculation would generate
a checksum of 0x356, resulting in a Checksum TLV of "334D5". The
complete AC string in this example would be
"108AC00000A20A3582AF0C3E3034D5".
Although this specification recommends using hexadecimal characters
only for the AC at the application's user interface layer and making
the TLV triples non-transparent to the user as described in the
example above; implementations MAY choose to use other printable
Unicode characters at the application's user interface layer in order
to meet specific local, context or usability requirements. When non-
hexadecimal characters are desired at the user interface layer such
as when other printable US-ASCII characters or international
characters are used, UTF-8 [RFC3629] MUST be used to convert user
input to a string of hexadecimal characters and the general
guidelines for mapping characters in [IDNA2008] MUST be followed.
For example, if a given application allows use of any printable US-
ASCII characters and extended ASCII characters for Client ID and
password fields and the Client ID is set to "myclient!D" and
associated password is set to "mYpas&#rD", the user enters through
the keyboard or other means a Client ID of "myclient!D" and a
password of "mYpas&#rD" in separate form fields or as instructed by
the provider. The application's layer processing user input MUST
then convert the values entered by the user to the following string
for use in the protocol:
"1146D79636C69656E74214421A6DC2A570CEB17373C2A372CEB4" (note that in
this example the Checksum TLV is not added).
The example is explained further below in detail:
Assume that the raw Client ID value or the value entered by the use
is: myclient!ID
The Client ID value as characters names is:
U+006D LATIN SMALL LETTER M character
U+0079 LATIN SMALL LETTER Y character
U+0063 LATIN SMALL LETTER C character
U+006C LATIN SMALL LETTER L character
U+0069 LATIN SMALL LETTER I character
U+0065 LATIN SMALL LETTER E character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character
U+0021 EXCLAMATION MARK character (!)
U+0044 LATIN CAPITAL LETTER D character
The UTF-8 conversion of the Client ID value is: 6D 79 63 6C 69 65 6E
74 21 44
The length of the Client ID value in hexadecimal characters is: 14
The TLV presentation of the Client ID field is:
10146D79636C69656E742144
The raw password value or the value entered by the user is: mYpas&#rD
The password value as character names is:
U+006D LATIN SMALL LETTER M character
U+0059 LATIN LARGE LETTER Y character
U+0070 LATIN SMALL LETTER P character
U+0061 LATIN SMALL LETTER A character
U+0073 LATIN SMALL LETTER S character
U+0026 AMPERSAND character (&)
U+0023 POUND SIGN character (#)
U+0072 LATIN SMALL LETTER R character
U+0044 LATIN LARGE LETTER D character
The UTF-8 conversion of the password value is: 6D 59 70 61 73 26 23
72 44
The length of the password value in hexadecimal characters is: 12
The TLV presentation of the password field is: 2126D5970617326237244
The combined Client ID and password fields value or the AC value is:
1146D79636C69656E7421442126D5970617326237244
3.4.1.2. User Authentication Data Calculation 3.4.1.2. User Authentication Data Calculation
The Authentication Data consists of a Client ID (extracted from the The Authentication Data consists of a Client ID (extracted from the
AC) and a value, which is derived from AC as follows (refer to AC) and a value, which is derived from AC as follows (refer to
Section 3.4.2 for a description of DSKPP-PRF in general and Section 3.4.2 for a description of DSKPP-PRF in general and
Appendix D for a description of DSKPP-PRF-AES): Appendix D for a description of DSKPP-PRF-AES):
MAC = DSKPP-PRF(K_AC, AC->ClientID||URL_S||R_C||[R_S], 16) MAC = DSKPP-PRF(K_AC, AC->ClientID||URL_S||R_C||[R_S], 16)
skipping to change at page 24, line 21 skipping to change at page 26, line 21
persuade the legitimate server to derive the same value for K_TOKEN, persuade the legitimate server to derive the same value for K_TOKEN,
since K_TOKEN is a function of the public key involved, and the since K_TOKEN is a function of the public key involved, and the
attacker's public key must be different than the correct server's (or attacker's public key must be different than the correct server's (or
else the attacker would not be able to decrypt the information else the attacker would not be able to decrypt the information
received from the client). Therefore, once the attacker is no longer received from the client). Therefore, once the attacker is no longer
"in the middle," the client and server will detect that they are "out "in the middle," the client and server will detect that they are "out
of sync" when they try to use their keys. In the case of encrypting of sync" when they try to use their keys. In the case of encrypting
R_C with K_SERVER, it is therefore important to verify that K_SERVER R_C with K_SERVER, it is therefore important to verify that K_SERVER
really is the legitimate server's key. One way to do this is to really is the legitimate server's key. One way to do this is to
independently validate a newly generated K_TOKEN against some independently validate a newly generated K_TOKEN against some
validation service at the server (e.g. using a connection independent validation service at the server (e.g., using a connection
from the one used for the key generation). independent from the one used for the key generation).
4.1.2. Computation 4.1.2. Computation
In DSKPP, the client and server both generate K_TOKEN and K_MAC by In DSKPP, the client and server both generate K_TOKEN and K_MAC by
deriving them from a provisioning key (K_PROV) using the DSKPP-PRF deriving them from a provisioning key (K_PROV) using the DSKPP-PRF
function (refer to Section 3.4.2) as follows: function (refer to Section 3.4.2) as follows:
K_PROV = DSKPP-PRF(k,s,dsLen), where K_PROV = DSKPP-PRF(k,s,dsLen), where
k = R_C (i.e., the secret random value chosen by the DSKPP k = R_C (i.e., the secret random value chosen by the DSKPP
skipping to change at page 25, line 32 skipping to change at page 27, line 32
[<---] AD, [DeviceID], [<---] AD, [DeviceID],
[KeyID], [URL_S] [KeyID], [URL_S]
When this message is sent: When this message is sent:
The "trigger" message is optional. The DSKPP server sends this The "trigger" message is optional. The DSKPP server sends this
message after the following out-of-band steps are performed: message after the following out-of-band steps are performed:
1. A user directed their browser to a key provisioning web 1. A user directed their browser to a key provisioning web
application and signs in (i.e., authenticates) application and signs in (i.e., authenticates)
2. The user requests a key 2. The user requests a key
3. The web application processes the request and returns an 3. The web application processes the request and returns an
authentication code to the user, e.g., in the form of an email authentication code to the user, e.g., in response to an
message enrollment request via a secure web session
4. The web application retrieves the authentication code from the 4. The web application retrieves the authentication code from the
user (possibly by asking the user to enter it using a web user (possibly by asking the user to enter it using a web
form, or alternatively by the user selecting a URL in which form, or alternatively by the user selecting a URL in which
the authentication code is embedded) the authentication code is embedded)
5. The web application derives authentication data (AD) from the 5. The web application derives authentication data (AD) from the
authentication code as described in Section 3.4.1 authentication code as described in Section 3.4.1
6. The web application passes AD, and possibly a DeviceID 6. The web application passes AD, and possibly a DeviceID
(identifies a particular device to which the key MUST be (identifies a particular device to which the key is to be
provisioned) and/or KeyID (identifies a key that will be provisioned) and/or KeyID (identifies a key that will be
replaced) to the DSKPP server replaced) to the DSKPP server
Purpose of this message: Purpose of this message:
To start a DSKPP session: The DSKPP server uses this message to To start a DSKPP session: The DSKPP server uses this message to
trigger a client-side application to send the first DSKPP message. trigger a client-side application to send the first DSKPP message.
To provide a way for the key provisioning system to get the DSKPP To provide a way for the key provisioning system to get the DSKPP
server URL to the DSKPP client. server URL to the DSKPP client.
skipping to change at page 28, line 35 skipping to change at page 30, line 35
nonce included with <KeyProvClientNonce>. K represents the nonce included with <KeyProvClientNonce>. K represents the
server's public key (K_SERVER) or a pre-shared secret key server's public key (K_SERVER) or a pre-shared secret key
(K_SHARED). (K_SHARED).
A MAC MUST be present if a key is being renewed so that the DSKPP A MAC MUST be present if a key is being renewed so that the DSKPP
client can confirm that the replacement key came from a trusted client can confirm that the replacement key came from a trusted
server. This MAC MUST be computed using DSKPP-PRF (see server. This MAC MUST be computed using DSKPP-PRF (see
Section 3.4.2), where the input parameter k MUST be set to the Section 3.4.2), where the input parameter k MUST be set to the
existing MAC key K_MAC' (i.e., the value of the MAC key that existing MAC key K_MAC' (i.e., the value of the MAC key that
existed before this protocol run; the implementation MAY specify existed before this protocol run; the implementation MAY specify
K_MAC' to be the value of the K_TOKEN that is being replaced, or a K_MAC' to be the value of the K_TOKEN that is being replaced), and
version of K_MAC from the previous protocol run), and input input parameter dsLen MUST be set to the length of R_S.
parameter dsLen MUST be set to the length of R_S.
How the DSKPP client uses this message: How the DSKPP client uses this message:
When the Status attribute is not set to "Continue", this indicates When the Status attribute is not set to "Continue", this indicates
failure and the DSKPP client MUST abort the protocol. failure and the DSKPP client MUST abort the protocol.
If successful execution of the protocol will result in the If successful execution of the protocol will result in the
replacement of an existing key with a newly generated one, the replacement of an existing key with a newly generated one, the
DSKPP client MUST verify the MAC provided in <KeyProvServerHello>. DSKPP client MUST verify the MAC provided in <KeyProvServerHello>.
The DSKPP client MUST terminate the DSKPP session if the MAC does The DSKPP client MUST terminate the DSKPP session if the MAC does
not verify, and MUST delete any nonces, keys, and/or secrets not verify, and MUST delete any nonces, keys, and/or secrets
skipping to change at page 29, line 14 skipping to change at page 31, line 13
selected key type. selected key type.
Encrypt R_C using K and the encryption algorithm included in the Encrypt R_C using K and the encryption algorithm included in the
SAL. SAL.
The method the DSKPP client MUST use to encrypt R_C: The method the DSKPP client MUST use to encrypt R_C:
If K is equivalent to K_SERVER (i.e., the public key of the DSKPP If K is equivalent to K_SERVER (i.e., the public key of the DSKPP
server), then an RSA encryption scheme from PKCS #1 [PKCS-1] MAY server), then an RSA encryption scheme from PKCS #1 [PKCS-1] MAY
be used. If K is equivalent to K_SERVER, then the cryptographic be used. If K is equivalent to K_SERVER, then the cryptographic
module SHOULD verify the server's certificate before using it to module SHOULD verify the server's certificate before using it to
encrypt R_C in accordance with [RFC5280]. encrypt R_C as described in [RFC2818], Section 3.1, and [RFC5280].
If K is equivalent to K_SHARED, the DSKPP client MAY use the If K is equivalent to K_SHARED, the DSKPP client MAY use the
DSKPP-PRF function to avoid dependence on other algorithms. In DSKPP-PRF function to avoid dependence on other algorithms. In
this case, the client uses K_SHARED as input parameter k (K_SHARED this case, the client uses K_SHARED as input parameter k (K_SHARED
SHOULD be used solely for this purpose) as follows: SHOULD be used solely for this purpose) as follows:
dsLen = len(R_C), where "len" is the length of R_C dsLen = len(R_C), where "len" is the length of R_C
DS = DSKPP-PRF(K_SHARED, "Encryption" || R_S, dsLen) DS = DSKPP-PRF(K_SHARED, "Encryption" || R_S, dsLen)
This will produce a pseudorandom string DS of length equal to R_C. This will produce a pseudorandom string DS of length equal to R_C.
skipping to change at page 30, line 48 skipping to change at page 32, line 48
msg_hash = SHA-256(msg_1, ..., msg_n) msg_hash = SHA-256(msg_1, ..., msg_n)
dsLen = len(msg_hash) dsLen = len(msg_hash)
MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash, dsLen) MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash, dsLen)
where where
MAC The DSKPP Pseudo-Random Function defined in Section 3.4.2 is MAC The DSKPP Pseudo-Random Function defined in Section 3.4.2 is
used to compute the MAC. The particular realization of DSKPP- used to compute the MAC. The particular realization of DSKPP-
PRF (e.g., those defined in Appendix D depends on the MAC PRF (e.g., those defined in Appendix D) depends on the MAC
algorithm contained in the <KeyProvServerHello> message. The algorithm contained in the <KeyProvServerHello> message. The
MAC MUST be computed using the existing MAC key (K_MAC), and a MAC MUST be computed using the existing MAC key (K_MAC), and a
string that is formed by concatenating the (ASCII) string "MAC string that is formed by concatenating the (ASCII) string "MAC
1 computation" and a msg_hash 1 computation" and a msg_hash
K_MAC The key derived from K_PROV, as described in Section 4.1.2. K_MAC The key derived from K_PROV, as described in Section 4.1.2.
msg_hash The message hash (defined in Section 3.4.3) of messages msg_hash The message hash (defined in Section 3.4.3) of messages
msg_1, ..., msg_n. msg_1, ..., msg_n.
skipping to change at page 31, line 33 skipping to change at page 33, line 33
With this message the DSKPP server confirms generation of the key With this message the DSKPP server confirms generation of the key
(K_TOKEN), and transmits the associated identifier and (K_TOKEN), and transmits the associated identifier and
application-specific attributes, but not the key itself, in a key application-specific attributes, but not the key itself, in a key
package to the client for protocol completion. package to the client for protocol completion.
What is contained in this message: What is contained in this message:
A status attribute equivalent to the server's return code to A status attribute equivalent to the server's return code to
<KeyProvClientNonce>. If user authentication passed, and the <KeyProvClientNonce>. If user authentication passed, and the
server successfully computed K_TOKEN, generated a key package, and server successfully computed K_TOKEN, generated a key package, and
associated them with the user's account on the cryptographic associated them with the user's account on the cryptographic
server, then it sets Status to Continue. server, then it sets Status to Success.
If status is Continue, then this message acts as a "commit" If status is Success, then this message acts as a "commit"
message, instructing the cryptographic module to store the message, instructing the cryptographic module to store the
generated key (K_TOKEN) and associate the given key identifier generated key (K_TOKEN) and associate the given key identifier
with this key. As such, a key package (KP) MUST be included in with this key. As such, a key package (KP) MUST be included in
this message, which holds an identifier for the generated key (but this message, which holds an identifier for the generated key (but
not the key itself) and additional configuration, e.g., the not the key itself) and additional configuration, e.g., the
identity of the DSKPP server, key usage attributes, etc. The identity of the DSKPP server, key usage attributes, etc. The
default symmetric key package format MUST be based on the Portable default symmetric key package format MUST be based on the Portable
Symmetric Key Container (PSKC) defined in [PSKC]. Alternative Symmetric Key Container (PSKC) defined in [PSKC]. Alternative
formats MAY include [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 XML formats MAY include [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 XML
[PKCS-5-XML] format. [PKCS-5-XML] format.
With KP, the server includes a key confirmation MAC that the With KP, the server includes a key confirmation MAC that the
client uses to avoid a false "Commit". The MAC algorithm is the client uses to avoid a false "Commit". The MAC algorithm is the
same DSKPP-PRF that was sent in the <KeyProvServerHello> message. same DSKPP-PRF that was sent in the <KeyProvServerHello> message.
How the DSKPP client uses this message: How the DSKPP client uses this message:
When the Status attribute is not set to "Continue", this indicates When the Status attribute is not set to "Success", this indicates
failure and the DSKPP client MUST abort the protocol. failure and the DSKPP client MUST abort the protocol.
After receiving a <KeyProvServerFinished> message with Status = After receiving a <KeyProvServerFinished> message with Status =
"Success", the DSKPP client MUST verify the key confirmation MAC "Success", the DSKPP client MUST verify the key confirmation MAC
that was transmitted with this message. The DSKPP client MUST that was transmitted with this message. The DSKPP client MUST
terminate the DSKPP session if the MAC does not verify, and MUST, terminate the DSKPP session if the MAC does not verify, and MUST,
in this case, also delete any nonces, keys, and/or secrets in this case, also delete any nonces, keys, and/or secrets
associated with the failed run of the protocol. associated with the failed run of the protocol.
If <KeyProvServerFinished> has Status = "Success" and the MAC was If <KeyProvServerFinished> has Status = "Success" and the MAC was
skipping to change at page 33, line 5 skipping to change at page 35, line 5
attributes, such as expiry date and length. attributes, such as expiry date and length.
The DSKPP server encrypts K_PROV to ensure that it is not exposed to The DSKPP server encrypts K_PROV to ensure that it is not exposed to
any other entity than the DSKPP server and the cryptographic module any other entity than the DSKPP server and the cryptographic module
itself. The DSKPP server uses any of three key protection methods to itself. The DSKPP server uses any of three key protection methods to
encrypt K_PROV: Key Transport, Key Wrap, and Passphrase-Based Key encrypt K_PROV: Key Transport, Key Wrap, and Passphrase-Based Key
Wrap Key Protection Methods. Wrap Key Protection Methods.
While the DSKPP client and server may negotiate the key protection While the DSKPP client and server may negotiate the key protection
method to use, the actual key protection is carried out in the method to use, the actual key protection is carried out in the
KeyPackage. For example, the default KeyPackage format KeyPackage. The format of a KeyPackage specifies how a key should be
urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer from [PSKC] protected using the three key protection methods. The following
specifies how a key should be protected, including the three key KeyPackage formats are defined for DSKPP:
protection methods described here.
o PSKC Key Container [PSKC] at
urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
o SKPC Key Container [SKPC-ASN.1] at
urn:ietf:params:xml:ns:keyprov:dskpp:skpc-key-container
o PKCS12 Key Container [PKCS-12] at
urn:ietf:params:xml:ns:keyprov:dskpp:pkcs12-key-container
o PKCS5-XML Key Container [PKCS-5-XML] at
urn:ietf:params:xml:ns:keyprov:dskpp:pkcs5-xml-key-container
Each of the key protection methods is described below.
5.1. Key Protection Methods 5.1. Key Protection Methods
This section introduces three key protection methods for the two-pass This section introduces three key protection methods for the two-pass
variant. Additional methods MAY be defined by external entities or variant. Additional methods MAY be defined by external entities or
through the IETF process. through the IETF process.
5.1.1. Key Transport 5.1.1. Key Transport
Purpose of this method: Purpose of this method:
This method is intended for PKI-capable devices. The DSKPP server This method is intended for PKI-capable devices. The DSKPP server
encrypts keying material and transports it to the DSKPP client. encrypts keying material and transports it to the DSKPP client.
The server encrypts the keying material using the public key of The server encrypts the keying material using the public key of
the DSKPP client, whose private key part resides in the the DSKPP client, whose private key part resides in the
cryptographic module. The DSKPP client decrypts the keying cryptographic module. The DSKPP client decrypts the keying
material and uses it to derive the symmetric key, K_TOKEN. material and uses it to derive the symmetric key, K_TOKEN.
This method is identified with the following URN: This method is identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp#transport urn:ietf:params:xml:schema:keyprov:dskpp:transport
The DSKPP server and client MUST support the following mechanism: The DSKPP server and client MUST support the following mechanism:
http://www.w3.org/2001/04/xmlenc#rsa-1_5 encryption mechanism http://www.w3.org/2001/04/xmlenc#rsa-1_5 encryption mechanism
defined in [XMLENC]. defined in [XMLENC].
5.1.2. Key Wrap 5.1.2. Key Wrap
Purpose of this method: Purpose of this method:
This method is ideal for pre-keyed devices, e.g., SIM cards. The This method is ideal for pre-keyed devices, e.g., SIM cards. The
DSKPP server encrypts keying material using a pre-shared key DSKPP server encrypts keying material using a pre-shared key
wrapping key and transports it to the DSKPP client. The DSKPP wrapping key and transports it to the DSKPP client. The DSKPP
client decrypts the keying material, and uses it to derive the client decrypts the keying material, and uses it to derive the
symmetric key, K_TOKEN. symmetric key, K_TOKEN.
This method is identified with the following URN: This method is identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp#wrap urn:ietf:params:xml:schema:keyprov:dskpp:wrap
The DSKPP server and client MUST support one of the following key The DSKPP server and client MUST support all of the following key
wrapping mechanisms: wrapping mechanisms:
KW-AES128 without padding; refer to
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
KW-AES128 with padding; refer to
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] and
[AESKWPAD]
AES-CBC-128; refer to [FIPS197-AES] AES128 KeyWrap
Refer to id-aes128-wrap in [RFC3394] and
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
AES128 KeyWrap with Padding
Refer to id-aes128-wrap-pad in [RFC5649] and
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
AES-CBC-128
Refer to [FIPS197-AES] and
http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC]
5.1.3. Passphrase-Based Key Wrap 5.1.3. Passphrase-Based Key Wrap
Purpose of this method: Purpose of this method:
This method is a variation of the Key Wrap Method that is This method is a variation of the Key Wrap Method that is
applicable to constrained devices with keypads, e.g., mobile applicable to constrained devices with keypads, e.g., mobile
phones. The DSKPP server encrypts keying material using a phones. The DSKPP server encrypts keying material using a
wrapping key derived from a user-provided passphrase, and wrapping key derived from a user-provided passphrase, and
transports the encrypted material to the DSKPP client. The DSKPP transports the encrypted material to the DSKPP client. The DSKPP
client decrypts the keying material, and uses it to derive the client decrypts the keying material, and uses it to derive the
symmetric key, K_TOKEN. symmetric key, K_TOKEN.
To preserve the property of not exposing K_TOKEN to any other To preserve the property of not exposing K_TOKEN to any other
entity than the DSKPP server and the cryptographic module itself, entity than the DSKPP server and the cryptographic module itself,
the method SHOULD be employed only when the device contains the method SHOULD be employed only when the device contains
facilities (e.g. a keypad) for direct entry of the passphrase. facilities (e.g. a keypad) for direct entry of the passphrase.
This method is identified with the following URN: This method is identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap
The DSKPP server and client MUST support the following: The DSKPP server and client MUST support the following:
* The PBES2 password-based encryption scheme defined in [PKCS-5] * The PBES2 password-based encryption scheme defined in [PKCS-5]
(and identified as (and identified as
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 in http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 in
[PKCS-5-XML]) [PKCS-5-XML])
* The PBKDF2 passphrase-based key derivation function also * The PBKDF2 passphrase-based key derivation function also
defined in [PKCS-5] (and identified as defined in [PKCS-5] (and identified as
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2
in [PKCS-5-XML]) in [PKCS-5-XML])
* One of the following key wrapping mechanisms: * All of the following key wrapping mechanisms:
a. KW-AES128 without padding; refer to
AES128 KeyWrap
Refer to id-aes128-wrap in [RFC3394] and
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
AES128 KeyWrap with Padding
Refer to id-aes128-wrap-pad in [RFC5649] and
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
b. KW-AES128 with padding; refer to
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] and AES-CBC-128
[AESKWPAD] Refer to [FIPS197-AES] and
c. AES-CBC-128; refer to [FIPS197-AES] http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC]
5.2. Message Flow 5.2. Message Flow
The two-pass protocol flow consists of one exchange: The two-pass protocol flow consists of one exchange:
1: Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerFinished> 1: Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerFinished>
Although there is no exchange of the <ServerHello> message or the Although there is no exchange of the <ServerHello> message or the
<ClientNonce> message, the DSKPP client is still able to specify <ClientNonce> message, the DSKPP client is still able to specify
algorithm preferences and supported key types in the algorithm preferences and supported key types in the
<KeyProvClientHello> message. <KeyProvClientHello> message.
skipping to change at page 36, line 19 skipping to change at page 38, line 41
What is contained in this message: What is contained in this message:
The Security Attribute List (SAL) included with The Security Attribute List (SAL) included with
<KeyProvClientHello> contains the combinations of DSKPP versions, <KeyProvClientHello> contains the combinations of DSKPP versions,
variants, key package formats, key types, and cryptographic variants, key package formats, key types, and cryptographic
algorithms that the DSKPP client supports in order of the client's algorithms that the DSKPP client supports in order of the client's
preference (favorite choice first). preference (favorite choice first).
Authentication Data (AD) that was either included with Authentication Data (AD) that was either included with
<KeyProvTrigger>, or generated as described in the "Application <KeyProvTrigger>, or generated as described in the "Application
Note" above. Note" above
The DSKPP client's random nonce (R_C), which is used to compute The DSKPP client's random nonce (R_C), which was used by the
provisioning key (K_PROV). By inserting R_C into the DSKPP client when generating AD. By inserting R_C into the DSKPP
session, the DSKPP client is able to ensure the DSKPP server is session, the DSKPP client is able to ensure the DSKPP server is
live before committing the key. live before committing the key.
If <KeyProvClientHello> was preceded by a <KeyProvTrigger>, then If <KeyProvClientHello> was preceded by a <KeyProvTrigger>, then
this message MUST also include the DeviceID and/or KeyID that was this message MUST also include the DeviceID and/or KeyID that was
provided with the trigger. Otherwise, if a trigger message did provided with the trigger. Otherwise, if a trigger message did
not precede <KeyProvClientHello>, then this message MAY include a not precede <KeyProvClientHello>, then this message MAY include a
device ID that was pre-shared with the DSKPP server, and MAY device ID that was pre-shared with the DSKPP server, and MAY
contain a key ID associated with a key previously provisioned by contain a key ID associated with a key previously provisioned by
the DSKPP provisioning server. the DSKPP provisioning server.
skipping to change at page 37, line 21 skipping to change at page 39, line 41
components of <ds:KeyName> MUST be set to the Client ID and components of <ds:KeyName> MUST be set to the Client ID and
authentication code components of AD (same AD as contained in authentication code components of AD (same AD as contained in
this message). this message).
How the DSKPP server uses this message: How the DSKPP server uses this message:
The DSKPP server will look for an acceptable combination of DSKPP The DSKPP server will look for an acceptable combination of DSKPP
version, variant (in this case, two-pass), key package format, key version, variant (in this case, two-pass), key package format, key
type, and cryptographic algorithms. If the DSKPP Client's SAL type, and cryptographic algorithms. If the DSKPP Client's SAL
does not match the capabilities of the DSKPP Server, or does not does not match the capabilities of the DSKPP Server, or does not
comply with key provisioning policy, then the DSKPP Server will comply with key provisioning policy, then the DSKPP Server will
set the Status attribute to something other than "Continue". set the Status attribute to something other than "Success".
Otherwise, Status will be set to "Continue". Otherwise, Status will be set to "Success".
The DSKPP server will validate the DeviceID and KeyID if included The DSKPP server will validate the DeviceID and KeyID if included
in <KeyProvClientHello>. The DSKPP server MUST NOT accept the in <KeyProvClientHello>. The DSKPP server MUST NOT accept the
DeviceID unless the server sent the DeviceID in a preceding DeviceID unless the server sent the DeviceID in a preceding
trigger message. Note that it is also legitimate for a DSKPP trigger message. Note that it is also legitimate for a DSKPP
client to initiate the DSKPP protocol run without having received client to initiate the DSKPP protocol run without having received
a <KeyProvTrigger> message from a server, but in this case any a <KeyProvTrigger> message from a server, but in this case any
provided DeviceID MUST NOT be accepted by the DSKPP server unless provided DeviceID MUST NOT be accepted by the DSKPP server unless
the server has access to a unique key for the identified device the server has access to a unique key for the identified device
and that key will be used in the protocol. and that key will be used in the protocol.
The DSKPP server MUST use AD to authenticate the user. If The DSKPP server MUST use AD to authenticate the user. If
authentication fails, then the DSKPP server MUST set the return authentication fails, then the DSKPP server MUST set the return
code to a failure status, and MUST, in this case, also delete any code to a failure status, and MUST, in this case, also delete any
nonces, keys, and/or secrets associated with the failed run of the nonces, keys, and/or secrets associated with the failed run of the
protocol. protocol.
If user authentication passes, the DSKPP server generates a key If user authentication passes, the DSKPP server generates a key
K_PROV, which MUST consist of two parts of equal length, where the K_PROV. Note that K_PROV is not derived from the formula in
first half constitutes K_MAC and the second half constitutes Section 4.1.2 that pertains to four-pass protocol usage. In the
K_TOKEN, i.e., two-pass case, K_PROV is randomly generated solely by the DSKPP
server wherein K_PROV MUST consist of two parts of equal length,
i.e.,
K_PROV = K_MAC || K_TOKEN K_PROV = K_MAC || K_TOKEN
The length of K_TOKEN (and hence also the length of K_MAC) is The length of K_TOKEN (and hence also the length of K_MAC) is
determined by the type of K_TOKEN, which MUST be one of the key determined by the type of K_TOKEN, which MUST be one of the key
types supported by the DSKPP client. In cases where the desired types supported by the DSKPP client. In cases where the desired
key length for K_TOKEN is different from the length of K_MAC for key length for K_TOKEN is different from the length of K_MAC for
the underlying MAC algorithm, the greater length of the two MUST the underlying MAC algorithm, the greater length of the two MUST
be chosen to generate K_PROV. The actual MAC key is truncated be chosen to generate K_PROV. The actual MAC key is truncated
from the resulting K_MAC when it is used in the MAC algorithm when from the resulting K_MAC when it is used in the MAC algorithm when
skipping to change at page 39, line 27 skipping to change at page 42, line 4
the <KeyPackage> element of <KeyProvServerFinished>. the <KeyPackage> element of <KeyProvServerFinished>.
If DSKPP-PRF (defined in Section 3.4.2) is used as the MAC If DSKPP-PRF (defined in Section 3.4.2) is used as the MAC
algorithm, then the input parameter s MUST consist of the algorithm, then the input parameter s MUST consist of the
concatenation of the (ASCII) string "MAC 1 computation", msg_hash, concatenation of the (ASCII) string "MAC 1 computation", msg_hash,
and ServerID, and the parameter dsLen MUST be set to the length of and ServerID, and the parameter dsLen MUST be set to the length of
msg_hash. msg_hash.
The method the DSKPP server MUST use to calculate the server The method the DSKPP server MUST use to calculate the server
authentication MAC: authentication MAC:
The MAC MUST be computed on the (ASCII) string "MAC 2 The MAC MUST be computed on the (ASCII) string "MAC 2
computation", the server identifier ServerID, and R, using a pre- computation", the server identifier ServerID, and R, using a pre-
existing MAC key K_MAC' (the MAC key that existed before this existing MAC key K_MAC' (the MAC key that existed before this
protocol run). Note that the implementation may specify K_MAC' to protocol run). Note that the implementation may specify K_MAC' to
be the value of the K_TOKEN that is being replaced, or a version be the value of the K_TOKEN that is being replaced.
of K_MAC from the previous protocol run.
If DSKPP-PRF is used as the MAC algorithm, then the input If DSKPP-PRF is used as the MAC algorithm, then the input
parameter s MUST consist of the concatenation of the (ASCII) parameter s MUST consist of the concatenation of the (ASCII)
string "MAC 2 computation" ServerID, and R. The parameter dsLen string "MAC 2 computation" ServerID, and R. The parameter dsLen
MUST be set to at least 16 (i.e. the length of the MAC MUST be at MUST be set to at least 16 (i.e. the length of the MAC MUST be at
least 16 octets): least 16 octets):
dsLen >= 16 dsLen >= 16
MAC = DSKPP-PRF (K_MAC', "MAC 2 computation" || ServerID || R, MAC = DSKPP-PRF (K_MAC', "MAC 2 computation" || ServerID || R,
skipping to change at page 40, line 25 skipping to change at page 42, line 45
cryptographic server. cryptographic server.
Purpose of this message: Purpose of this message:
With this message the DSKPP server transports a key package With this message the DSKPP server transports a key package
containing the encrypted provisioning key (K_PROV) and key usage containing the encrypted provisioning key (K_PROV) and key usage
attributes. attributes.
What is contained in this message: What is contained in this message:
A status attribute equivalent to the server's return code to A status attribute equivalent to the server's return code to
<KeyProvClientHello>. If the server found an acceptable set of <KeyProvClientHello>. If the server found an acceptable set of
attributes from the client's SAL, then it sets status to Continue. attributes from the client's SAL, then it sets status to Success.
The confirmation message MUST include the Key Package (KP) that The confirmation message MUST include the Key Package (KP) that
holds the DSKPP Server's ID, key ID, key type, encrypted holds the DSKPP Server's ID, key ID, key type, encrypted
provisioning key (K_PROV), encryption method, and additional provisioning key (K_PROV), encryption method, and additional
configuration information. The default symmetric key package configuration information. The default symmetric key package
format is based on the Portable Symmetric Key Container (PSKC) format MUST be based on the Portable Symmetric Key Container
defined in [PSKC]. Alternative formats MAY include [SKPC-ASN.1], (PSKC) defined in [PSKC]. Alternative formats MAY include
PKCS#12 [PKCS-12], or PKCS#5 XML [PKCS-5-XML].
Finally, this message MUST include a MAC that the DSKPP client [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 XML [PKCS-5-XML].
will use for key confirmation. In addition, this message MUST
also include a server authentication MAC (AD) if an existing key This message MUST include a MAC that the DSKPP client will use for
is being replaced. These MACs are calculated as described in the key confirmation. This key confirmation MAC is calculated using
previous section. the "MAC 1 computation" as described in the previous section.
Finally, if an existing key is being replaced, then this message
MUST also include a server authentication MAC (calculated using
the "MAC 2 computation" as described in the previous section),
which is passed as AD to the DSKPP client.
How the DSKPP client uses this message: How the DSKPP client uses this message:
After receiving a <KeyProvServerFinished> message with Status = After receiving a <KeyProvServerFinished> message with Status =
"Success", the DSKPP client MUST verify both MACs (MAC and AD). "Success", the DSKPP client MUST verify both MACs (MAC and AD).
The DSKPP client MUST terminate the DSKPP protocol run if either The DSKPP client MUST terminate the DSKPP protocol run if either
MAC does not verify, and MUST, in this case, also delete any MAC does not verify, and MUST, in this case, also delete any
nonces, keys, and/or secrets associated with the failed run of the nonces, keys, and/or secrets associated with the failed run of the
protocol. protocol.
If <KeyProvServerFinished> has Status = "Success" and the MACs If <KeyProvServerFinished> has Status = "Success" and the MACs
were verified, then the DSKPP client MUST extract K_PROV from the were verified, then the DSKPP client MUST extract K_PROV from the
provided key package, and derive K_TOKEN. Finally, the DSKPP provided key package, and derive K_TOKEN. Finally, the DSKPP
client initializes the cryptographic module with K_TOKEN and the client initializes the cryptographic module with K_TOKEN and the
corresponding key usage attributes. After this operation, it MUST corresponding key usage attributes. After this operation, it MUST
NOT be possible to overwrite the key unless knowledge of an NOT be possible to overwrite the key unless knowledge of an
authorizing key is proven through a MAC on a later authorizing key is proven through a MAC on a later
<KeyProvServerFinished> message. <KeyProvServerFinished> message.
6. Protocol Extensions 6. Protocol Extensions
DSKPP has been designed to be extensible. However, it is possible DSKPP has been designed to be extensible. The sub-sections below
that the use of extensions will harm interoperability; therefore, any define two extensions that are included with the DSKPP schema. Since
use of extensions SHOULD be carefully considered. For example, if a it is possible that the use of extensions will harm interoperability,
particular implementation relies on the presence of a proprietary protocol designers are advised to carefully consider the use of
extension, then it may not be able to interoperate with independent extensions. For example, if a particular implementation relies on
implementations that have no knowledge of this extension. the presence of a proprietary extension, then it may not be able to
interoperate with independent implementations that have no knowledge
of this extension.
Extensions may be sent with any DSKPP message using the
ExtensionsType. The ExtensionsType type is a list of Extensions
containing type-value pairs that define optional features supported
by a DSKPP client or server. Each extension MAY be marked as
Critical by setting the "Critical" attribute of the Extension to
"true". Unless an extension is marked as Critical, a receiving party
need not be able to interpret it; a receiving party is always free to
disregard any (non-critical) extensions.
6.1. The ClientInfoType Extension 6.1. The ClientInfoType Extension
The ClientInfoType extension MAY contain any client-specific data The ClientInfoType extension MAY contain any client-specific data
required of an application. This extension MAY be present in a required of an application. This extension MAY be present in a
<KeyProvClientHello> or <KeyProvClientNonce> message. DSKPP servers <KeyProvClientHello> or <KeyProvClientNonce> message. When present,
MUST support this extension. DSKPP servers MUST NOT attempt to this extension MUST NOT be marked as Critical.
interpret the data it carries and, if received, MUST include it
unmodified in the current protocol run's next server response. DSKPP DSKPP servers MUST support this extension. DSKPP servers MUST NOT
servers need not retain the ClientInfoType data. attempt to interpret the data it carries and, if received, MUST
include it unmodified in the current protocol run's next server
response. DSKPP servers need not retain the ClientInfoType data.
6.2. The ServerInfoType Extension 6.2. The ServerInfoType Extension
The ServerInfoType extension MAY contain any server-specific data The ServerInfoType extension MAY contain any server-specific data
required of an application, e.g., state information. This extension required of an application, e.g., state information. This extension
is only valid in <KeyProvServerHello> messages for which the Status is only valid in <KeyProvServerHello> messages for which the Status
attribute is set to "Continue". DSKPP clients MUST support this attribute is set to "Continue". When present, this extension MUST
extension. DSKPP clients MUST NOT attempt to interpret the data it NOT be marked as Critical.
carries and, if received, MUST include it unmodified in the current
protocol run's next client request (i.e., the <KeyProvClientNonce> DSKPP clients MUST support this extension. DSKPP clients MUST NOT
message). DSKPP clients need not retain the ServerInfoType data. attempt to interpret the data it carries and, if received, MUST
include it unmodified in the current protocol run's next client
request (i.e., the <KeyProvClientNonce> message). DSKPP clients need
not retain the ServerInfoType data.
7. Protocol Bindings 7. Protocol Bindings
7.1. General Requirements 7.1. General Requirements
DSKPP assumes a reliable transport. DSKPP assumes a reliable transport.
7.2. HTTP/1.1 Binding for DSKPP 7.2. HTTP/1.1 Binding for DSKPP
This section presents a binding of the previous messages to HTTP/1.1 This section presents a binding of the previous messages to HTTP/1.1
[RFC2616]. Note that the HTTP client will normally be different from [RFC2616]. This HTTP binding is mandatory-to-implement, although
the DSKPP client (i.e., the HTTP client will "proxy" DSKPP messages newer versions of the specification might define additional bindings
from the DSKPP client to the DSKPP server). Likewise, on the HTTP in the future. Note that the HTTP client will normally be different
server side, the DSKPP server MAY receive DSKPP message from a from the DSKPP client (i.e., the HTTP client will "proxy" DSKPP
"front-end" HTTP server. The DSKPP server will be identified by a messages from the DSKPP client to the DSKPP server). Likewise, on
the HTTP server side, the DSKPP server MAY receive DSKPP message from
a "front-end" HTTP server. The DSKPP server will be identified by a
specific URL, which may be pre-configured, or provided to the client specific URL, which may be pre-configured, or provided to the client
during initialization. during initialization.
7.2.1. Identification of DSKPP Messages 7.2.1. Identification of DSKPP Messages
The MIME-type for all DSKPP messages MUST be The MIME-type for all DSKPP messages MUST be
application/vnd.ietf.keyprov.dskpp+xml application/dskpp+xml
7.2.2. HTTP Headers 7.2.2. HTTP Headers
In order to avoid caching of responses carrying DSKPP messages by In order to avoid caching of responses carrying DSKPP messages by
proxies, the following holds: proxies, the following holds:
o When using HTTP/1.1, requesters SHOULD: o When using HTTP/1.1, requesters SHOULD:
* Include a Cache-Control header field set to "no-cache, no- * Include a Cache-Control header field set to "no-cache, no-
store". store".
* Include a Pragma header field set to "no-cache". * Include a Pragma header field set to "no-cache".
skipping to change at page 44, line 15 skipping to change at page 47, line 11
respond by sending a DSKPP initialization message in an HTTP response respond by sending a DSKPP initialization message in an HTTP response
with Content-Type set according to Section 7.2.1 and response code with Content-Type set according to Section 7.2.1 and response code
set to 406 (Not Acceptable). set to 406 (Not Acceptable).
7.2.7. Example Messages 7.2.7. Example Messages
a. Initialization from DSKPP server: a. Initialization from DSKPP server:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Cache-Control: no-store Cache-Control: no-store
Content-Type: application/vnd.ietf.keyprov.dskpp+xml Content-Type: application/dskpp+xml
Content-Length: <some value> Content-Length: <some value>
DSKPP initialization data in XML form... DSKPP initialization data in XML form...
b. Initial request from DSKPP client: b. Initial request from DSKPP client:
POST http://example.com/cgi-bin/DSKPP-server HTTP/1.1 POST http://example.com/cgi-bin/DSKPP-server HTTP/1.1
Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store
Pragma: no-cache Pragma: no-cache
Host: www.example.com Host: www.example.com
Content-Type: application/vnd.ietf.keyprov.dskpp+xml Content-Type: application/dskpp+xml
Content-Length: <some value> Content-Length: <some value>
DSKPP data in XML form (supported version, supported DSKPP data in XML form (supported version, supported
algorithms...) algorithms...)
c. Initial response from DSKPP server: c. Initial response from DSKPP server:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Cache-Control: no-cache, no-must-revalidate, private Cache-Control: no-cache, no-must-revalidate, private
Pragma: no-cache Pragma: no-cache
Content-Type: application/vnd.ietf.keyprov.dskpp+xml Content-Type: application/dskpp+xml
Content-Length: <some value> Content-Length: <some value>
DSKPP data in XML form (server random nonce, server public key, DSKPP data in XML form (server random nonce, server public key,
...) ...)
8. DSKPP XML Schema 8. DSKPP XML Schema
8.1. General Processing Requirements 8.1. General Processing Requirements
Some DSKPP elements rely on the parties being able to compare Some DSKPP elements rely on the parties being able to compare
received values with stored values. Unless otherwise noted, all received values with stored values. Unless otherwise noted, all
elements that have the XML Schema "xs:string" type, or a type derived elements that have the XML Schema "xs:string" type, or a type derived
from it, MUST be compared using an exact binary comparison. In from it, MUST be compared using an exact binary comparison. In
particular, DSKPP implementations MUST NOT depend on case-insensitive particular, DSKPP implementations MUST NOT depend on case-insensitive
string comparisons, normalization or trimming of white space, or string comparisons, normalization or trimming of white space, or
conversion of locale-specific formats such as numbers. conversion of locale-specific formats such as numbers.
Implementations that compare values that are represented using Implementations that compare values that are represented using
different character encodings MUST use a comparison method that different character encodings MUST use a comparison method that
returns the same result as converting both values to the Unicode returns the same result as converting both values to the Unicode
character encoding, Normalization Form C [UNICODE], and then character encoding and then performing an exact binary comparison.
performing an exact binary comparison.
No collation or sorting order for attributes or element values is No collation or sorting order for attributes or element values is
defined. Therefore, DSKPP implementations MUST NOT depend on defined. Therefore, DSKPP implementations MUST NOT depend on
specific sorting orders for values. specific sorting orders for values.
8.2. Schema 8.2. Schema
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<xs:schema <xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:dskpp" targetNamespace="urn:ietf:params:xml:ns:keyprov:dskpp"
elementFormDefault="qualified" attributeFormDefault="unqualified" elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0"> version="1.0">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation= schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/> xmldsig-core-schema.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:keyprov:pskc" <xs:import namespace="urn:ietf:params:xml:ns:keyprov:pskc"
schemaLocation="keyprov-pskc-1.0.xsd"/> schemaLocation="keyprov-pskc-1.0.xsd"/>
<xs:complexType name="AbstractRequestType" abstract="true"> <xs:complexType name="AbstractRequestType" abstract="true">
<xs:annotation> <xs:annotation>
<xs:documentation> Basic types </xs:documentation> <xs:documentation> Basic types </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:attribute name="Version" type="dskpp:VersionType" <xs:attribute name="Version" type="dskpp:VersionType"
use="required"/> use="required"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="AbstractResponseType" abstract="true"> <xs:complexType name="AbstractResponseType" abstract="true">
<xs:annotation> <xs:annotation>
<xs:documentation> Basic types </xs:documentation> <xs:documentation> Basic types </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:attribute name="Version" type="dskpp:VersionType" <xs:attribute name="Version" type="dskpp:VersionType"
use="required"/> use="required"/>
<xs:attribute name="SessionID" type="dskpp:IdentifierType" /> <xs:attribute name="SessionID" type="dskpp:IdentifierType" />
<xs:attribute name="Status" type="dskpp:StatusCode" use="required"/> <xs:attribute name="Status" type="dskpp:StatusCode"
</xs:complexType> use="required"/>
<xs:simpleType name="VersionType"> </xs:complexType>
<xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="IdentifierType"> <xs:simpleType name="VersionType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:maxLength value="128" /> <xs:pattern value="\d{1,2}\.\d{1,3}" />
</xs:restriction> </xs:restriction>
</xs:simpleType>
<xs:simpleType name="StatusCode"> </xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Continue" />
<xs:enumeration value="Success" />
<xs:enumeration value="Abort" />
<xs:enumeration value="AccessDenied" />
<xs:enumeration value="MalformedRequest" />
<xs:enumeration value="UnknownRequest" />
<xs:enumeration value="UnknownCriticalExtension" />
<xs:enumeration value="UnsupportedVersion" />
<xs:enumeration value="NoSupportedKeyTypes" />
<xs:enumeration value="NoSupportedEncryptionAlgorithms" />
<xs:enumeration value="NoSupportedMacAlgorithms" />
<xs:enumeration value="NoProtocolVariants" />
<xs:enumeration value="NoSupportedKeyPackages" />
<xs:enumeration value="AuthenticationDataMissing" />
<xs:enumeration value="AuthenticationDataInvalid" />
<xs:enumeration value="InitializationFailed" />
<xs:enumeration value="ProvisioningPeriodExpired" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DeviceIdentifierDataType"> <xs:simpleType name="IdentifierType">
<xs:choice> <xs:restriction base="xs:string">
<xs:element name="DeviceId" type="pskc:DeviceInfoType" /> <xs:maxLength value="128" />
<xs:any namespace="##other" processContents="strict" /> </xs:restriction>
</xs:choice> </xs:simpleType>
</xs:complexType>
<xs:simpleType name="PlatformType"> <xs:simpleType name="StatusCode">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="Hardware" /> <xs:enumeration value="Continue" />
<xs:enumeration value="Software" /> <xs:enumeration value="Success" />
<xs:enumeration value="Unspecified" /> <xs:enumeration value="Abort" />
</xs:restriction> <xs:enumeration value="AccessDenied" />
</xs:simpleType> <xs:enumeration value="MalformedRequest" />
<xs:complexType name="TokenPlatformInfoType"> <xs:enumeration value="UnknownRequest" />
<xs:attribute name="KeyLocation" type="dskpp:PlatformType"/> <xs:enumeration value="UnknownCriticalExtension" />
<xs:attribute name="AlgorithmLocation" type="dskpp:PlatformType"/> <xs:enumeration value="UnsupportedVersion" />
</xs:complexType> <xs:enumeration value="NoSupportedKeyTypes" />
<xs:enumeration value="NoSupportedEncryptionAlgorithms" />
<xs:enumeration value="NoSupportedMacAlgorithms" />
<xs:enumeration value="NoProtocolVariants" />
<xs:enumeration value="NoSupportedKeyPackages" />
<xs:enumeration value="AuthenticationDataMissing" />
<xs:enumeration value="AuthenticationDataInvalid" />
<xs:enumeration value="InitializationFailed" />
<xs:enumeration value="ProvisioningPeriodExpired" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="NonceType"> <xs:complexType name="DeviceIdentifierDataType">
<xs:restriction base="xs:base64Binary"> <xs:choice>
<xs:minLength value="16" /> <xs:element name="DeviceId" type="pskc:DeviceInfoType" />
</xs:restriction> <xs:any namespace="##other" processContents="strict" />
</xs:simpleType> </xs:choice>
</xs:complexType>
<xs:complexType name="AlgorithmsType"> <xs:simpleType name="PlatformType">
<xs:sequence maxOccurs="unbounded"> <xs:restriction base="xs:string">
<xs:element name="Algorithm" type="dskpp:AlgorithmType" /> <xs:enumeration value="Hardware" />
</xs:sequence> <xs:enumeration value="Software" />
</xs:complexType> <xs:enumeration value="Unspecified" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="AlgorithmType"> <xs:complexType name="TokenPlatformInfoType">
<xs:restriction base="xs:anyURI" /> <xs:attribute name="KeyLocation"
</xs:simpleType> type="dskpp:PlatformType"/>
<xs:complexType name="ProtocolVariantsType"> <xs:attribute name="AlgorithmLocation"
<xs:sequence> type="dskpp:PlatformType"/>
<xs:element name="FourPass" minOccurs="0" /> </xs:complexType>
<xs:element name="TwoPass" type="dskpp:KeyProtectionDataType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyProtectionDataType"> <xs:simpleType name="NonceType">
<xs:annotation> <xs:restriction base="xs:base64Binary">
<xs:documentation xml:lang="en"> <xs:minLength value="16" />
This element is only valid for two-pass DSKPP. </xs:restriction>
</xs:documentation> </xs:simpleType>
</xs:annotation>
<xs:sequence maxOccurs="unbounded">
<xs:element name="SupportedKeyProtectionMethod" type="xs:anyURI"/>
<xs:element name="Payload" type="dskpp:PayloadType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PayloadType"> <xs:complexType name="AlgorithmsType">
<xs:choice> <xs:sequence maxOccurs="unbounded">
<xs:element name="Nonce" type="dskpp:NonceType" /> <xs:element name="Algorithm" type="dskpp:AlgorithmType"/>
<xs:any namespace="##other" processContents="strict" /> </xs:sequence>
</xs:choice> </xs:complexType>
</xs:complexType>
<xs:complexType name="KeyPackagesFormatType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="KeyPackageFormat"
type="dskpp:KeyPackageFormatType"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="KeyPackageFormatType"> <xs:simpleType name="AlgorithmType">
<xs:restriction base="xs:anyURI" /> <xs:restriction base="xs:anyURI" />
</xs:simpleType> </xs:simpleType>
<xs:complexType name="AuthenticationDataType"> <xs:complexType name="ProtocolVariantsType">
<xs:annotation> <xs:sequence>
<xs:documentation xml:lang="en"> <xs:element name="FourPass" minOccurs="0" />
Authentication data contains a MAC. <xs:element name="TwoPass"
</xs:documentation> type="dskpp:KeyProtectionDataType" minOccurs="0"/>
</xs:annotation> </xs:sequence>
<xs:sequence> </xs:complexType>
<xs:element name="ClientID"
type="dskpp:IdentifierType" minOccurs="0"/>
<xs:choice>
<xs:element name="AuthenticationCodeMac"
type="dskpp:AuthenticationMacType"/>
<xs:any namespace="##other" processContents="strict" />
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AuthenticationMacType"> <xs:complexType name="KeyProtectionDataType">
<xs:sequence> <xs:annotation>
<xs:element minOccurs="0" name="Nonce" type="dskpp:NonceType" /> <xs:documentation xml:lang="en">
<xs:element minOccurs="0" name="IterationCount" type="xs:int" /> This element is only valid for two-pass DSKPP.
<xs:element name="Mac" type="dskpp:MacType" /> </xs:documentation>
</xs:sequence> </xs:annotation>
</xs:complexType> <xs:sequence maxOccurs="unbounded">
<xs:element name="SupportedKeyProtectionMethod"
type="xs:anyURI"/>
<xs:element name="Payload"
type="dskpp:PayloadType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MacType"> <xs:complexType name="PayloadType">
<xs:simpleContent> <xs:choice>
<xs:extension base="xs:base64Binary"> <xs:element name="Nonce" type="dskpp:NonceType" />
<xs:attribute name="MacAlgorithm" type="xs:anyURI" /> <xs:any namespace="##other" processContents="strict"/>
</xs:extension> </xs:choice>
</xs:simpleContent> </xs:complexType>
</xs:complexType> <xs:complexType name="KeyPackagesFormatType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="KeyPackageFormat"
type="dskpp:KeyPackageFormatType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyPackageType"> <xs:simpleType name="KeyPackageFormatType">
<xs:sequence> <xs:restriction base="xs:anyURI" />
<xs:element minOccurs="0" name="ServerID" type="xs:anyURI" /> </xs:simpleType>
<xs:element minOccurs="0" name="KeyProtectionMethod"
type="xs:anyURI" />
<xs:choice>
<xs:element name="KeyContainer" type="pskc:KeyContainerType" />
<xs:any namespace="##other" processContents="strict" />
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="InitializationTriggerType"> <xs:complexType name="AuthenticationDataType">
<xs:sequence> <xs:annotation>
<xs:element minOccurs="0" name="DeviceIdentifierData" <xs:documentation xml:lang="en">
type="dskpp:DeviceIdentifierDataType" /> Authentication data contains a MAC.
<xs:element minOccurs="0" name="KeyID" type="xs:base64Binary" /> </xs:documentation>
<xs:element minOccurs="0" name="TokenPlatformInfo" </xs:annotation>
type="dskpp:TokenPlatformInfoType" /> <xs:sequence>
<xs:element name="AuthenticationData" <xs:element name="ClientID"
type="dskpp:AuthenticationDataType" /> type="dskpp:IdentifierType" minOccurs="0"/>
<xs:element minOccurs="0" name="ServerUrl" type="xs:anyURI" /> <xs:choice>
<xs:any minOccurs="0" namespace="##other" <xs:element name="AuthenticationCodeMac"
processContents="strict" /> type="dskpp:AuthenticationMacType"/>
</xs:sequence> <xs:any namespace="##other" processContents="strict" />
</xs:complexType> </xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ExtensionsType"> <xs:complexType name="AuthenticationMacType">
<xs:annotation> <xs:sequence>
<xs:documentation> Extension types </xs:documentation> <xs:element minOccurs="0" name="Nonce"
</xs:annotation> type="dskpp:NonceType"/>
<xs:sequence maxOccurs="unbounded"> <xs:element minOccurs="0" name="IterationCount"
<xs:element name="Extension" type="dskpp:AbstractExtensionType" /> type="xs:int"/>
</xs:sequence> <xs:element name="Mac" type="dskpp:MacType" />
</xs:complexType> </xs:sequence>
</xs:complexType>
<xs:complexType name="AbstractExtensionType" abstract="true"> <xs:complexType name="MacType">
<xs:attribute name="Critical" type="xs:boolean" /> <xs:simpleContent>
</xs:complexType> <xs:extension base="xs:base64Binary">
<xs:attribute name="MacAlgorithm" type="xs:anyURI"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ClientInfoType"> <xs:complexType name="KeyPackageType">
<xs:complexContent mixed="false"> <xs:sequence>
<xs:extension base="dskpp:AbstractExtensionType"> <xs:element minOccurs="0" name="ServerID"
<xs:sequence> type="xs:anyURI"/>
<xs:element name="Data" type="xs:base64Binary" /> <xs:element minOccurs="0" name="KeyProtectionMethod"
</xs:sequence> type="xs:anyURI" />
</xs:extension> <xs:choice>
</xs:complexContent> <xs:element name="KeyContainer"
</xs:complexType> type="pskc:KeyContainerType"/>
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ServerInfoType"> <xs:complexType name="InitializationTriggerType">
<xs:complexContent mixed="false"> <xs:sequence>
<xs:extension base="dskpp:AbstractExtensionType"> <xs:element minOccurs="0" name="DeviceIdentifierData"
<xs:sequence> type="dskpp:DeviceIdentifierDataType" />
<xs:element name="Data" type="xs:base64Binary" /> <xs:element minOccurs="0" name="KeyID"
</xs:sequence> type="xs:base64Binary"/>
</xs:extension> <xs:element minOccurs="0" name="TokenPlatformInfo"
</xs:complexContent> type="dskpp:TokenPlatformInfoType" />
</xs:complexType> <xs:element name="AuthenticationData"
type="dskpp:AuthenticationDataType" />
<xs:element minOccurs="0" name="ServerUrl"
type="xs:anyURI"/>
<xs:any minOccurs="0" namespace="##other"
processContents="strict" />
</xs:sequence>
</xs:complexType>
<xs:element name="KeyProvTrigger" type="dskpp:KeyProvTriggerType"> <xs:complexType name="ExtensionsType">
<xs:annotation> <xs:annotation>
<xs:documentation> DSKPP PDUs </xs:documentation> <xs:documentation> Extension types </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> <xs:sequence maxOccurs="unbounded">
<xs:complexType name="KeyProvTriggerType"> <xs:element name="Extension"
<xs:annotation> type="dskpp:AbstractExtensionType"/>
<xs:documentation xml:lang="en"> </xs:sequence>
Message used to trigger the device to initiate a </xs:complexType>
DSKPP protocol run.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="InitializationTrigger"
type="dskpp:InitializationTriggerType" />
<xs:any namespace="##other" processContents="strict" />
</xs:choice>
</xs:sequence>
<xs:attribute name="Version" type="dskpp:VersionType" />
</xs:complexType>
<xs:element name="KeyProvClientHello" <xs:complexType name="AbstractExtensionType" abstract="true">
type="dskpp:KeyProvClientHelloPDU"> <xs:attribute name="Critical" type="xs:boolean" />
<xs:annotation> </xs:complexType>
<xs:documentation> KeyProvClientHello PDU </xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvClientHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from DSKPP client to DSKPP server to initiate a
DSKPP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractRequestType">
<xs:sequence>
<xs:element minOccurs="0" name="DeviceIdentifierData"
type="dskpp:DeviceIdentifierDataType" />
<xs:element minOccurs="0" name="KeyID" <xs:complexType name="ClientInfoType">
type="xs:base64Binary" /> <xs:complexContent mixed="false">
<xs:element minOccurs="0" name="ClientNonce" <xs:extension base="dskpp:AbstractExtensionType">
type="dskpp:NonceType" /> <xs:sequence>
<xs:element name="SupportedKeyTypes" <xs:element name="Data" type="xs:base64Binary"/>
type="dskpp:AlgorithmsType" />
<xs:element name="SupportedEncryptionAlgorithms"
type="dskpp:AlgorithmsType" />
<xs:element name="SupportedMacAlgorithms"
type="dskpp:AlgorithmsType" />
<xs:element minOccurs="0" name="SupportedProtocolVariants"
type="dskpp:ProtocolVariantsType" />
<xs:element minOccurs="0" name="SupportedKeyPackages"
type="dskpp:KeyPackagesFormatType" />
<xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationDataType" />
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvServerHello" </xs:sequence>
type="dskpp:KeyProvServerHelloPDU"> </xs:extension>
<xs:annotation> </xs:complexContent>
<xs:documentation> KeyProvServerHello PDU </xs:documentation> </xs:complexType>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvServerHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Response message sent from DSKPP server to DSKPP client
in four-pass DSKPP.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyType" type="dskpp:AlgorithmType" />
<xs:element name="EncryptionAlgorithm"
type="dskpp:AlgorithmType" />
<xs:element name="MacAlgorithm" type="dskpp:AlgorithmType" />
<xs:element name="EncryptionKey" type="ds:KeyInfoType" />
<xs:element name="KeyPackageFormat"
type="dskpp:KeyPackageFormatType" />
<xs:element name="Payload" type="dskpp:PayloadType" />
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
<xs:element minOccurs="0" name="Mac" type="dskpp:MacType" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvClientNonce" <xs:complexType name="ServerInfoType">
type="dskpp:KeyProvClientNoncePDU"> <xs:complexContent mixed="false">
<xs:annotation> <xs:extension base="dskpp:AbstractExtensionType">
<xs:documentation> KeyProvClientNonce PDU </xs:documentation> <xs:sequence>
</xs:annotation> <xs:element name="Data" type="xs:base64Binary"/>
</xs:element> </xs:sequence>
<xs:complexType name="KeyProvClientNoncePDU"> </xs:extension>
<xs:annotation> </xs:complexContent>
<xs:documentation xml:lang="en"> </xs:complexType>
Response message sent from DSKPP client to
DSKPP server in a four-pass DSKPP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractRequestType">
<xs:sequence>
<xs:element name="EncryptedNonce" type="xs:base64Binary" />
<xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationDataType" />
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
</xs:sequence>
<xs:attribute name="SessionID" type="dskpp:IdentifierType"
use="required" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvServerFinished" <xs:element name="KeyProvTrigger"
type="dskpp:KeyProvServerFinishedPDU"> type="dskpp:KeyProvTriggerType">
<xs:annotation> <xs:annotation>
<xs:documentation> KeyProvServerFinished PDU </xs:documentation> <xs:documentation> DSKPP PDUs </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
<xs:complexType name="KeyProvServerFinishedPDU"> <xs:complexType name="KeyProvTriggerType">
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
Final message sent from DSKPP server to DSKPP client in a DSKPP Message used to trigger the device to initiate a
session. A MAC value serves for key confirmation, and optional DSKPP protocol run.
AuthenticationData serves for server authentication. </xs:documentation>
</xs:documentation> </xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="InitializationTrigger"
type="dskpp:InitializationTriggerType" />
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="Version" type="dskpp:VersionType"/>
</xs:complexType>
</xs:annotation> <xs:element name="KeyProvClientHello"
<xs:complexContent mixed="false"> type="dskpp:KeyProvClientHelloPDU">
<xs:extension base="dskpp:AbstractResponseType"> <xs:annotation>
<xs:sequence minOccurs="0"> <xs:documentation>KeyProvClientHello PDU</xs:documentation>
<xs:element name="KeyPackage" </xs:annotation>
type="dskpp:KeyPackageType" /> </xs:element>
<xs:element minOccurs="0" name="Extensions" <xs:complexType name="KeyProvClientHelloPDU">
type="dskpp:ExtensionsType" /> <xs:annotation>
<xs:element name="Mac" type="dskpp:MacType" /> <xs:documentation xml:lang="en">
<xs:element minOccurs="0" name="AuthenticationData" Message sent from DSKPP client to DSKPP server to
type="dskpp:AuthenticationMacType" /> initiate a DSKPP session.
</xs:sequence> </xs:documentation>
</xs:extension> </xs:annotation>
</xs:complexContent> <xs:complexContent mixed="false">
</xs:complexType> <xs:extension base="dskpp:AbstractRequestType">
</xs:schema> <xs:sequence>
<xs:element minOccurs="0" name="DeviceIdentifierData"
type="dskpp:DeviceIdentifierDataType" />
<xs:element minOccurs="0" name="KeyID"
type="xs:base64Binary" />
<xs:element minOccurs="0" name="ClientNonce"
type="dskpp:NonceType" />
<xs:element name="SupportedKeyTypes"
type="dskpp:AlgorithmsType" />
<xs:element name="SupportedEncryptionAlgorithms"
type="dskpp:AlgorithmsType" />
<xs:element name="SupportedMacAlgorithms"
type="dskpp:AlgorithmsType" />
<xs:element minOccurs="0"
name="SupportedProtocolVariants"
type="dskpp:ProtocolVariantsType" />
<xs:element minOccurs="0" name="SupportedKeyPackages"
type="dskpp:KeyPackagesFormatType" />
<xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationDataType" />
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvServerHello"
type="dskpp:KeyProvServerHelloPDU">
<xs:annotation>
<xs:documentation>KeyProvServerHello PDU</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvServerHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Response message sent from DSKPP server to DSKPP client
in four-pass DSKPP.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyType"
type="dskpp:AlgorithmType"/>
<xs:element name="EncryptionAlgorithm"
type="dskpp:AlgorithmType" />
<xs:element name="MacAlgorithm"
type="dskpp:AlgorithmType"/>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType"/>
<xs:element name="KeyPackageFormat"
type="dskpp:KeyPackageFormatType" />
<xs:element name="Payload" type="dskpp:PayloadType"/>
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
<xs:element minOccurs="0" name="Mac"
type="dskpp:MacType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvClientNonce"
type="dskpp:KeyProvClientNoncePDU">
<xs:annotation>
<xs:documentation>KeyProvClientNonce PDU</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvClientNoncePDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Response message sent from DSKPP client to
DSKPP server in a four-pass DSKPP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractRequestType">
<xs:sequence>
<xs:element name="EncryptedNonce"
type="xs:base64Binary"/>
<xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationDataType" />
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
</xs:sequence>
<xs:attribute name="SessionID"
type="dskpp:IdentifierType" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvServerFinished"
type="dskpp:KeyProvServerFinishedPDU">
<xs:annotation>
<xs:documentation>
KeyProvServerFinished PDU
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvServerFinishedPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Final message sent from DSKPP server to DSKPP client in
a DSKPP session. A MAC value serves for key
confirmation, and optional AuthenticationData serves for
server authentication.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyPackage"
type="dskpp:KeyPackageType" />
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
<xs:element name="Mac" type="dskpp:MacType" />
<xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationMacType" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
9. Conformance Requirements 9. Conformance Requirements
In order to assure that all implementations of DSKPP can In order to assure that all implementations of DSKPP can
interoperate, the DSKPP server: interoperate, the DSKPP server:
a. MUST implement the four-pass variation of the protocol a. MUST implement the four-pass variation of the protocol
(Section 4) (Section 4)
b. MUST implement the two-pass variation of the protocol (Section 5) b. MUST implement the two-pass variation of the protocol (Section 5)
skipping to change at page 53, line 48 skipping to change at page 57, line 20
e. MUST support the following encryption mechanisms for protection e. MUST support the following encryption mechanisms for protection
of the client nonce in the four-pass protocol: of the client nonce in the four-pass protocol:
* Mechanism described in Section 4.2.4 * Mechanism described in Section 4.2.4
f. MUST support one of the following encryption algorithms for f. MUST support one of the following encryption algorithms for
symmetric key operations, e.g., key wrap: symmetric key operations, e.g., key wrap:
* KW-AES128 without padding; refer to * KW-AES128 without padding; refer to
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
* KW-AES128 with padding; refer to * KW-AES128 with padding; refer to
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] and http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] and
[AESKWPAD] [RFC5649]
* AES-CBC-128; refer to [FIPS197-AES] * AES-CBC-128; refer to [FIPS197-AES]
g. MUST support the following encryption algorithms for asymmetric g. MUST support the following encryption algorithms for asymmetric
key operations, e.g., key transport: key operations, e.g., key transport:
* RSA Encryption Scheme [PKCS-1] * RSA Encryption Scheme [PKCS-1]
h. MUST support the following integrity/KDF MAC functions: h. MUST support the following integrity/KDF MAC functions:
* DSKPP-PRF-AES (Appendix D) * DSKPP-PRF-AES (Appendix D)
* DSKPP-PRF-SHA256 (Appendix D) * DSKPP-PRF-SHA256 (Appendix D)
i. MUST support the PSKC key package [PSKC]; all three PSKC key i. MUST support the PSKC key package [PSKC]; all three PSKC key
protection methods (Key Transport, Key Wrap, and Passphrase-Based protection methods (Key Transport, Key Wrap, and Passphrase-Based
Key Wrap) MUST be implemented Key Wrap) MUST be implemented
j. MAY support the ASN.1 key package as defined in [SKPC-ASN.1] j. MAY support the ASN.1 key package as defined in [SKPC-ASN.1]
DSKPP clients MUST support either the two-pass or the four-pass DSKPP clients MUST support either the two-pass or the four-pass
variant of the protocol. DSKPP clients MUST fulfill all requirements variant of the protocol. DSKPP clients MUST fulfill all requirements
listed in item (c) - (j). listed in item (c) - (j).
Finally, implementations of DSKPP MUST bind DSKPP messages to
HTTP/1.1 as described in Section 7.2.
Of course, DSKPP is a security protocol, and one of its major Of course, DSKPP is a security protocol, and one of its major
functions is to allow only authorized parties to successfully functions is to allow only authorized parties to successfully
initialize a cryptographic module with a new symmetric key. initialize a cryptographic module with a new symmetric key.
Therefore, a particular implementation may be configured with any of Therefore, a particular implementation may be configured with any of
a number of restrictions concerning algorithms and trusted a number of restrictions concerning algorithms and trusted
authorities that will prevent universal interoperability. authorities that will prevent universal interoperability.
10. Security Considerations 10. Security Considerations
10.1. General 10.1. General
DSKPP is designed to protect generated keying material from exposure. DSKPP is designed to protect generated keying material from exposure.
No other entities than the DSKPP server and the cryptographic module No other entities than the DSKPP server and the cryptographic module
will have access to a generated K_TOKEN if the cryptographic will have access to a generated K_TOKEN if the cryptographic
algorithms used are of sufficient strength and, on the DSKPP client algorithms used are of sufficient strength and, on the DSKPP client
side, generation and encryption of R_C and generation of K_TOKEN take side, generation and encryption of R_C and generation of K_TOKEN take
place as specified in the cryptographic module. This applies even if place as specified in the cryptographic module. This applies even if
malicious software is present in the DSKPP client. However, as malicious software is present in the DSKPP client. However, as
discussed in the following sub-sections, DSKPP does not protect discussed in the following sub-sections, DSKPP does not protect
against certain other threats resulting from man-in-the-middle against certain other threats resulting from man-in-the-middle
attacks and other forms of attacks. DSKPP SHOULD, therefore, be run attacks and other forms of attacks. DSKPP MUST, therefore, be run
over a transport providing confidentiality and integrity, such as over a transport providing confidentiality and integrity, such as
HTTP over Transport Layer Security (TLS) with a suitable ciphersuite, HTTP over Transport Layer Security (TLS) with a suitable ciphersuite,
when such threats are a concern. Note that TLS ciphersuites with when such threats are a concern. Note that TLS ciphersuites with
anonymous key exchanges are not suitable in those situations. anonymous key exchanges are not suitable in those situations.
10.2. Active Attacks 10.2. Active Attacks
10.2.1. Introduction 10.2.1. Introduction
An active attacker MAY attempt to modify, delete, insert, replay, or An active attacker MAY attempt to modify, delete, insert, replay, or
skipping to change at page 58, line 24 skipping to change at page 61, line 40
o The identifiers of keys on those cryptographic modules and other o The identifiers of keys on those cryptographic modules and other
attributes pertaining to those keys, e.g., the lifetime of the attributes pertaining to those keys, e.g., the lifetime of the
keys keys
o DSKPP versions and cryptographic algorithms supported by a o DSKPP versions and cryptographic algorithms supported by a
particular DSKPP client or server particular DSKPP client or server
o Any value present in an <extension> that is part of o Any value present in an <extension> that is part of
<KeyProvClientHello> <KeyProvClientHello>
Whenever the above is a concern, DSKPP SHOULD be run over a transport Whenever the above is a concern, DSKPP SHOULD be run over a transport
providing confidentiality. If man-in-the-middle attacks for the providing confidentiality. If man-in-the-middle attacks for the
purposes described above are a concern, the transport SHOULD also purposes described above are a concern, the transport MUST also offer
offer server-side authentication. server-side authentication.
10.4. Cryptographic Attacks 10.4. Cryptographic Attacks
An attacker with unlimited access to an initialized cryptographic An attacker with unlimited access to an initialized cryptographic
module may use the module as an "oracle" to pre-compute values that module may use the module as an "oracle" to pre-compute values that
later on may be used to impersonate the DSKPP server. Section 4.1.1 later on may be used to impersonate the DSKPP server. Section 4.1.1
contains a discussion of this threat and steps RECOMMENDED to protect contains a discussion of this threat and steps RECOMMENDED to protect
against it. against it.
Implementers SHOULD also be aware that cryptographic algorithms Implementers are advised that cryptographic algorithms become weaker
become weaker with time. As new cryptographic techniques are with time. As new cryptographic techniques are developed and
developed and computing performance improves, the work factor to computing performance improves, the work factor to break a particular
break a particular cryptographic algorithm will reduce. Therefore, cryptographic algorithm will reduce. Therefore, cryptographic
cryptographic algorithm implementations SHOULD be modular allowing algorithm implementations SHOULD be modular allowing new algorithms
new algorithms to be readily inserted. That is, implementers SHOULD to be readily inserted. That is, implementers SHOULD be prepared to
be prepared to regularly update the algorithms in their regularly update the algorithms in their implementations.
implementations.
10.5. Attacks on the Interaction between DSKPP and User Authentication 10.5. Attacks on the Interaction between DSKPP and User Authentication
If keys generated in DSKPP will be associated with a particular user If keys generated in DSKPP will be associated with a particular user
at the DSKPP server (or a server trusted by, and communicating with at the DSKPP server (or a server trusted by, and communicating with
the DSKPP server), then in order to protect against threats where an the DSKPP server), then in order to protect against threats where an
attacker replaces a client-provided encrypted R_C with his own R'C attacker replaces a client-provided encrypted R_C with his own R'C
(regardless of whether the public-key variation or the shared-secret (regardless of whether the public-key variation or the shared-secret
variation of DSKPP is employed to encrypt the client nonce), the variation of DSKPP is employed to encrypt the client nonce), the
server SHOULD NOT commit to associate a generated K_TOKEN with the server SHOULD NOT commit to associate a generated K_TOKEN with the
skipping to change at page 60, line 15 skipping to change at page 63, line 32
10.6.3. Server Authentication 10.6.3. Server Authentication
DSKPP servers MUST authenticate themselves whenever a successful DSKPP servers MUST authenticate themselves whenever a successful
DSKPP 2-pass protocol run would result in an existing K_TOKEN being DSKPP 2-pass protocol run would result in an existing K_TOKEN being
replaced by a K_TOKEN', or else a denial-of-service attack where an replaced by a K_TOKEN', or else a denial-of-service attack where an
unauthorized DSKPP server replaces a K_TOKEN with another key would unauthorized DSKPP server replaces a K_TOKEN with another key would
be possible. In 2-pass DSKPP, servers authenticate by including the be possible. In 2-pass DSKPP, servers authenticate by including the
AuthenticationDataType extension containing a MAC as described in AuthenticationDataType extension containing a MAC as described in
Section 5 for two-pass DSKPP. Section 5 for two-pass DSKPP.
Whenever a successful DSKPP 2-pass protocol run would result in an
existing K_TOKEN being replaced by a K_TOKEN', the DSKPP client and
server MUST do the following to prevent a denial-of-service attack
where an unauthorized DSKPP server replaces a K_TOKEN with another
key:
o The DSKPP server MUST use the AuthenticationDataType extension to
transmit a second MAC, calculated as described in Section 5.2.2.
o The DSKPP client MUST authenticate the server using the MAC
contained in the AuthenticationDataType extension received from
the DSKPP server to which it is connected.
10.6.4. User Authentication 10.6.4. User Authentication
A DSKPP server MUST authenticate a client to ensure that K_TOKEN is A DSKPP server MUST authenticate a client to ensure that K_TOKEN is
delivered to the intended device. The following measures SHOULD be delivered to the intended device. The following measures SHOULD be
considered: considered:
o When an Authentication Code is used for client authentication, a o When an Authentication Code is used for client authentication, a
password dictionary attack on the authentication data is possible. password dictionary attack on the authentication data is possible.
o The length of the Authentication Code when used over a non-secure o The length of the Authentication Code when used over a non-secure
channel SHOULD be longer than what is used over a secure channel. channel SHOULD be longer than what is used over a secure channel.
When a device, e.g., some mobile phones with small screens, cannot When a device, e.g., some mobile phones with small screens, cannot
handle a long Authentication Code in a user-friendly manner, DSKPP handle a long Authentication Code in a user-friendly manner, DSKPP
SHOULD rely on a secure channel for communication. SHOULD rely on a secure channel for communication.
o In the case that a non-secure channel has to be used, the o In the case that a non-secure channel has to be used, the
Authentication Code SHOULD be sent to the server MAC'd as Authentication Code SHOULD be sent to the server MAC'd as
specified in Section 3.4.1. The Authentication Code and nonce specified in Section 3.4.1. The Authentication Code and nonce
value MUST be strong enough to prevent offline brute-force value MUST be strong enough to prevent offline brute-force
recovery of the Authentication Code from the HMAC data. Given recovery of the Authentication Code from the HMAC data. Given
skipping to change at page 62, line 8 skipping to change at page 65, line 39
for DSKPP, except for the key size in the computation of DSKPP-PRF. for DSKPP, except for the key size in the computation of DSKPP-PRF.
Another reason was that protocols did not support algorithm Another reason was that protocols did not support algorithm
negotiation. This is also not the case for DSKPP, except for the use negotiation. This is also not the case for DSKPP, except for the use
of SHA-256 in the MAC confirmation message. Updating the key size of SHA-256 in the MAC confirmation message. Updating the key size
for DSKPP-PRF or the MAC confirmation message algorithm will require for DSKPP-PRF or the MAC confirmation message algorithm will require
a new version of the protocol, which is supported with the Version a new version of the protocol, which is supported with the Version
attribute. attribute.
11. Internationalization Considerations 11. Internationalization Considerations
The DSKPP protocol is mostly meant for machine-to-machine The DSKPP protocol is meant for machine-to-machine communications; as
communications; as such, most of its elements are tokens not meant such, its elements are tokens not meant for direct human consumption.
for direct human consumption. If these tokens are presented to the DSKPP exchanges information using XML. All XML processors are
end user, some localization may need to occur. DSKPP exchanges required to understand UTF-8 [RFC3629] encoding, and therefore all
information using XML. All XML processors are required to understand DSKPP clients and servers MUST understand UTF-8 encoded XML.
UTF-8 [RFC3629] and UTF-16 [RFC2781] encoding, and therefore all Additionally, DSKPP servers and clients MUST NOT encode XML with
DSKPP clients and servers MUST understand UTF-8 and UTF-16 encoded encodings other than UTF-8.
XML. Additionally, DSKPP servers and clients MUST NOT encode XML
with encodings other than UTF-8 or UTF-16.
12. IANA Considerations 12. IANA Considerations
This document requires several IANA registrations, detailed below. This document requires several IANA registrations, detailed below.
12.1. URN Sub-Namespace Registration 12.1. URN Sub-Namespace Registration
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:keyprov:dskpp" per the guidelines in "urn:ietf:params:xml:ns:keyprov:dskpp" per the guidelines in
[RFC3688]: [RFC3688]:
skipping to change at page 63, line 28 skipping to change at page 67, line 11
12.3. MIME Media Type Registration 12.3. MIME Media Type Registration
This section registers the "application/dskpp+xml" MIME type: This section registers the "application/dskpp+xml" MIME type:
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/dskpp+xml Subject: Registration of MIME media type application/dskpp+xml
MIME media type name: application MIME media type name: application
MIME subtype name: dskpp+xml MIME subtype name: dskpp+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML.
UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See characters, depending on the character encoding used. See
[RFC3203], Section 3.2. [RFC3203], Section 3.2. Implementations need to support both
[RFC3629].
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
protocol data related to key management. Security mechanisms are protocol data related to key management. Security mechanisms are
built into the protocol to ensure that various threats are dealt built into the protocol to ensure that various threats are dealt
with. with. Refer to Section 10 of the Published Specification for more
Interoperability considerations: This content type provides a basis details
for a protocol. Interoperability considerations: None
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.] replace XXXX with the RFC number for this specification.]
Applications which use this media type: Protocol for key exchange. Applications which use this media type: Protocol for key exchange.
Additional information: Additional information:
Magic Number(s): (none) Magic Number(s): (none)
File extension(s): .xmls File extension(s): .xmls
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Person & email address to contact for further information:
Andrea Doherty (andrea.doherty@rsa.com) Andrea Doherty (andrea.doherty@rsa.com)
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [RFC3203], and many of the considerations application/xml [RFC3203], and many of the considerations
described there also apply to application/dskpp+xml. described there also apply to application/dskpp+xml.
12.4. Status Code Registry 12.4. Status Code Registration
This section registers status codes included in each DSKPP response This section registers status codes included in each DSKPP response
message. The status codes are defined in the schema in the message. The status codes are defined in the schema in the
<StatusCode> type definition contained in the XML schema in <StatusCode> type definition contained in the XML schema in
Section 8. The following summarizes the registry: Section 8. The following summarizes the registry:
Related Registry: Related Registry:
KEYPROV DSKPP Registries, Status codes for DSKPP KEYPROV DSKPP Registries, Status codes for DSKPP
Defining RFC: Defining RFC:
RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the
RFC number for this specification.] RFC number for this specification.]
Registration/Assignment Procedures: Registration/Assignment Procedures:
Following the policies outlined in [RFC3575], the IANA policy for Following the policies outlined in [RFC3575], the IANA policy for
assigning new values for the status codes for DSKPP MUST be assigning new values for the status codes for DSKPP MUST be
"Specification Required" and their meanings MUST be documented in "Specification Required" and their meanings MUST be documented in
an RFC or in some other permanent and readily available reference, an RFC or in some other permanent and readily available reference,
in sufficient detail that interoperability between independent in sufficient detail that interoperability between independent
implementations is possible. No mechanism to mark entries as implementations is possible. No mechanism to mark entries as
"deprecated" is envisioned. It is possible to delete or update "deprecated" is envisioned. It is possible to update entries from
entries from the registry. the registry.
Registrant Contact:
IETF, KEYPROV working group (keyprov@ietf.org),
Andrea Doherty (andrea.doherty@rsa.com)
12.5. DSKPP Version Registration
This section registers DSKPP version numbers. The registry has the
following structure:
+-------------------------------------------+
| DSKPP Version | Specification |
+-------------------------------------------+
| 1.0 | [This document] |
+-------------------------------------------+
Standards action is required to define new versions of DSKPP. It is
not envisioned to deprecate, delete, or modify existing DSKPP
versions.
12.6. PRF Algorithm ID Sub-Registry
This specification relies on a cryptographic primitive, called
"DSKPP-PRF" that provides a deterministic transformation of a secret
key k and a varying length octet string s to a bit string of
specified length dsLen. From the point of view of this
specification, DSKPP-PRF is a "black-box" function that, given the
inputs, generates a pseudorandom value that can be realized by any
appropriate and competent cryptographic technique. . Section 3.4.2
provides two realizations of DSKPP-PRF, DSKPP-PRF-AES and DSKPP-PRF-
SHA256. This section registers the identifiers associated with these
realizations.
12.6.1. DSKPP-PRF-AES
Common Name:
DSKPP-PRF-AES
URI:
urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
Identifier Definition:
The DSKPP-PRF-AES algorithm realization is defined in
Appendix D.2.2 of this document.
Registrant Contact:
IETF, KEYPROV working group (keyprov@ietf.org),
Andrea Doherty (andrea.doherty@rsa.com)
12.6.2. DSKPP-PRF-SHA256
Common Name:
DSKPP-PRF-SHA256
URI:
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
Identifier Definition:
The DSKPP-PRF-SHA256 algorithm realization is defined in
Appendix D.3.2 of this document.
Registrant Contact:
IETF, KEYPROV working group (keyprov@ietf.org),
Andrea Doherty (andrea.doherty@rsa.com)
12.7. Key Container Registration
This section registers the Key Container type.
Key Container:
The registration name for the Key Container.
Specification:
Key Container defines a key package format that specifies how a
key should be protected using the three key protection methods
provided in Section 5.1.
Deprecated:
TRUE if based on expert approval this entry has been deprecated
and SHOULD NOT be used in any new implementations. Otherwise
FALSE.
Identifiers:
The initial URIs for the Key Container defined for this version of
the document are listed here:
Name: PSKC Key Container
URI: urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
Specification: [PSKC]
Deprecated: FALSE
Name: SKPC Key Container
URI: urn:ietf:params:xml:ns:keyprov:dskpp:skpc-key-container
Specification: [SKPC-ASN.1]
Deprecated: FALSE
Name: PKCS12 Key Container
URI: urn:ietf:params:xml:ns:keyprov:dskpp:pkcs12-key-container
Specification: [PKCS-12]
Deprecated: FALSE
Name: PKCS5-XML Key Container
URI: urn:ietf:params:xml:ns:keyprov:dskpp:pkcs5-xml-key-container
Specification: [PKCS-5-XML]
Deprecated: FALSE
Registrant Contact: Registrant Contact:
IETF, KEYPROV working group (keyprov@ietf.org), IETF, KEYPROV working group (keyprov@ietf.org),
Andrea Doherty (andrea.doherty@rsa.com) Andrea Doherty (andrea.doherty@rsa.com)
13. Intellectual Property Considerations 13. Intellectual Property Considerations
RSA and RSA Security are registered trademarks or trademarks of RSA RSA and RSA Security are registered trademarks or trademarks of RSA
Security Inc. in the United States and/or other countries. The names Security Inc. in the United States and/or other countries. The names
of other products and services mentioned may be the trademarks of of other products and services mentioned may be the trademarks of
skipping to change at page 65, line 28 skipping to change at page 71, line 23
o Shuh Chang (Review June 2007) o Shuh Chang (Review June 2007)
o Hannes Tschofenig (Review June 2007 and again in August 2007) o Hannes Tschofenig (Review June 2007 and again in August 2007)
o Sean Turner (Reviews August 2007 and again in July 2008) o Sean Turner (Reviews August 2007 and again in July 2008)
o John Linn (Review August 2007) o John Linn (Review August 2007)
o Philip Hoyer (Review September 2007) o Philip Hoyer (Review September 2007)
o Thomas Roessler (Review November 2007) o Thomas Roessler (Review November 2007)
o Lakshminath Dondeti (Comments December 2007) o Lakshminath Dondeti (Comments December 2007)
o Pasi Eronen (Comments December 2007) o Pasi Eronen (Comments December 2007)
o Phillip Hallam-Baker (Review and Edits November 2008 and again in o Phillip Hallam-Baker (Review and Edits November 2008 and again in
January 2009) January 2009)
o Alexey Melnikov (Review May 2010)
o Peter Saint-Andre (Review May 2010)
We would also like to thank the following for their input to selected We would also like to thank the following for their input to selected
design aspects of the DSKPP protocol: design aspects of the DSKPP protocol:
o Anders Rundgren (Key Package Format and Client Authentication o Anders Rundgren (Key Package Format and Client Authentication
Data) Data)
o Thomas Roessler (HTTP Binding) o Thomas Roessler (HTTP Binding)
o Hannes Tschofenig (HTTP Binding) o Hannes Tschofenig (HTTP Binding)
o Phillip Hallam-Baker (Registry for Algorithms) o Phillip Hallam-Baker (Registry for Algorithms)
o N. Asokan (original observation of weakness in Authentication o N. Asokan (original observation of weakness in Authentication
skipping to change at page 66, line 18 skipping to change at page 72, line 13
Hash Standard", FIPS 180-2, February 2004, <http:// Hash Standard", FIPS 180-2, February 2004, <http://
csrc.nist.gov/publications/fips/fips180-2/ csrc.nist.gov/publications/fips/fips180-2/
fips180-2withchangenotice.pdf>. fips180-2withchangenotice.pdf>.
[FIPS197-AES] [FIPS197-AES]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard "Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001, <http://csrc.nist.gov/ (AES)", FIPS 197, November 2001, <http://csrc.nist.gov/
publications/fips/fips197/fips-197.pdf>. publications/fips/fips197/fips-197.pdf>.
[IDNA2008]
Resnick, P. and P. Hoffman, "Mapping Characters in
IDNA2008", April 2010, <http://www.rfc-editor.org/
internet-drafts/draft-resman-idna2008-mappings-01.txt>.
[ISO3309] "ISO Information Processing Systems - Data Communication -
High-Level Data Link Control Procedure - Frame Structure",
IS 3309, 3rd Edition, October 1984.
[PKCS-1] RSA Laboratories, "RSA Cryptography Standard", PKCS #1 [PKCS-1] RSA Laboratories, "RSA Cryptography Standard", PKCS #1
Version 2.1, June 2002, Version 2.1, June 2002,
<http://www.rsasecurity.com/rsalabs/pkcs/>. <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS-5] RSA Laboratories, "Password-Based Cryptography Standard", [PKCS-5] RSA Laboratories, "Password-Based Cryptography Standard",
PKCS #5 Version 2.0, March 1999, PKCS #5 Version 2.0, March 1999,
<http://www.rsasecurity.com/rsalabs/pkcs/>. <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS-5-XML] [PKCS-5-XML]
RSA Laboratories, "XML Schema for PKCS #5 Version 2.0", RSA Laboratories, "XML Schema for PKCS #5 Version 2.0",
PKCS #5 Version 2.0 Amd.1 (FINAL DRAFT), October 2006, PKCS #5 Version 2.0 Amd.1 (FINAL DRAFT), October 2006,
<http://www.rsasecurity.com/rsalabs/pkcs/>. <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PSKC] "Portable Symmetric Key Container", 2008, <org/ [PSKC] "Portable Symmetric Key Container", 2010,
internet-drafts/ <http://tools.ietf.org/html/draft-ietf-keyprov-pskc-09>.
draft-hoyer-keyprov-portable-symmetric-key-container-
03.txt>.
[RFC2104] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997, <http://www.ietf.org/rfc/rfc2104.txt>. February 1997, <http://www.ietf.org/rfc/rfc2104.txt>.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997, Levels", BCP 14, RFC 2119, March 1997,
<http://www.ietf.org/rfc/rfc2119.txt>. <http://www.ietf.org/rfc/rfc2119.txt>.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
10646", February 2000, Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
<http://www.ietf.org/rfc/rfc2781.txt>. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
<http://www.ietf.org/rfc/rfc2616.txt>.
[RFC3394] Schaad , J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002,
<http://www.ietf.org/rfc/rfc3394.txt>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646", [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646",
STD 63, RFC 3629, November 2003, STD 63, RFC 3629, November 2003,
<http://www.ietf.org/rfc/rfc3629.txt>. <http://www.ietf.org/rfc/rfc3629.txt>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate "Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, September 2005, Management Protocol (CMP)", RFC 4210, September 2005,
<http://www.ietf.org/rfc/rfc4210.txt>. <http://www.ietf.org/rfc/rfc4210.txt>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, June 2008, (CMC)", RFC 5272, June 2008,
<http://www.ietf.org/rfc/rfc5272.txt>. <http://www.ietf.org/rfc/rfc5272.txt>.
[UNICODE] Davis, M. and M. Duerst, "Unicode Normalization Forms", [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
March 2001, Housley, R., and W. Polk, "Internet X.509 Public Key
<http://www.unicode.org/unicode/reports/tr15/ Infrastructure Certificate and Certificate Revocation List
tr15-21.html>. (CRL) Profile", RFC 5280, May 2008,
<http://www.ietf.org/rfc/rfc5280.txt>.
[RFC5649] Housley, R. and M. Dworkin , "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649,
August 2009, <http://www.ietf.org/rfc/rfc5649.txt>.
[XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", W3C Recommendation, November 2008,
<http://www.w3.org/TR/2006/REC-xml-20060816/>.
[XMLDSIG] W3C, "XML Signature Syntax and Processing", [XMLDSIG] W3C, "XML Signature Syntax and Processing",
W3C Recommendation, February 2002, W3C Recommendation, February 2002,
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>. <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.
[XMLENC] W3C, "XML Encryption Syntax and Processing", [XMLENC] W3C, "XML Encryption Syntax and Processing",
W3C Recommendation, December 2002, W3C Recommendation, December 2002,
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>. <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.
16.2. Informative references 16.2. Informative references
[AESKWPAD]
Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", March 2009, <http:
//www.ietf.org/internet-drafts/
draft-housley-aes-key-wrap-with-pad-02.txt>.
[CT-KIP-P11] [CT-KIP-P11]
RSA Laboratories, "PKCS #11 Mechanisms for the RSA Laboratories, "PKCS #11 Mechanisms for the
Cryptographic Token Key Initialization Protocol", PKCS #11 Cryptographic Token Key Initialization Protocol", PKCS #11
Version 2.20 Amd.2, December 2005, Version 2.20 Amd.2, December 2005,
<http://www.rsasecurity.com/rsalabs/pkcs/>. <http://www.rsasecurity.com/rsalabs/pkcs/>.
[FAQ] RSA Laboratories, "Frequently Asked Questions About [FAQ] RSA Laboratories, "Frequently Asked Questions About
Today's Cryptography", Version 4.1, 2000. Today's Cryptography", Version 4.1, 2000.
[ISO3309] "ISO Information Processing Systems - Data Communication -
High-Level Data Link Control Procedure - Frame Structure",
IS 3309, 3rd Edition, October 1984.
[NIST-PWD] [NIST-PWD]
National Institute of Standards and Technology, "Password National Institute of Standards and Technology, "Password
Usage", FIPS 112, May 1985, Usage", FIPS 112, May 1985,
<http://www.itl.nist.gov/fipspubs/fip112.htm>. <http://www.itl.nist.gov/fipspubs/fip112.htm>.
[NIST-SP800-38B] [NIST-SP800-38B]
International Organization for Standardization, International Organization for Standardization,
"Recommendations for Block Cipher Modes of Operation: The "Recommendations for Block Cipher Modes of Operation: The
CMAC Mode for Authentication", NIST SP800-38B, May 2005, < CMAC Mode for Authentication", NIST SP800-38B, May 2005, <
http://csrc.nist.gov/publications/nistpubs/800-38B/ http://csrc.nist.gov/publications/nistpubs/800-38B/
skipping to change at page 68, line 28 skipping to change at page 74, line 33
[PKCS-11] RSA Laboratories, "Cryptographic Token Interface [PKCS-11] RSA Laboratories, "Cryptographic Token Interface
Standard", PKCS #11 Version 2.20, June 2004, Standard", PKCS #11 Version 2.20, June 2004,
<http://www.rsasecurity.com/rsalabs/pkcs/>. <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS-12] "Personal Information Exchange Syntax Standard", PKCS #12 [PKCS-12] "Personal Information Exchange Syntax Standard", PKCS #12
Version 1.0, 2005, Version 1.0, 2005,
<ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/ <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/
pkcs-12v1.pdf>. pkcs-12v1.pdf>.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000,
Resource Identifiers (URI): Generic Syntax", RFC 2396, <http://www.ietf.org/rfc/rfc2818.txt>.
August 1998, <http://www.ietf.org/rfc/rfc2396.txt>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
<http://www.ietf.org/rfc/rfc2616.txt>.
[RFC3203] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3203] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3203, January 2001, Types", RFC 3203, January 2001,
<http://www.ietf.org/rfc/rfc3203.txt>. <http://www.ietf.org/rfc/rfc3203.txt>.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575,
July 2003, <http://www.ietf.org/rfc/rfc3575.txt>. July 2003, <http://www.ietf.org/rfc/rfc3575.txt>.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
January 2004, <http://www.ietf.org/rfc/rfc3688.txt>. January 2004, <http://www.ietf.org/rfc/rfc3688.txt>.
[RFC4758] RSA, The Security Division of EMC, "Cryptographic Token [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Key Initialization Protocol (CT-KIP)", November 2006, Resource Identifier (URI): Generic Syntax", RFC 3986,
<http://www.ietf.org/rfc/rfc4758.txt>. STD 66, January 2005,
<http://www.ietf.org/rfc/rfc3986.txt>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC4758] RSA, The Security Division of EMC, "Cryptographic Token
Housley, R., and W. Polk, "Internet X.509 Public Key Key Initialization Protocol (CT-KIP)", RFC 4758,
Infrastructure Certificate and Certificate Revocation List November 2006, <http://www.ietf.org/rfc/rfc4758.txt>.
(CRL) Profile", RFC 5280, May 2008,
<http://www.ietf.org/rfc/rfc5280.txt>.
[SKPC-ASN.1] [SKPC-ASN.1]
"Symmetric Key Package Content Type", 2007, <http:// "Symmetric Key Package Content Type", 2007, <http://
www.ietf.org/internet-drafts/ www.ietf.org/internet-drafts/
draft-ietf-keyprov-symmetrickeyformat-01.txt>. draft-ietf-keyprov-symmetrickeyformat-01.txt>.
[XMLNS] W3C, "Namespaces in XML", W3C Recommendation, [XMLNS] W3C, "Namespaces in XML", W3C Recommendation,
January 1999, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114 >. <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
Appendix A. Usage Scenarios Appendix A. Usage Scenarios
DSKPP is expected to be used to provision symmetric keys to DSKPP is expected to be used to provision symmetric keys to
cryptographic modules in a number of different scenarios, each with cryptographic modules in a number of different scenarios, each with
its own special requirements, as described below. This appendix its own special requirements, as described below. This appendix
forms an informative part of the document. forms an informative part of the document.
A.1. Single Key Request A.1. Single Key Request
skipping to change at page 73, line 4 skipping to change at page 79, line 4
</dskpp:AuthenticationCodeMac> </dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData> </dskpp:AuthenticationData>
<dskpp:ServerUrl>https://www.somekeyprovservice.com/ <dskpp:ServerUrl>https://www.somekeyprovservice.com/
</dskpp:ServerUrl> </dskpp:ServerUrl>
</dskpp:InitializationTrigger> </dskpp:InitializationTrigger>
</dskpp:KeyProvTrigger> </dskpp:KeyProvTrigger>
B.2. Four-Pass Protocol B.2. Four-Pass Protocol
B.2.1. <KeyProvClientHello> Without a Preceding Trigger B.2.1. <KeyProvClientHello> Without a Preceding Trigger
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello <dskpp:KeyProvClientHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0"> Version="1.0">
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo> <pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId> </dskpp:DeviceId>
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes> <dskpp:SupportedKeyTypes>
<dskpp:Algorithm> <dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc#hotp urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedKeyTypes> </dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms> </dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants> <dskpp:SupportedProtocolVariants>
<dskpp:FourPass/> <dskpp:FourPass/>
</dskpp:SupportedProtocolVariants> </dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages> <dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages> </dskpp:SupportedKeyPackages>
</dskpp:KeyProvClientHello> </dskpp:KeyProvClientHello>
B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello <dskpp:KeyProvClientHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0"> Version="1.0">
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo> <pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId> </dskpp:DeviceId>
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
<dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID> <dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID>
<dskpp:SupportedKeyTypes> <dskpp:SupportedKeyTypes>
<dskpp:Algorithm> <dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc#hotp urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedKeyTypes> </dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms> </dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants> <dskpp:SupportedProtocolVariants>
<dskpp:FourPass/> <dskpp:FourPass/>
</dskpp:SupportedProtocolVariants> </dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages> <dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages> </dskpp:SupportedKeyPackages>
</dskpp:KeyProvClientHello> </dskpp:KeyProvClientHello>
B.2.3. <KeyProvServerHello> Without a Preceding Trigger B.2.3. <KeyProvServerHello> Without a Preceding Trigger
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerHello <dskpp:KeyProvServerHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0" Version="1.0"
Status="Continue" Status="Continue"
SessionID="4114"> SessionID="4114">
<dskpp:KeyType> <dskpp:KeyType>
urn:ietf:params:xml:ns:keyprov:pskc#hotp urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:KeyType> </dskpp:KeyType>
<dskpp:EncryptionAlgorithm> <dskpp:EncryptionAlgorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:EncryptionAlgorithm> </dskpp:EncryptionAlgorithm>
<dskpp:MacAlgorithm> <dskpp:MacAlgorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:MacAlgorithm> </dskpp:MacAlgorithm>
<dskpp:EncryptionKey> <dskpp:EncryptionKey>
<ds:KeyName>Example-Key1</ds:KeyName> <ds:KeyName>Example-Key1</ds:KeyName>
</dskpp:EncryptionKey> </dskpp:EncryptionKey>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
<dskpp:Payload> <dskpp:Payload>
<dskpp:Nonce>EjRWeJASNFZ4kBI0VniQEg==</dskpp:Nonce> <dskpp:Nonce>EjRWeJASNFZ4kBI0VniQEg==</dskpp:Nonce>
</dskpp:Payload> </dskpp:Payload>
</dskpp:KeyProvServerHello> </dskpp:KeyProvServerHello>
B.2.4. <KeyProvServerHello> Assuming Key Renewal B.2.4. <KeyProvServerHello> Assuming Key Renewal
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerHello <dskpp:KeyProvServerHello
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0" Version="1.0"
SessionID="4114" SessionID="4114"
Status="Continue"> Status="Continue">
<dskpp:KeyType> <dskpp:KeyType>
urn:ietf:params:xml:schema:keyprov:otpalg#SecurID-AES urn:ietf:params:xml:schema:keyprov:otpalg#SecurID-AES
</dskpp:KeyType> </dskpp:KeyType>
<dskpp:EncryptionAlgorithm> <dskpp:EncryptionAlgorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:EncryptionAlgorithm> </dskpp:EncryptionAlgorithm>
<dskpp:MacAlgorithm> <dskpp:MacAlgorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:MacAlgorithm> </dskpp:MacAlgorithm>
<dskpp:EncryptionKey> <dskpp:EncryptionKey>
<ds:KeyName>Example-Key1</ds:KeyName> <ds:KeyName>Example-Key1</ds:KeyName>
</dskpp:EncryptionKey> </dskpp:EncryptionKey>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
<dskpp:Payload> <dskpp:Payload>
<dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce> <dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce>
</dskpp:Payload> </dskpp:Payload>
<dskpp:Mac <dskpp:Mac
MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128"> MacAlgorithm="urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128">
cXcycmFuZG9tMzEyYXNkZXIzOTRqdw== cXcycmFuZG9tMzEyYXNkZXIzOTRqdw==
</dskpp:Mac> </dskpp:Mac>
</dskpp:KeyProvServerHello> </dskpp:KeyProvServerHello>
B.2.5. <KeyProvClientNonce> Using Default Encryption B.2.5. <KeyProvClientNonce> Using Default Encryption
This message contains the nonce chosen by the cryptographic module, This message contains the nonce chosen by the cryptographic module,
R_C, encrypted by the specified encryption key and encryption R_C, encrypted by the specified encryption key and encryption
algorithm. algorithm.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientNonce <dskpp:KeyProvClientNonce
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
SessionID="4114" SessionID="4114"
Version="1.0"> Version="1.0">
<dskpp:EncryptedNonce> <dskpp:EncryptedNonce>
oTvo+S22nsmS2Z/RtcoF8CTwadRa1PVsRXkZnCihHkU1rPueggrd0NpEWVZR16Rg16+ oTvo+S22nsmS2Z/RtcoF8CTwadRa1PVsRXkZnCihHkU1rPueggrd0NpEWVZR
FHuTg33GK1wH3wffDZQ== 16Rg16+FHuTg33GK1wH3wffDZQ==
</dskpp:EncryptedNonce> </dskpp:EncryptedNonce>
</dskpp:KeyProvClientNonce> </dskpp:KeyProvClientNonce>
B.2.6. <KeyProvServerFinished> Using Default Encryption B.2.6. <KeyProvServerFinished> Using Default Encryption
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerFinished <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" <dskpp:KeyProvServerFinished
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Version="1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Status="Success" Version="1.0"
SessionID="4114"> Status="Success"
<dskpp:KeyPackage> SessionID="4114">
<dskpp:KeyContainer Version="1.0" Id="KC0001"> <dskpp:KeyPackage>
<pskc:KeyPackage> <dskpp:KeyContainer Version="1.0" Id="KC0001">
<pskc:DeviceInfo> <pskc:KeyPackage>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:DeviceInfo>
<pskc:SerialNo>987654321</pskc:SerialNo> <pskc:Manufacturer>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> TokenVendorAcme
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> </pskc:Manufacturer>
</pskc:DeviceInfo> <pskc:SerialNo>
<pskc:CryptoModuleInfo> 987654321
<pskc:Id>CM_ID_001</pskc:Id> </pskc:SerialNo>
</pskc:CryptoModuleInfo> <pskc:StartDate>
<pskc:Key 2009-09-01T00:00:00Z
Id="MBK000000001" </pskc:StartDate>
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"> <pskc:ExpiryDate>
<pskc:Issuer>Example-Issuer</pskc:Issuer> 2014-09-01T00:00:00Z
<pskc:AlgorithmParameters> </pskc:ExpiryDate>
<pskc:ResponseFormat Length="6" Encoding="DECIMAL"/> </pskc:DeviceInfo>
</pskc:AlgorithmParameters> <pskc:CryptoModuleInfo>
<pskc:Data> <pskc:Id>CM_ID_001</pskc:Id>
<pskc:Counter> </pskc:CryptoModuleInfo>
<pskc:PlainValue>0</pskc:PlainValue> <pskc:Key
</pskc:Counter> Id="MBK000000001"
</pskc:Data> Algorithm=
<pskc:Policy> "urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:KeyUsage>OTP</pskc:KeyUsage> <pskc:Issuer>Example-Issuer</pskc:Issuer>
</pskc:Policy> <pskc:AlgorithmParameters>
</pskc:Key> <pskc:ResponseFormat Length="6"
</pskc:KeyPackage> Encoding="DECIMAL"/>
</dskpp:KeyContainer> </pskc:AlgorithmParameters>
</dskpp:KeyPackage> <pskc:Data>
<dskpp:Mac <pskc:Counter>
MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256"> <pskc:PlainValue>0</pskc:PlainValue>
151yAR2NqU5dJzETK+SGYqN6sq6DEH5AgHohra3Jpp4= </pskc:Counter>
</dskpp:Mac> </pskc:Data>
</dskpp:KeyProvServerFinished> <pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy>
</pskc:Key>
</pskc:KeyPackage>
</dskpp:KeyContainer>
</dskpp:KeyPackage>
<dskpp:Mac
MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
151yAR2NqU5dJzETK+SGYqN6sq6DEH5AgHohra3Jpp4=
</dskpp:Mac>
</dskpp:KeyProvServerFinished>
B.3. Two-Pass Protocol B.3. Two-Pass Protocol
B.3.1. Example Using the Key Transport Method B.3.1. Example Using the Key Transport Method
The client indicates support for all the Key Transport, Key Wrap, and The client indicates support for all the Key Transport, Key Wrap, and
Passphrase-Based Key Wrap key protection methods: Passphrase-Based Key Wrap key protection methods:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello <dskpp:KeyProvClientHello
skipping to change at page 79, line 29 skipping to change at page 85, line 5
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo> <pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId> </dskpp:DeviceId>
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes> <dskpp:SupportedKeyTypes>
<dskpp:Algorithm> <dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc#hotp urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedKeyTypes> </dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#rsa_1_5 http://www.w3.org/2001/04/xmlenc#rsa_1_5
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms> </dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants> <dskpp:SupportedProtocolVariants>
<dskpp:TwoPass> <dskpp:TwoPass>
<dskpp:SupportedKeyProtectionMethod> <dskpp:SupportedKeyProtectionMethod>
urn:ietf:params:xml:schema:keyprov:dskpp#transport urn:ietf:params:xml:schema:keyprov:dskpp:transport
</dskpp:SupportedKeyProtectionMethod> </dskpp:SupportedKeyProtectionMethod>
<dskpp:Payload> <dskpp:Payload>
<ds:KeyInfo> <ds:KeyInfo>
<ds:X509Data> <ds:X509Data>
<ds:X509Certificate> <ds:X509Certificate>
MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGMRMwEQY MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGM
DVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MDkxMzMyWhcNMT RMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MD
EwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDV kxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXl
QQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1 Qcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypf AoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA
zTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WI 3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCx
h1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBL vdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYE
otUKuqfrnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/ Ae875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqfrnRuXJRMeZXaaEGmzY1k
w4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo= LonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w4rnqdkmwZX/NgXg06aln
c2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
</ds:X509Certificate> </ds:X509Certificate>
</ds:X509Data> </ds:X509Data>
</ds:KeyInfo> </ds:KeyInfo>
</dskpp:Payload> </dskpp:Payload>
</dskpp:TwoPass> </dskpp:TwoPass>
</dskpp:SupportedProtocolVariants> </dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages> <dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages> </dskpp:SupportedKeyPackages>
<dskpp:AuthenticationData> <dskpp:AuthenticationData>
<dskpp:ClientID>AC00000A</dskpp:ClientID> <dskpp:ClientID>AC00000A</dskpp:ClientID>
<dskpp:AuthenticationCodeMac> <dskpp:AuthenticationCodeMac>
<dskpp:Nonce> <dskpp:Nonce>
ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI= ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
</dskpp:Nonce> </dskpp:Nonce>
<dskpp:IterationCount>100000</dskpp:IterationCount> <dskpp:IterationCount>100000</dskpp:IterationCount>
<dskpp:Mac <dskpp:Mac
MacAlgorithm= MacAlgorithm=
"http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256"> "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
3eRz51ILqiG+dJW2iLcjuA== 3eRz51ILqiG+dJW2iLcjuA==
</dskpp:Mac> </dskpp:Mac>
</dskpp:AuthenticationCodeMac> </dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData> </dskpp:AuthenticationData>
</dskpp:KeyProvClientHello> </dskpp:KeyProvClientHello>
In this example, the server responds to the previous request by In this example, the server responds to the previous request by
returning a key package in which the provisioning key was encrypted returning a key package in which the provisioning key was encrypted
using the Key Transport key protection method. using the Key Transport key protection method.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerFinished <dskpp:KeyProvServerFinished
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#" xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
xmlns:pkcs5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
Version="1.0" Version="1.0"
Status="Success" Status="Success"
SessionID="4114"> SessionID="4114">
<dskpp:KeyPackage> <dskpp:KeyPackage>
<dskpp:KeyContainer Version="1.0" Id="KC0001"> <dskpp:KeyContainer Version="1.0" Id="KC0001">
<pskc:EncryptionKey> <pskc:EncryptionKey>
<ds:X509Data> <ds:X509Data>
<ds:X509Certificate> <ds:X509Certificate>
MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGMRMwEQY MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGM
DVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MDkxMzMyWhcNMT RMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MD
EwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDV kxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXl
QQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1 Qcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypf AoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA
zTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WI 3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCx
h1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBL vdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYE
otUKuqfrnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/ Ae875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqfrnRuXJRMeZXaaEGmzY1k
w4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo= LonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w4rnqdkmwZX/NgXg06aln
c2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
</ds:X509Certificate> </ds:X509Certificate>
</ds:X509Data> </ds:X509Data>
</pskc:EncryptionKey> </pskc:EncryptionKey>
<pskc:KeyPackage> <pskc:KeyPackage>
<pskc:DeviceInfo> <pskc:DeviceInfo>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo> TokenVendorAcme
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> </pskc:Manufacturer>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> <pskc:SerialNo>
987654321
</pskc:SerialNo>
<pskc:StartDate>
2009-09-01T00:00:00Z
</pskc:StartDate>
<pskc:ExpiryDate>
2014-09-01T00:00:00Z
</pskc:ExpiryDate>
</pskc:DeviceInfo> </pskc:DeviceInfo>
<pskc:Key <pskc:Key
Id="MBK000000001" Id="MBK000000001"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"> Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:Issuer>Example-Issuer</pskc:Issuer> <pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters> <pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="6" Encoding="DECIMAL"/> <pskc:ResponseFormat Length="6"
Encoding="DECIMAL"/>
</pskc:AlgorithmParameters> </pskc:AlgorithmParameters>
<pskc:Data> <pskc:Data>
<pskc:Secret> <pskc:Secret>
<pskc:EncryptedValue> <pskc:EncryptedValue>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm= Algorithm=
"http://www.w3.org/2001/04/xmlenc#rsa_1_5"/> "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>
eyjr23WMy9S2UdKgGnQEbs44T1jmX1TNWEBq48xfS20PK2VWF4ZK1iSctHj/u3uk+7+y8uKrAzH eyjr23WMy9S2UdKgGnQEbs44T1jmX1TNWEBq48xfS20PK2VWF4ZK1iSctHj/u3uk+7+y8
Em5mujKPAU4DCbb5mSibXMnAbbIoAi2cJW60/l8FlzwaU4EZsZ1LyQ1GcBQKACEeylG5vK8NTo4 uKrAzHEm5mujKPAU4DCbb5mSibXMnAbbIoAi2cJW60/l8FlzwaU4EZsZ1LyQ1GcBQKACE
7vZTatL5UxmbmOX2HvaVQ= eylG5vK8NTo47vZTatL5UxmbmOX2HvaVQ=
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</pskc:EncryptedValue> </pskc:EncryptedValue>
</pskc:Secret> </pskc:Secret>
<pskc:Counter> <pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue> <pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter> </pskc:Counter>
</pskc:Data> </pskc:Data>
<pskc:Policy> <pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage> <pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy> </pskc:Policy>
</pskc:Key> </pskc:Key>
skipping to change at page 82, line 15 skipping to change at page 88, line 4
</pskc:EncryptedValue> </pskc:EncryptedValue>
</pskc:Secret> </pskc:Secret>
<pskc:Counter> <pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue> <pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter> </pskc:Counter>
</pskc:Data> </pskc:Data>
<pskc:Policy> <pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage> <pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy> </pskc:Policy>
</pskc:Key> </pskc:Key>
</pskc:KeyPackage> </pskc:KeyPackage>
</dskpp:KeyContainer> </dskpp:KeyContainer>
</dskpp:KeyPackage> </dskpp:KeyPackage>
<dskpp:Mac <dskpp:Mac
MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256"> MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
GHZ0H6Y+KpxdlVZ7zgcJDiDdqc8Gcmlcf+HQi4EUxYU= GHZ0H6Y+KpxdlVZ7zgcJDiDdqc8Gcmlcf+HQi4EUxYU=
</dskpp:Mac> </dskpp:Mac>
</dskpp:KeyProvServerFinished> </dskpp:KeyProvServerFinished>
B.3.2. Example Using the Key Wrap Method B.3.2. Example Using the Key Wrap Method
The client sends a request that specifies a shared key to protect the The client sends a request that specifies a shared key to protect the
K_TOKEN, and the server responds using the Key Wrap key protection K_TOKEN, and the server responds using the Key Wrap key protection
method. Authentication data in this example is based on an method. Authentication data in this example is based on an
authentication code rather than a device certificate. authentication code rather than a device certificate.
skipping to change at page 82, line 48 skipping to change at page 88, line 39
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo> <pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId> </dskpp:DeviceId>
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes> <dskpp:SupportedKeyTypes>
<dskpp:Algorithm> <dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc#hotp urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedKeyTypes> </dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms> </dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants> <dskpp:SupportedProtocolVariants>
<dskpp:TwoPass> <dskpp:TwoPass>
<dskpp:SupportedKeyProtectionMethod> <dskpp:SupportedKeyProtectionMethod>
urn:ietf:params:xml:schema:keyprov:dskpp#wrap urn:ietf:params:xml:schema:keyprov:dskpp:wrap
</dskpp:SupportedKeyProtectionMethod> </dskpp:SupportedKeyProtectionMethod>
<dskpp:Payload> <dskpp:Payload>
<ds:KeyInfo> <ds:KeyInfo>
<ds:KeyName>Pre-shared-key-1</ds:KeyName> <ds:KeyName>Pre-shared-key-1</ds:KeyName>
</ds:KeyInfo> </ds:KeyInfo>
</dskpp:Payload> </dskpp:Payload>
</dskpp:TwoPass> </dskpp:TwoPass>
</dskpp:SupportedProtocolVariants> </dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages> <dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages> </dskpp:SupportedKeyPackages>
<dskpp:AuthenticationData> <dskpp:AuthenticationData>
<dskpp:ClientID>AC00000A</dskpp:ClientID> <dskpp:ClientID>AC00000A</dskpp:ClientID>
<dskpp:AuthenticationCodeMac> <dskpp:AuthenticationCodeMac>
<dskpp:Nonce> <dskpp:Nonce>
ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI= ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
</dskpp:Nonce> </dskpp:Nonce>
<dskpp:IterationCount>1</dskpp:IterationCount> <dskpp:IterationCount>1</dskpp:IterationCount>
<dskpp:Mac <dskpp:Mac
MacAlgorithm= MacAlgorithm=
"http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256"> "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
3eRz51ILqiG+dJW2iLcjuA== 3eRz51ILqiG+dJW2iLcjuA==
</dskpp:Mac> </dskpp:Mac>
</dskpp:AuthenticationCodeMac> </dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData> </dskpp:AuthenticationData>
</dskpp:KeyProvClientHello> </dskpp:KeyProvClientHello>
In this example, the server responds to the previous request by In this example, the server responds to the previous request by
returning a key package in which the provisioning key was encrypted returning a key package in which the provisioning key was encrypted
using the Key Wrap key protection method. using the Key Wrap key protection method.
skipping to change at page 84, line 14 skipping to change at page 90, line 4
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerFinished <dskpp:KeyProvServerFinished
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#" xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
xmlns:pkcs5= xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
Version="1.0" Version="1.0"
Status="Success" Status="Success"
SessionID="4114"> SessionID="4114">
<dskpp:KeyPackage> <dskpp:KeyPackage>
<dskpp:KeyContainer Version="1.0" Id="KC0001"> <dskpp:KeyContainer Version="1.0" Id="KC0001">
<pskc:EncryptionKey> <pskc:EncryptionKey>
<ds:KeyName>Pre-shared-key-1</ds:KeyName> <ds:KeyName>Pre-shared-key-1</ds:KeyName>
</pskc:EncryptionKey> </pskc:EncryptionKey>
<pskc:MACMethod <pskc:MACMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"> Algorithm=
"http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<pskc:MACKey> <pskc:MACKey>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm= Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoMUBJBuAf25hARFv0Z7MFk9Ecdb04PWY/qaeCbrgz7Es 2GTTnLwM3I4e5IO5FkufoMUBJBuAf25hARFv0Z7MFk9Ecdb04PWY/qaeCbrgz7Es
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</pskc:MACKey> </pskc:MACKey>
</pskc:MACMethod> </pskc:MACMethod>
<pskc:KeyPackage> <pskc:KeyPackage>
<pskc:DeviceInfo> <pskc:DeviceInfo>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo> TokenVendorAcme
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> </pskc:Manufacturer>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> <pskc:SerialNo>
987654321
</pskc:SerialNo>
<pskc:StartDate>
2009-09-01T00:00:00Z
</pskc:StartDate>
<pskc:ExpiryDate>
2014-09-01T00:00:00Z
</pskc:ExpiryDate>
</pskc:DeviceInfo> </pskc:DeviceInfo>
<pskc:CryptoModuleInfo> <pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id> <pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo> </pskc:CryptoModuleInfo>
<pskc:Key <pskc:Key
Id="MBK000000001" Id="MBK000000001"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"> Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:Issuer>Example-Issuer</pskc:Issuer> <pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters> <pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="6" Encoding="DECIMAL"/> <pskc:ResponseFormat Length="6"
Encoding="DECIMAL"/>
</pskc:AlgorithmParameters> </pskc:AlgorithmParameters>
<pskc:Data> <pskc:Data>
<pskc:Secret> <pskc:Secret>
<pskc:EncryptedValue> <pskc:EncryptedValue>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm= Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8AabC6vr09sh0Q oTvo+S22nsmS2Z/RtcoF8AabC6vr
IU+E224S96sZjpV+6nFYgn6525OoepbPnL 09sh0QIU+E224S96sZjpV+6nFYgn
/fGuuey64WCYXoqhTg== 6525OoepbPnL/fGuuey64WCYXoqh
Tg==
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</pskc:EncryptedValue> </pskc:EncryptedValue>
<pskc:ValueMAC> <pskc:ValueMAC>
o+e9xgMVUbYuZH9UHe0W9dIo88A= o+e9xgMVUbYuZH9UHe0W9dIo88A=
</pskc:ValueMAC> </pskc:ValueMAC>
</pskc:Secret> </pskc:Secret>
<pskc:Counter> <pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue> <pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter> </pskc:Counter>
</pskc:Data> </pskc:Data>
<pskc:Policy> <pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage> <pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy> </pskc:Policy>
</pskc:Key> </pskc:Key>
</pskc:KeyPackage> </pskc:KeyPackage>
</dskpp:KeyContainer> </dskpp:KeyContainer>
</dskpp:KeyPackage> </dskpp:KeyPackage>
<dskpp:Mac <dskpp:Mac
MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256"> MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
l53BmSO6qUzoIgbQegimsKk2es+WRpEl0YFqaOp5PGE= l53BmSO6qUzoIgbQegimsKk2es+WRpEl0YFqaOp5PGE=
</dskpp:Mac> </dskpp:Mac>
</dskpp:KeyProvServerFinished> </dskpp:KeyProvServerFinished>
B.3.3. Example Using the Passphrase-Based Key Wrap Method B.3.3. Example Using the Passphrase-Based Key Wrap Method
The client sends a request similar to that in Appendix B.3.1 with The client sends a request similar to that in Appendix B.3.1 with
authentication data based on an authentication code, and the server authentication data based on an authentication code, and the server
responds using the Passphrase-Based Key Wrap method to encrypt the responds using the Passphrase-Based Key Wrap method to encrypt the
provisioning key (note that the encryption is derived from the provisioning key (note that the encryption is derived from the
skipping to change at page 86, line 17 skipping to change at page 92, line 22
<dskpp:DeviceIdentifierData> <dskpp:DeviceIdentifierData>
<dskpp:DeviceId> <dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo> <pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> <pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> <pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId> </dskpp:DeviceId>
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes> <dskpp:SupportedKeyTypes>
<dskpp:Algorithm> <dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc#hotp urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedKeyTypes> </dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#rsa_1_5 http://www.w3.org/2001/04/xmlenc#rsa_1_5
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms> </dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants> <dskpp:SupportedProtocolVariants>
<dskpp:TwoPass> <dskpp:TwoPass>
<dskpp:SupportedKeyProtectionMethod> <dskpp:SupportedKeyProtectionMethod>
urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap
</dskpp:SupportedKeyProtectionMethod> </dskpp:SupportedKeyProtectionMethod>
<dskpp:Payload> <dskpp:Payload>
<ds:KeyInfo> <ds:KeyInfo>
<ds:KeyName>Passphrase-1</ds:KeyName> <ds:KeyName>Passphrase-1</ds:KeyName>
</ds:KeyInfo> </ds:KeyInfo>
</dskpp:Payload> </dskpp:Payload>
</dskpp:TwoPass> </dskpp:TwoPass>
</dskpp:SupportedProtocolVariants> </dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages> <dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages> </dskpp:SupportedKeyPackages>
<dskpp:AuthenticationData> <dskpp:AuthenticationData>
<dskpp:ClientID>AC00000A</dskpp:ClientID> <dskpp:ClientID>AC00000A</dskpp:ClientID>
<dskpp:AuthenticationCodeMac> <dskpp:AuthenticationCodeMac>
<dskpp:Nonce> <dskpp:Nonce>
ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI= ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
</dskpp:Nonce> </dskpp:Nonce>
<dskpp:IterationCount>1</dskpp:IterationCount> <dskpp:IterationCount>1</dskpp:IterationCount>
<dskpp:Mac <dskpp:Mac
MacAlgorithm= MacAlgorithm=
"http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256"> "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
K4YvLMN6Q1DZvtShoCxQag== K4YvLMN6Q1DZvtShoCxQag==
</dskpp:Mac> </dskpp:Mac>
</dskpp:AuthenticationCodeMac> </dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData> </dskpp:AuthenticationData>
</dskpp:KeyProvClientHello> </dskpp:KeyProvClientHello>
In this example, the server responds to the previous request by In this example, the server responds to the previous request by
returning a key package in which the provisioning key was encrypted returning a key package in which the provisioning key was encrypted
using the Passphrase-Based Key Wrap key protection method. using the Passphrase-Based Key Wrap key protection method.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerFinished <dskpp:KeyProvServerFinished
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#" xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
xmlns:pkcs5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
Version="1.0" Version="1.0"
Status="Success" Status="Success"
SessionID="4114"> SessionID="4114">
<dskpp:KeyPackage> <dskpp:KeyPackage>
<dskpp:KeyContainer Version="1.0" Id="KC0002"> <dskpp:KeyContainer Version="1.0" Id="KC0002">
<pskc:EncryptionKey> <pskc:EncryptionKey>
<dkey:DerivedKey> <dkey:DerivedKey>
<dkey:KeyDerivationMethod <dkey:KeyDerivationMethod
Algorithm= Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/ "http://www.rsasecurity.com/rsalabs/pkcs/schemas/
skipping to change at page 87, line 47 skipping to change at page 94, line 4
<dkey:KeyDerivationMethod <dkey:KeyDerivationMethod
Algorithm= Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/ "http://www.rsasecurity.com/rsalabs/pkcs/schemas/
pkcs-5v2-0#pbkdf2"> pkcs-5v2-0#pbkdf2">
<pkcs5:PBKDF2-params> <pkcs5:PBKDF2-params>
<Salt> <Salt>
<Specified>Ej7/PEpyEpw=</Specified> <Specified>Ej7/PEpyEpw=</Specified>
</Salt> </Salt>
<IterationCount>1000</IterationCount> <IterationCount>1000</IterationCount>
<KeyLength>16</KeyLength> <KeyLength>16</KeyLength>
</pkcs5:PBKDF2-params> </pkcs5:PBKDF2-params>
</dkey:KeyDerivationMethod> </dkey:KeyDerivationMethod>
<xenc:ReferenceList> <xenc:ReferenceList>
<xenc:DataReference URI="#ED"/> <xenc:DataReference URI="#ED"/>
</xenc:ReferenceList> </xenc:ReferenceList>
<dkey:MasterKeyName>Passphrase1</dkey:MasterKeyName> <dkey:MasterKeyName>
Passphrase1
</dkey:MasterKeyName>
</dkey:DerivedKey> </dkey:DerivedKey>
</pskc:EncryptionKey> </pskc:EncryptionKey>
<pskc:MACMethod <pskc:MACMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"> Algorithm=
"http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<pskc:MACKey> <pskc:MACKey>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm= Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx 2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</pskc:MACKey> </pskc:MACKey>
</pskc:MACMethod> </pskc:MACMethod>
<pskc:KeyPackage> <pskc:KeyPackage>
<pskc:DeviceInfo> <pskc:DeviceInfo>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo> TokenVendorAcme
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate> </pskc:Manufacturer>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate> <pskc:SerialNo>
987654321
</pskc:SerialNo>
<pskc:StartDate>
2009-09-01T00:00:00Z
</pskc:StartDate>
<pskc:ExpiryDate>
2014-09-01T00:00:00Z
</pskc:ExpiryDate>
</pskc:DeviceInfo> </pskc:DeviceInfo>
<pskc:CryptoModuleInfo> <pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id> <pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo> </pskc:CryptoModuleInfo>
<pskc:Key <pskc:Key
Id="MBK000000001" Id="MBK000000001"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"> Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:Issuer>Example-Issuer</pskc:Issuer> <pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters> <pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="6" Encoding="DECIMAL"/> <pskc:ResponseFormat Length="6"
Encoding="DECIMAL"/>
</pskc:AlgorithmParameters> </pskc:AlgorithmParameters>
<pskc:Data> <pskc:Data>
<pskc:Secret> <pskc:Secret>
<pskc:EncryptedValue> <pskc:EncryptedValue>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm= Algorithm=
"http://www.w3.org/2001/04/ "http://www.w3.org/2001/04/
xmlenc#aes128-cbc"/> xmlenc#aes128-cbc"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8HX385uMWgJmyIFME oTvo+S22nsmS2Z/RtcoF8HX385uMWgJ
SBmcvtHQXp/6T1TgCS9CsgKtmcOrF8VoK254t myIFMESBmcvtHQXp/6T1TgCS9CsgKtm
ZKnrAjiD5cdw== cOrF8VoK254tZKnrAjiD5cdw==
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</pskc:EncryptedValue> </pskc:EncryptedValue>
<pskc:ValueMAC> <pskc:ValueMAC>
pbgEbVYxoYs0x41wdeC7eDRbUEk= pbgEbVYxoYs0x41wdeC7eDRbUEk=
</pskc:ValueMAC> </pskc:ValueMAC>
</pskc:Secret> </pskc:Secret>
<pskc:Counter> <pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue> <pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter> </pskc:Counter>
</pskc:Data> </pskc:Data>
<pskc:Policy> <pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage> <pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy> </pskc:Policy>
</pskc:Key> </pskc:Key>
</pskc:KeyPackage> </pskc:KeyPackage>
</dskpp:KeyContainer> </dskpp:KeyContainer>
</dskpp:KeyPackage> </dskpp:KeyPackage>
<dskpp:Mac MacAlgorithm= <dskpp:Mac MacAlgorithm=
"http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256"> "urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
Jc4VsNODYXgfbDmTn9qQZgcL3cKoa//j/NRT7sTpKOM= Jc4VsNODYXgfbDmTn9qQZgcL3cKoa//j/NRT7sTpKOM=
</dskpp:Mac> </dskpp:Mac>
</dskpp:KeyProvServerFinished> </dskpp:KeyProvServerFinished>
Appendix C. Integration with PKCS #11 Appendix C. Integration with PKCS #11
A DSKPP client that needs to communicate with a connected A DSKPP client that needs to communicate with a connected
cryptographic module to perform a DSKPP exchange MAY use PKCS #11 cryptographic module to perform a DSKPP exchange MAY use PKCS #11
[PKCS-11] as a programming interface as described herein. This [PKCS-11] as a programming interface as described herein. This
appendix forms an informative part of the document. appendix forms an informative part of the document.
skipping to change at page 92, line 22 skipping to change at page 98, line 36
the previous protocol run). Again, if the MAC does not the previous protocol run). Again, if the MAC does not
verify the protocol session ends with a failure, and the verify the protocol session ends with a failure, and the
token MUST be constructed no to "commit" to the new K_TOKEN token MUST be constructed no to "commit" to the new K_TOKEN
or the new K_MAC unless the MAC verifies. or the new K_MAC unless the MAC verifies.
Appendix D. Example of DSKPP-PRF Realizations Appendix D. Example of DSKPP-PRF Realizations
D.1. Introduction D.1. Introduction
This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES] This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
and HMAC [RFC2104]. This appendix forms an informative part of the and HMAC [RFC2104]. This appendix forms a normative part of the
document. document.
D.2. DSKPP-PRF-AES D.2. DSKPP-PRF-AES
D.2.1. Identification D.2.1. Identification
For cryptographic modules supporting this realization of DSKPP-PRF, For cryptographic modules supporting this realization of DSKPP-PRF,
the following URL MAY be used to identify this algorithm in DSKPP: the following URN MUST be used to identify this algorithm in DSKPP:
http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128 urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
When this URL is used to identify the encryption algorithm, the When this URN is used to identify the encryption algorithm, the
method for encryption of R_C values described in Section 4.2.4 MUST method for encryption of R_C values described in Section 4.2.4 MUST
be used. be used.
D.2.2. Definition D.2.2. Definition
DSKPP-PRF-AES (k, s, dsLen) DSKPP-PRF-AES (k, s, dsLen)
Input: Input:
k Encryption key to use k Encryption key to use
skipping to change at page 94, line 20 skipping to change at page 100, line 27
j = 16 - (1 - 1) * 16 = 16 j = 16 - (1 - 1) * 16 = 16
DS = B1 = F (k, s, 1) = CMAC-AES (k, INT (1) || s) DS = B1 = F (k, s, 1) = CMAC-AES (k, INT (1) || s)
D.3. DSKPP-PRF-SHA256 D.3. DSKPP-PRF-SHA256
D.3.1. Identification D.3.1. Identification
For cryptographic modules supporting this realization of DSKPP-PRF, For cryptographic modules supporting this realization of DSKPP-PRF,
the following URL MAY be used to identify this algorithm in DSKPP: the following URN MUST be used to identify this algorithm in DSKPP:
http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
When this URL is used to identify the encryption algorithm to use, When this URN is used to identify the encryption algorithm to use,
the method for encryption of R_C values described in Section 4.2.4 the method for encryption of R_C values described in Section 4.2.4
MUST be used. MUST be used.
D.3.2. Definition D.3.2. Definition
DSKPP-PRF-SHA256 (k, s, dsLen) DSKPP-PRF-SHA256 (k, s, dsLen)
Input: Input:
k Encryption key to use k Encryption key to use
skipping to change at page 96, line 16 skipping to change at page 102, line 21
Andrea Doherty Andrea Doherty
RSA, The Security Division of EMC RSA, The Security Division of EMC
174 Middlesex Turnpike 174 Middlesex Turnpike
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: andrea.doherty@rsa.com Email: andrea.doherty@rsa.com
Mingliang Pei Mingliang Pei
Verisign, Inc. VeriSign, Inc.
487 E. Middlefield Road 487 E. Middlefield Road
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: mpei@verisign.com Email: mpei@verisign.com
Salah Machani Salah Machani
Diversinet Corp. Diversinet Corp.
2225 Sheppard Avenue East, Suite 1801 2225 Sheppard Avenue East, Suite 1801
Toronto, Ontario M2J 5C2 Toronto, Ontario M2J 5C2
 End of changes. 189 change blocks. 
965 lines changed or deleted 1318 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/