draft-ietf-keyprov-dskpp-05.txt   draft-ietf-keyprov-dskpp-06.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: January 13, 2009 Verisign, Inc. Expires: May 7, 2009 Verisign, Inc.
S. Machani S. Machani
Diversinet Corp. Diversinet Corp.
M. Nystrom M. Nystrom
RSA, The Security Division of EMC RSA, The Security Division of EMC
July 12, 2008 November 3, 2008
Dynamic Symmetric Key Provisioning Protocol (DSKPP) Dynamic Symmetric Key Provisioning Protocol (DSKPP)
draft-ietf-keyprov-dskpp-05.txt draft-ietf-keyprov-dskpp-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2009. This Internet-Draft will expire on May 7, 2009.
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 This document builds on information contained in [RFC4758], adding
specific enhancements in response to implementation experience and specific enhancements in response to implementation experience and
liaison requests. It is intended that this document or a successor liaison requests.
version thereto will become the basis for subsequent progression of a
symmetric key provisioning protocol specification on the standards
track.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
1.1.1. Single Key Request . . . . . . . . . . . . . . . . . 7 1.1.1. Single Key Request . . . . . . . . . . . . . . . . . 7
1.1.2. Multiple Key Requests . . . . . . . . . . . . . . . . 7 1.1.2. Multiple Key Requests . . . . . . . . . . . . . . . . 7
1.1.3. User Authentication . . . . . . . . . . . . . . . . . 7 1.1.3. User Authentication . . . . . . . . . . . . . . . . . 7
1.1.4. Provisioning Time-Out Policy . . . . . . . . . . . . 7 1.1.4. Provisioning Time-Out Policy . . . . . . . . . . . . 7
1.1.5. Key Renewal . . . . . . . . . . . . . . . . . . . . . 8 1.1.5. Key Renewal . . . . . . . . . . . . . . . . . . . . . 7
1.1.6. Pre-Loaded Key Replacement . . . . . . . . . . . . . 8 1.1.6. Pre-Loaded Key Replacement . . . . . . . . . . . . . 8
1.1.7. Pre-Shared Manufacturing Key . . . . . . . . . . . . 8 1.1.7. Pre-Shared Manufacturing Key . . . . . . . . . . . . 8
1.1.8. End-to-End Protection of Key Material . . . . . . . . 9 1.1.8. End-to-End Protection of Key Material . . . . . . . . 8
1.2. Protocol Entities . . . . . . . . . . . . . . . . . . . . 9 1.2. Protocol Entities . . . . . . . . . . . . . . . . . . . . 9
1.3. Initiating DSKPP . . . . . . . . . . . . . . . . . . . . 10 1.3. Initiating DSKPP . . . . . . . . . . . . . . . . . . . . 10
1.4. Determining Which Protocol Variant to Use . . . . . . . . 11 1.4. Determining Which Protocol Variant to Use . . . . . . . . 11
1.4.1. Criteria for Using the Four-Pass Protocol . . . . . . 11 1.4.1. Criteria for Using the Four-Pass Protocol . . . . . . 11
1.4.2. Criteria for Using the Two-Pass Protocol . . . . . . 12 1.4.2. Criteria for Using the Two-Pass Protocol . . . . . . 12
1.5. Presentation Syntax . . . . . . . . . . . . . . . . . . . 12 1.5. Presentation Syntax . . . . . . . . . . . . . . . . . . . 12
1.5.1. Versions . . . . . . . . . . . . . . . . . . . . . . 12 1.5.1. Versions . . . . . . . . . . . . . . . . . . . . . . 12
1.5.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 12 1.5.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 12
1.5.3. Identifiers . . . . . . . . . . . . . . . . . . . . . 13 1.5.3. Identifiers . . . . . . . . . . . . . . . . . . . . . 13
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16 2.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16
3. DSKPP Protocol Details . . . . . . . . . . . . . . . . . . . 17 3. DSKPP Protocol Details . . . . . . . . . . . . . . . . . . . 17
3.1. Four-Pass Protocol Usage . . . . . . . . . . . . . . . . 19 3.1. Protocol Initiation . . . . . . . . . . . . . . . . . . . 17
3.1.1. Message Flow . . . . . . . . . . . . . . . . . . . . 19 3.1.1. Server Initiation . . . . . . . . . . . . . . . . . . 17
3.1.2. Generation of Symmetric Keys for Cryptographic 3.1.2. Client Initiation . . . . . . . . . . . . . . . . . . 18
Modules . . . . . . . . . . . . . . . . . . . . . . . 22 3.2. Protocol Variations . . . . . . . . . . . . . . . . . . . 18
3.1.3. Encryption of Pseudorandom Nonces Sent from the 3.2.1. Four-Pass Protocol Interaction . . . . . . . . . . . 18
DSKPP Client . . . . . . . . . . . . . . . . . . . . 25 3.2.2. Two-Pass Protocol Interaction . . . . . . . . . . . . 20
3.1.4. MAC Calculations . . . . . . . . . . . . . . . . . . 25 3.3. Cryptographic Construction . . . . . . . . . . . . . . . 21
3.2. Two-Pass Protocol Usage . . . . . . . . . . . . . . . . . 27 3.3.1. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF . 21
3.2.1. Message Flow . . . . . . . . . . . . . . . . . . . . 27 3.4. Four-Pass Protocol Usage . . . . . . . . . . . . . . . . 22
3.2.2. Key Protection Profiles . . . . . . . . . . . . . . . 30 3.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . 22
3.2.3. MAC Calculations . . . . . . . . . . . . . . . . . . 34 3.4.2. Generation of Symmetric Keys for Cryptographic
3.3. Device Identification . . . . . . . . . . . . . . . . . . 35 Modules . . . . . . . . . . . . . . . . . . . . . . . 25
3.4. User Authentication . . . . . . . . . . . . . . . . . . . 36 3.4.3. Encryption of Pseudorandom Nonces Sent from the
3.4.1. Authentication Data . . . . . . . . . . . . . . . . . 36 DSKPP Client . . . . . . . . . . . . . . . . . . . . 28
3.4.2. Authentication Code Format . . . . . . . . . . . . . 37 3.4.4. MAC Calculations . . . . . . . . . . . . . . . . . . 28
3.4.3. Authentication Data Calculation . . . . . . . . . . . 39 3.5. Two-Pass Protocol Usage . . . . . . . . . . . . . . . . . 30
3.5. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF . . . 40 3.5.1. Message Flow . . . . . . . . . . . . . . . . . . . . 30
3.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 40 3.5.2. Key Protection Profiles . . . . . . . . . . . . . . . 33
3.5.2. Declaration . . . . . . . . . . . . . . . . . . . . . 41 3.5.3. MAC Calculations . . . . . . . . . . . . . . . . . . 37
4. DSKPP Message Formats . . . . . . . . . . . . . . . . . . . . 41 3.6. Device Identification . . . . . . . . . . . . . . . . . . 38
4.1. General XML Schema Requirements . . . . . . . . . . . . . 41 3.7. User Authentication . . . . . . . . . . . . . . . . . . . 39
4.2. Components of the <KeyProvTrigger> Message . . . . . . . 42 3.7.1. Authentication Data . . . . . . . . . . . . . . . . . 39
4.3. Components of the <KeyProvClientHello> Request . . . . . 43 3.7.2. Authentication Code Format . . . . . . . . . . . . . 40
4.3.1. The DeviceIdentifierDataType Type . . . . . . . . . . 46 3.7.3. Authentication Data Calculation . . . . . . . . . . . 42
4.3.2. The ProtocolVariantsType Type . . . . . . . . . . . . 46 4. DSKPP Message Formats . . . . . . . . . . . . . . . . . . . . 43
4.3.3. The KeyPackagesFormatType Type . . . . . . . . . . . 47 4.1. General XML Schema Requirements . . . . . . . . . . . . . 43
4.3.4. The AuthenticationDataType Type . . . . . . . . . . . 48 4.2. Components of the <KeyProvTrigger> Message . . . . . . . 44
4.3. Components of the <KeyProvClientHello> Request . . . . . 45
4.3.1. The DeviceIdentifierDataType Type . . . . . . . . . . 48
4.3.2. The ProtocolVariantsType Type . . . . . . . . . . . . 48
4.3.3. The KeyPackagesFormatType Type . . . . . . . . . . . 49
4.3.4. The AuthenticationDataType Type . . . . . . . . . . . 50
4.4. Components of the <KeyProvServerHello> Response (Used 4.4. Components of the <KeyProvServerHello> Response (Used
Only in Four-Pass DSKPP) . . . . . . . . . . . . . . . . 48
4.5. Components of a <KeyProvClientNonce> Request (Used
Only in Four-Pass DSKPP) . . . . . . . . . . . . . . . . 50 Only in Four-Pass DSKPP) . . . . . . . . . . . . . . . . 50
4.6. Components of a <KeyProvServerFinished> Response . . . . 51 4.5. Components of a <KeyProvClientNonce> Request (Used
4.7. The StatusCode Type . . . . . . . . . . . . . . . . . . . 53 Only in Four-Pass DSKPP) . . . . . . . . . . . . . . . . 52
5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 55 4.6. Components of a <KeyProvServerFinished> Response . . . . 53
5.1. The ClientInfoType Type . . . . . . . . . . . . . . . . . 55 4.7. The StatusCode Type . . . . . . . . . . . . . . . . . . . 55
5.2. The ServerInfoType Type . . . . . . . . . . . . . . . . . 55 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 57
6. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 55 5.1. The ClientInfoType Type . . . . . . . . . . . . . . . . . 57
6.1. General Requirements . . . . . . . . . . . . . . . . . . 55 5.2. The ServerInfoType Type . . . . . . . . . . . . . . . . . 57
6.2. HTTP/1.1 Binding for DSKPP . . . . . . . . . . . . . . . 55 6. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 57
6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 55 6.1. General Requirements . . . . . . . . . . . . . . . . . . 57
6.2.2. Identification of DSKPP Messages . . . . . . . . . . 56 6.2. HTTP/1.1 Binding for DSKPP . . . . . . . . . . . . . . . 57
6.2.3. HTTP Headers . . . . . . . . . . . . . . . . . . . . 56 6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 57
6.2.4. HTTP Operations . . . . . . . . . . . . . . . . . . . 56 6.2.2. Identification of DSKPP Messages . . . . . . . . . . 58
6.2.5. HTTP Status Codes . . . . . . . . . . . . . . . . . . 57 6.2.3. HTTP Headers . . . . . . . . . . . . . . . . . . . . 58
6.2.6. HTTP Authentication . . . . . . . . . . . . . . . . . 57 6.2.4. HTTP Operations . . . . . . . . . . . . . . . . . . . 58
6.2.7. Initialization of DSKPP . . . . . . . . . . . . . . . 57 6.2.5. HTTP Status Codes . . . . . . . . . . . . . . . . . . 59
6.2.8. Example Messages . . . . . . . . . . . . . . . . . . 58 6.2.6. HTTP Authentication . . . . . . . . . . . . . . . . . 59
7. DSKPP Schema . . . . . . . . . . . . . . . . . . . . . . . . 58 6.2.7. Initialization of DSKPP . . . . . . . . . . . . . . . 59
8. Conformance Requirements . . . . . . . . . . . . . . . . . . 66 6.2.8. Example Messages . . . . . . . . . . . . . . . . . . 60
9. Security Considerations . . . . . . . . . . . . . . . . . . . 68 7. DSKPP Schema . . . . . . . . . . . . . . . . . . . . . . . . 60
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 68 8. Conformance Requirements . . . . . . . . . . . . . . . . . . 69
9.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 70
9.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 68 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.2.2. Message Modifications . . . . . . . . . . . . . . . . 68 9.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 70
9.2.3. Message Deletion . . . . . . . . . . . . . . . . . . 70 9.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 70
9.2.4. Message Insertion . . . . . . . . . . . . . . . . . . 70 9.2.2. Message Modifications . . . . . . . . . . . . . . . . 70
9.2.5. Message Replay . . . . . . . . . . . . . . . . . . . 70 9.2.3. Message Deletion . . . . . . . . . . . . . . . . . . 72
9.2.6. Message Reordering . . . . . . . . . . . . . . . . . 71 9.2.4. Message Insertion . . . . . . . . . . . . . . . . . . 72
9.2.7. Man-in-the-Middle . . . . . . . . . . . . . . . . . . 71 9.2.5. Message Replay . . . . . . . . . . . . . . . . . . . 72
9.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 71 9.2.6. Message Reordering . . . . . . . . . . . . . . . . . 73
9.4. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 71 9.2.7. Man-in-the-Middle . . . . . . . . . . . . . . . . . . 73
9.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 73
9.4. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 73
9.5. Attacks on the Interaction between DSKPP and User 9.5. Attacks on the Interaction between DSKPP and User
Authentication . . . . . . . . . . . . . . . . . . . . . 71 Authentication . . . . . . . . . . . . . . . . . . . . . 74
9.6. Miscellaneous Considerations . . . . . . . . . . . . . . 72 9.6. Miscellaneous Considerations . . . . . . . . . . . . . . 75
9.6.1. Client Contributions to K_TOKEN Entropy . . . . . . . 72 9.6.1. Client Contributions to K_TOKEN Entropy . . . . . . . 75
9.6.2. Key Confirmation . . . . . . . . . . . . . . . . . . 73 9.6.2. Key Confirmation . . . . . . . . . . . . . . . . . . 75
9.6.3. Server Authentication . . . . . . . . . . . . . . . . 73 9.6.3. Server Authentication . . . . . . . . . . . . . . . . 75
9.6.4. User Authentication . . . . . . . . . . . . . . . . . 73 9.6.4. User Authentication . . . . . . . . . . . . . . . . . 75
9.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . 74 9.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . 76
10. Internationalization Considerations . . . . . . . . . . . . . 74 10. Internationalization Considerations . . . . . . . . . . . . . 77
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 75 11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 77
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 75 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 78
11.3. MIME Media Type Registration . . . . . . . . . . . . . . 76 11.3. MIME Media Type Registration . . . . . . . . . . . . . . 78
11.4. Status Code Registry . . . . . . . . . . . . . . . . . . 76 11.4. Status Code Registry . . . . . . . . . . . . . . . . . . 79
12. Intellectual Property Considerations . . . . . . . . . . . . 77 12. Intellectual Property Considerations . . . . . . . . . . . . 80
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 77 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 80
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
15.1. Normative references . . . . . . . . . . . . . . . . . . 78 15.1. Normative references . . . . . . . . . . . . . . . . . . 81
15.2. Informative references . . . . . . . . . . . . . . . . . 79 15.2. Informative references . . . . . . . . . . . . . . . . . 82
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 81 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 84
A.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 82 A.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 85
A.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . 82 A.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . 85
A.2.1. <KeyProvClientHello> Without a Preceding Trigger . . 83 A.2.1. <KeyProvClientHello> Without a Preceding Trigger . . 86
A.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 84 A.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 87
A.2.3. <KeyProvServerHello> Without a Preceding Trigger . . 85 A.2.3. <KeyProvServerHello> Without a Preceding Trigger . . 88
A.2.4. <KeyProvServerHello> Assuming a Preceding Trigger . . 86 A.2.4. <KeyProvServerHello> Assuming a Preceding Trigger . . 89
A.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 86 A.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 89
A.2.6. <KeyProvServerFinished> Using Default Encryption . . 88 A.2.6. <KeyProvServerFinished> Using Default Encryption . . 91
A.3. Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . 88 A.3. Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . 91
A.3.1. Example Using the Key Transport Profile . . . . . . . 88 A.3.1. Example Using the Key Transport Profile . . . . . . . 91
A.3.2. Example Using the Key Wrap Profile . . . . . . . . . 91 A.3.2. Example Using the Key Wrap Profile . . . . . . . . . 94
A.3.3. Example Using the Passphrase-Based Key Wrap Profile . 94 A.3.3. Example Using the Passphrase-Based Key Wrap Profile . 97
Appendix B. Integration with PKCS #11 . . . . . . . . . . . . . 97 Appendix B. Integration with PKCS #11 . . . . . . . . . . . . . 100
B.1. The 4-pass Variant . . . . . . . . . . . . . . . . . . . 97 B.1. The 4-pass Variant . . . . . . . . . . . . . . . . . . . 100
B.2. The 2-pass Variant . . . . . . . . . . . . . . . . . . . 97 B.2. The 2-pass Variant . . . . . . . . . . . . . . . . . . . 100
Appendix C. Example of DSKPP-PRF Realizations . . . . . . . . . 100 Appendix C. Example of DSKPP-PRF Realizations . . . . . . . . . 103
C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 100 C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 103
C.2. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 100 C.2. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 103
C.2.1. Identification . . . . . . . . . . . . . . . . . . . 100 C.2.1. Identification . . . . . . . . . . . . . . . . . . . 103
C.2.2. Definition . . . . . . . . . . . . . . . . . . . . . 100 C.2.2. Definition . . . . . . . . . . . . . . . . . . . . . 103
C.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 101 C.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 104
C.3. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . 102 C.3. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . 104
C.3.1. Identification . . . . . . . . . . . . . . . . . . . 102 C.3.1. Identification . . . . . . . . . . . . . . . . . . . 105
C.3.2. Definition . . . . . . . . . . . . . . . . . . . . . 102 C.3.2. Definition . . . . . . . . . . . . . . . . . . . . . 105
C.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 103 C.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 106
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
Intellectual Property and Copyright Statements . . . . . . . . . 105 Intellectual Property and Copyright Statements . . . . . . . . . 108
1. Introduction 1. Introduction
A symmetric key cryptographic module provides data authentication and While the range of problems for which symmetric key cryptography is
encryption services to software (or firmware) applications hosted on the solution of choice is somewhat smaller than for public key
hardware devices, such as personal computers, handheld mobile phones, cryptography, the problems it does solve, it solves exceedingly well.
one-time password tokens, USB flash drives, tape drives, etc. Until In particular, symmetric key algorithms are considerably faster than
recently, provisioning symmetric keys to these modules has been labor public key equivalents and allow for smaller key and signature sizes.
intensive, involving manual operations that are device-specific, and
inherently error-prone.
Fortunately, an increasing number of hardware devices enable Despite the clear advantages of employing symmetric keys as long term
programmatic initialization of their applications. For example, a credentials or access keys in certain circumstances, it has generally
U3-ready thumb drive lets users load and configure applications been assumed that any protocol in which ease of key management is
locally through a USB port on their PC. Other hardware devices, such required will employ public key cryptography. In particular it is
as Personal Digital Assistant (PDA) phones, allow users to load and assumed that only private components of public keypairs will be
configure applications over-the-air. Likewise, programmable employed as long term secrets and that symmetric cryptography will
cryptographic modules enable key issuers to provision symmetric keys only play a supporting role.
via the Internet, whether over-the-wire or over-the-air.
This document describes the Dynamic Symmetric Key Provisioning This document describes the Dynamic Symmetric Key Provisioning
Protocol (DSKPP), which leverages these recent technological Protocol (DSKPP), which provides a mechanism for provisioning
developments. DSKPP provides an open and interoperable mechanism for symmetric keys that provides the same degree of flexibility and
initializing and configuring symmetric keys to cryptographic modules convenience in use as equivalent infrastructures for public keys.
that are accessible over the Internet. The description is based on
the information contained in RFC4758, and contains specific
enhancements, such as User Authentication and support for the [PSKC]
format for transmission of keying material.
DSKPP is a client-server protocol with two variations. One variation DSKPP enables provisioning of symmetric keys to a symmetric key
establishes a symmetric key by mutually authenticated key agreement. cryptographic module that provides data authentication and encryption
The other variation relies on key distribution. In the former case, services to software (or firmware) applications hosted on a wide
key agreement enables two parties (a cryptographic module and key range of hardware devices, such as personal computers, handheld
provisioning server) to establish a symmetric cryptographic key using mobile phones, one-time password tokens, USB flash drives, tape
an exchange of four messages, such that the key is not transported drives, etc.
over the Internet. In the latter case, key distribution enables a
key provisioning server to transport a symmetric key to a
cryptographic module over the Internet using an exchange of two
messages. In either case, DSKPP is flexible enough to be run with or
without private-key capability in the cryptographic module, and with
or without an established public-key infrastructure.
All DSKPP communications consist of pairs of messages: a request and DSKPP provides an open and interoperable mechanism for initializing
a response. Each pair is called an "exchange", and each message sent and configuring symmetric keys to cryptographic modules that are
in an exchange is called a "pass". Thus, an implementation of DSKPP accessible over the Internet. The description is based on the
that relies on mutually authenticated key agreement is called the information contained in [RFC4758], and contains specific
"four-pass protocol"; an implementation of DSKPP that relies on key enhancements, such as User Authentication and support for the [PSKC]
distribution is called the "two-pass protocol". format for transmission of keying material.
DSKPP message flow always consists of a request followed by a DSKPP has two principal protocol variations. The four pass protocol
response. It is the responsibility of the client to ensure variation permits a symmetric key to be established that includes
reliability. If the response is not received with a timeout randomness contributed by both the client and the server. The two
interval, the client needs to retransmit the request (or abandon the pass protocol requires only one round trip instead of two and permits
connection). Number of retries and lengths of timeouts are not a server specified key to be established.
covered in this document because they do not affect interoperability.
1.1. Usage Scenarios 1.1. 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. its own special requirements.
1.1.1. Single Key Request 1.1.1. Single Key Request
The usual scenario is that a cryptographic module makes a request for The usual scenario is that a cryptographic module makes a request for
skipping to change at page 8, line 12 skipping to change at page 7, line 48
An issuer may provide a time-limited authentication code to a user An issuer may provide a time-limited authentication code to a user
during registration, which the user will input into the cryptographic during registration, which the user will input into the cryptographic
module to authenticate themselves with the provisioning server. The module to authenticate themselves with the provisioning server. The
server will allow a key to be provisioned to the cryptographic module server will allow a key to be provisioned to the cryptographic module
hosted by the user's device when user authentication is required only hosted by the user's device when user authentication is required only
if the user inputs a valid authentication code within the fixed time if the user inputs a valid authentication code within the fixed time
period established by the issuer. period established by the issuer.
1.1.5. Key Renewal 1.1.5. Key Renewal
A cryptographic module requests renewal of a symmetric key using the A cryptographic module requests renewal of the symmetric key material
same key ID already associated with the key. Such a need may occur attached to a key ID, as opposed to keeping the key value constant
in the case when a user wants to upgrade her device that houses the and refreshing the metadata. Such a need may occur in the case when
cryptographic module or when a key has expired. When a user uses the a user wants to upgrade her device that houses the cryptographic
same cryptographic module to, for example, perform strong module or when a key has expired. When a user uses the same
authentication at multiple Web login sites, keeping the same key ID cryptographic module to, for example, perform strong authentication
removes the need for the user to register a new key ID at each site. at multiple Web login sites, keeping the same key ID removes the need
for the user to register a new key ID at each site.
1.1.6. Pre-Loaded Key Replacement 1.1.6. Pre-Loaded Key Replacement
This scenario represents a special case of symmetric key renewal in This scenario represents a special case of symmetric key renewal in
which a local administrator can authenticate the user procedurally which a local administrator can authenticate the user procedurally
before initiating the provisioning process. It also allows for a before initiating the provisioning process. It also allows for a
device issuer to pre-load a key onto a cryptographic module with a device issuer to pre-load a key onto a cryptographic module with a
restriction that the key is replaced with a new key prior to use of restriction that the key is replaced with a new key prior to use of
the cryptographic module. Another variation of this scenario is the the cryptographic module. Another variation of this scenario is the
organization who recycles devices. In this case, a key issuer would organization who recycles devices. In this case, a key issuer would
provision a new symmetric key to a cryptographic module hosted on a provision a new symmetric key to a cryptographic module hosted on a
device that was previously owned by another user. device that was previously owned by another user.
Note that this usage scenario is essentially the same as the last Note that this usage scenario is essentially the same as the previous
scenario wherein the same key ID is used for renewal. scenario wherein the same key ID is used for renewal.
1.1.7. Pre-Shared Manufacturing Key 1.1.7. Pre-Shared Manufacturing Key
A cryptographic module is loaded onto a smart card after the card is A cryptographic module is loaded onto a smart card after the card is
issued to a user. The symmetric key for the cryptographic module issued to a user. The symmetric key for the cryptographic module
will then be provisioned using a secure channel mechanism present in will then be provisioned using a secure channel mechanism present in
many smart card platforms. This allows a direct secure channel to be many smart card platforms. This allows a direct secure channel to be
established between the smart card chip and the provisioning server. established between the smart card chip and the provisioning server.
For example, the card commands (i.e., Application Protocol Data For example, the card commands (i.e., Application Protocol Data
skipping to change at page 9, line 17 skipping to change at page 9, line 7
In this scenario, transport layer security does not provide end-to- In this scenario, transport layer security does not provide end-to-
end protection of keying material transported from the provisioning end protection of keying material transported from the provisioning
server to the cryptographic module. For example, TLS may terminate server to the cryptographic module. For example, TLS may terminate
at an application hosted on a PC rather than at the cryptographic at an application hosted on a PC rather than at the cryptographic
module (i.e., the endpoint) located on a data storage device. module (i.e., the endpoint) located on a data storage device.
Mutually authenticated key agreement provides end-to-end protection, Mutually authenticated key agreement provides end-to-end protection,
which TLS cannot provide. which TLS cannot provide.
1.2. Protocol Entities 1.2. Protocol Entities
In principle, the protocol involves a DSKPP client and a DSKPP A DSKPP provisioning transaction has three entities:
server. The DSKPP client manages communication between the
cryptographic module and the provisioning server. In this document, Server: The DSKPP provisioning server.
the DSKPP server represents the provisioning server.
Cryptographic Module: The cryptographic module to which the
symmetric keys are to be provisioned.
Client: The DSKPP client which manages communication between the
cryptographic module and the provisioning server.
While it is highly desirable for the entire communication between the
DSKPP client and server to be protected by means of a transport
providing confidentiality and integrity protection such as HTTP over
Transport Layer Security (TLS), such protection is not sufficient to
protect the exchange of the symmetric key data between the server and
the cryptographic module and the DSKPP protocol is designed to permit
implementations that satisfy this requirement.
The server only communicates to the client. As far as the server is
concerned, the client and cryptographic module may be considered to
be a single entity.
From a client-side security perspective, however, the client and the
cryptographic module are separate logical entities and may in some
implementations be separate physical entities as well.
A high-level object model that describes the client-side entities and A high-level object model that describes the client-side entities and
how they relate to each other is shown in Figure 1. Conceptually, how they relate to each other is shown in Figure 1. Conceptually,
each entity is represented by the definitions found in Section 2.2. each entity is represented by the definitions found in Section 2.2.
----------- ------------- ----------- -------------
| User | | Device | | User | | Device |
|---------|* owns *|-----------| |---------|* owns *|-----------|
| UserID |--------->| DeviceID | | UserID |--------->| DeviceID |
| ... | | ... | | ... | | ... |
skipping to change at page 12, line 25 skipping to change at page 12, line 25
other form of pre-shared key (such as may exist on a SIM-card), other form of pre-shared key (such as may exist on a SIM-card),
and is capable of performing private-key operations. and is capable of performing private-key operations.
o The cryptographic module is hosted by a device that has a built-in o The cryptographic module is hosted by a device that has a built-in
keypad with which a user may enter a passphrase, useful for keypad with which a user may enter a passphrase, useful for
deriving a key wrapping key for distribution of keying material. deriving a key wrapping key for distribution of keying material.
1.5. Presentation Syntax 1.5. Presentation Syntax
This documents presents DSKPP message formats and data elements using This documents presents DSKPP message formats and data elements using
XML syntax. The main goal in using this syntax is to document DSKPP. XML syntax. The main goal in using this syntax is to document DSKPP.
Application of the syntax beyond this goal is OPTIONAL. Application of the syntax beyond this goal is OPTIONAL (i.e., an
implementation that does not use XML and instead uses ASN.1 could
claim compliance with this specification).
1.5.1. Versions 1.5.1. Versions
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.
1.5.2. Namespaces 1.5.2. Namespaces
The XML namespace [XMLNS] URN that MUST be used by implementations of The XML namespace [XMLNS] URN that MUST be used by implementations of
this syntax is: this syntax is:
skipping to change at page 15, line 43 skipping to change at page 16, line 4
|| String concatenation || String concatenation
[x] Optional element x [x] Optional element x
A ^ B Exclusive-OR operation on strings A and B (where A A ^ B Exclusive-OR operation on strings A and B (where A
and B are of equal length) and B are of equal length)
<XMLElement> A typographical convention used in the body of the <XMLElement> A typographical convention used in the body of the
text text
DSKPP-PRF(k,s,dsLen) A keyed pseudo-random function (see
DSKPP-PRF(k,x,l) A keyed pseudo-random function (see Section 3.5) Section 3.3.1)
E(k,m) Encryption of m with the key k E(k,m) Encryption of m with the key k
K Key used to encrypt R_C (either K_SERVER or K Key used to encrypt R_C (either K_SERVER or
K_SHARED), or in MAC or DSKPP_PRF computations K_SHARED), or in MAC or DSKPP_PRF computations
K_AC Secret key that is derived from the Authentication K_AC Secret key that is derived from the Authentication
Code and used for user authentication purposes Code and used for user authentication purposes
K_MAC Secret key derived during a DSKPP exchange for use K_MAC Secret key derived during a DSKPP exchange for use
with key confirmation with key confirmation
K_MAC' A second secret key used for server authentication K_MAC' A second secret key used for server authentication
skipping to change at page 17, line 25 skipping to change at page 17, line 28
SAL Security Attribute List (see Section 2.2) SAL Security Attribute List (see Section 2.2)
SC Security Context (see Section 2.2) SC Security Context (see Section 2.2)
TLS Transport Layer Security TLS Transport Layer Security
URL Uniform Resource Locator URL Uniform Resource Locator
USB Universal Serial Bus USB Universal Serial Bus
XML eXtensible Markup Language XML eXtensible Markup Language
3. DSKPP Protocol Details 3. DSKPP Protocol Details
DSKPP enables symmetric key provisioning between a DSKPP server and DSKPP enables symmetric key provisioning between a DSKPP server and
DSKPP client. The DSKPP protocol supports the request and response DSKPP client.
messages shown in Figure 2. These messages are described below.
3.1. Protocol Initiation
The DSKPP protocol has two- and four-pass variations, either of which
may be initiated by either the client or the server making four
possible successful protocol interactions. In every case the first
message sent from the client to the server is <KeyProvClientHello>
and the last message is <KeyProvServerFinished> and is sent from the
server to the client.
3.1.1. Server Initiation
The DSKPP protocol may be initiated by the server by means of a
<KeyProvTrigger> message to which the client responds with a
<KeyProvClientHello> message as shown in Figure 2. The trigger
message always contains a nonce to allow the server to couple the
trigger with a later <KeyProvClientHello> request.
+---------------+ +---------------+
| | | |
| DSKPP Client | | DSKPP Server |
| | | |
+---------------+ +---------------+
| |
| <--------- <KeyProvTrigger> --------- |
| |
| ------- <KeyProvClientHello> -------> |
... ...
Figure 2: Server Initiated DSKPP (start)
3.1.2. Client Initiation
The DSKPP protocol may be initiated by the client by means of the
<KeyProvClientHello> message Figure 3 message.
+---------------+ +---------------+
| | | |
| DSKPP Client | | DSKPP Server |
| | | |
+---------------+ +---------------+
| |
| ------- <KeyProvClientHello> -------> |
... ...
Figure 3: Client Initiated DSKPP (start)
3.2. Protocol Variations
Once contact has been initiated, the client and server MAY engage in
either a two-pass or four-pass protocol depending on the protocol
options specified in the <KeyProvClientHello> message and the server
configuration.
3.2.1. Four-Pass Protocol Interaction
In the four-pass version of the protocol the server responds to the
<KeyProvClientHello> message with <KeyProvServerHello>. The client
then responds with <KeyProvClientNonce> and the server with
<KeyProvServerFinished> as shown in Figure 4.
+---------------+ +---------------+ +---------------+ +---------------+
| | | | | | | |
| DSKPP Client | | DSKPP Server | | DSKPP Client | | DSKPP Server |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
| | | |
| [ <--------- <KeyProvTrigger> --------- ] | | [ <--------- <KeyProvTrigger> --------- ] |
| | | |
| ------- <KeyProvClientHello> -------> | | ------- <KeyProvClientHello> -------> |
| (Applicable to 4- and 2-pass) |
| | | |
| <------ <KeyProvServerHello> -------- | | <------ <KeyProvServerHello> -------- |
| (Applicable to 4-pass only) |
| | | |
| ------- <KeyProvClientNonce> -------> | | ------- <KeyProvClientNonce> -------> |
| (Applicable to 4-pass only) |
| | | |
| <---- <KeyProvServerFinished> ------- | | <---- <KeyProvServerFinished> ------- |
| (Applicable to 4- and 2-pass) |
| | | |
Figure 2: The DSKPP protocol (with OPTIONAL preceding trigger) Figure 4: Four Pass DSKPP protocol (with OPTIONAL preceding trigger)
[<KeyProvTrigger>]: A DSKPP server may initiate the DSKPP protocol
by sending a <KeyProvTrigger> message. For example, this message
may be sent in response to a user requesting a symmetric key in a
browsing session. The trigger message always contains a nonce to
allow the server to couple the trigger with a later
<KeyProvClientHello> request.
<KeyProvClientHello>: With this request, a DSKPP client initiates [<KeyProvTrigger> Message]: The <KeyProvTrigger> message is used to
contact with the DSKPP server, indicating which protocol versions initiate a request from the server. The trigger message always
and variations (four-pass or two-pass), key types, encryption and contains a nonce to allow the server to couple the trigger with a
MAC algorithms that it supports. In addition, the request may later <KeyProvClientHello> request.
include client authentication data that the DSKPP server uses to
verify proof-of-possession of the device.
<KeyProvServerHello>: Upon receiving a <KeyProvClientHello> request, <KeyProvClientHello>: The <KeyProvClientHello> request is sent by a
the DSKPP server uses the <KeyProvServerHello> response to DSKPP client to initiate contact with the DSKPP server,
specify which protocol version and variation, key type, indicating which protocol versions and variations (four-pass or
encryption algorithm, and MAC algorithm that will be used by the two-pass), key types, encryption and MAC algorithms that it
DSKPP server and DSKPP client during the protocol run. The supports. In addition, the request may include client
decision of which variation, key type, and cryptographic authentication data that the DSKPP server uses to verify proof-
algorithms to pick is policy- and implementation-dependent and of-possession of the device.
therefore outside the scope of this document.
The <KeyProvServerHello> response includes the DSKPP server's Server Processing of <KeyProvClientHello>: Upon receiving a
random nonce, R_S. The response also consists of information <KeyProvClientHello> request, the DSKPP server uses the
about either a shared secret key, or its own public key, that the <KeyProvServerHello> response to specify which protocol version
DSKPP client uses when sending its protected random nonce, R_C, and variation, key type, encryption algorithm, and MAC algorithm
in the <KeyProvClientNonce> request (see below). that will be used by the DSKPP server and DSKPP client during the
protocol run. The decision of which variation, key type, and
cryptographic algorithms to pick is policy- and implementation-
dependent and therefore outside the scope of this document.
<KeyProvServerHello>: The <KeyProvServerHello> response is only used
in the four pass protocol, it includes the DSKPP server's random
nonce, R_S. The response also consists of information about
either a shared secret key, or its own public key, that the DSKPP
client uses when sending its protected random nonce, R_C, in the
<KeyProvClientNonce> request (see below).
Optionally, the DSKPP server may provide a MAC that the DSKPP Optionally, the DSKPP server may provide a MAC that the DSKPP
client may use for server authentication. client may use for server authentication.
<KeyProvClientNonce>: With this request, a DSKPP client and DSKPP Client Processing of <KeyProvServerHello>: On receipt of
server securely exchange protected data, e.g., the protected <KeyProvServerHello>, the client encrypts the random client nonce
random nonce R_C. In addition, the request may include user R_c under the (provided) server key K.
<KeyProvClientNonce>: The <KeyProvClientNonce> request is only used
in the four pass protocol, it is used to exchange protected data,
i.e., the protected random nonce R_C. In addition, the request
may include user authentication data that the DSKPP server uses
to verify proof-of-possession of the device.
<KeyProvServerFinished>: The <KeyProvServerFinished> response is a
confirmation message that includes a key package that holds
configuration data, but no keying material.
Optionally, the DSKPP server may provide a MAC that the DSKPP
client may use for server authentication.
3.2.2. Two-Pass Protocol Interaction
In the two-pass version of the protocol the server responds to the
<KeyProvClientHello> message with a <KeyProvServerFinished> message
Figure 5
+---------------+ +---------------+
| | | |
| DSKPP Client | | DSKPP Server |
| | | |
+---------------+ +---------------+
| |
| [ <--------- <KeyProvTrigger> --------- ] |
| |
| ------- <KeyProvClientHello> -------> |
| |
| <---- <KeyProvServerFinished> ------- |
| |
Figure 5: Two Pass DSKPP protocol (with OPTIONAL preceding trigger)
[<KeyProvTrigger> Message]: The <KeyProvTrigger> message is used to
initiate a request from the server. The trigger message always
contains a nonce to allow the server to couple the trigger with a
later <KeyProvClientHello> request.
<KeyProvClientHello>: The <KeyProvClientHello> request is sent by a
DSKPP client to initiate contact with the DSKPP server,
indicating which protocol versions and variations (four-pass or
two-pass), key types, encryption and MAC algorithms that it
supports. In addition, the request may include client
authentication data that the DSKPP server uses to verify proof- authentication data that the DSKPP server uses to verify proof-
of-possession of the device. of-possession of the device.
<KeyProvServerFinished>: The <KeyProvServerFinished> response is a <KeyProvServerFinished>: The <KeyProvServerFinished> response is a
confirmation message that includes a key package that holds confirmation message that includes a key package that holds
configuration data, and may also contain protected keying configuration data and contain protected keying material.
material (this depends on the protocol variation, as discussed
below).
Optionally, the DSKPP server may provide a MAC that the DSKPP Optionally, the DSKPP server may provide a MAC that the DSKPP
client may use for server authentication. client may use for server authentication.
3.1. Four-Pass Protocol Usage 3.3. Cryptographic Construction
3.3.1. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF
3.3.1.1. Introduction
Regardless of the protocol variation employed, there is a requirement
for a cryptographic primitive that provides a deterministic
transformation of a secret key k and a varying length octet string s
to a bitstring of specified length dsLen.
This primitive must meet the same requirements as for a keyed hash
function: It MUST take an arbitrary length input, and generate an
output that is one-way and collision-free (for a definition of these
terms, see, e.g., [FAQ]). Further, its output MUST be unpredictable
even if other outputs for the same key are known.
From the point of view of this specification, DSKPP-PRF is a "black-
box" function that, given the inputs, generates a pseudorandom value
and MAY be realized by any appropriate and competent cryptographic
technique. Appendix C contains two example realizations of DSKPP-
PRF.
3.3.1.2. Declaration
DSKPP-PRF (k, s, dsLen)
Input:
k secret key in octet string format
s octet string of varying length consisting of variable data
distinguishing the particular string being derived
dsLen desired length of the output
Output:
DS pseudorandom string, dsLen-octets long
For the purposes of this document, the secret key k MUST be at least
16 octets long.
3.4. Four-Pass Protocol Usage
This section describes the message flow and methods that comprise the This section describes the message flow and methods that comprise the
four-pass protocol variant. four-pass protocol variant.
3.1.1. Message Flow 3.4.1. Message Flow
The four-pass protocol flow consists of two message exchanges: The four-pass protocol flow consists of two message exchanges:
1: Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerHello> 1: Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerHello>
2: Pass 3 = <KeyProvClientNonce>, Pass 4 = <KeyProvServerFinished> 2: Pass 3 = <KeyProvClientNonce>, Pass 4 = <KeyProvServerFinished>
The first pair of messages negotiate cryptographic algorithms and The first pair of messages negotiate cryptographic algorithms and
exchange nonces. The second pair of messages establishes a symmetric exchange nonces. The second pair of messages establishes a symmetric
key using mutually authenticated key agreement. key using mutually authenticated key agreement.
The DSKPP server MUST ensure that a generated key is associated with The DSKPP server MUST ensure that a generated key is associated with
the correct cryptographic module, and if applicable, the correct the correct cryptographic module, and if applicable, the correct
user. To do this, the DSKPP server MAY couple an initial user user. To do this, the DSKPP server MAY couple an initial user
authentication to the DSKPP execution using one of the mechanisms authentication to the DSKPP execution using one of the mechanisms
described in Section 3.4. described in Section 3.7.
The purpose and content of each message are described below, The purpose and content of each message are described below,
including the optional <KeyProvTrigger>. including the optional <KeyProvTrigger>.
DSKPP Client DSKPP Server DSKPP Client DSKPP Server
------------ ------------ ------------ ------------
[<---] R_TRIGGER, [DeviceID], [<---] R_TRIGGER, [DeviceID],
[KeyID], [URL_S] [KeyID], [URL_S]
The DSKPP server optionally sends a <KeyProvTrigger> message to the The DSKPP server optionally sends a <KeyProvTrigger> message to the
DSKPP client. The trigger message MUST contain a nonce, R_TRIGGER, DSKPP client. The trigger message MUST contain a nonce, R_TRIGGER,
to allow the server to couple the trigger with a later to allow the server to couple the trigger with a later
<KeyProvClientHello> request. <KeyProvTrigger> MAY include a DeviceID <KeyProvClientHello> request. <KeyProvTrigger> MAY include a DeviceID
to allow the client to select the device with which it will to allow the client to select the device with which it will
communicate (for more information about device identification, refer communicate (for more information about device identification, refer
to Section 3.3). In the case of key renewal, <KeyProvTrigger> MAY to Section 3.6). In the case of key renewal, <KeyProvTrigger> MAY
include the identifier for the key, KeyID, that is being replaced. include the identifier for the key, KeyID, that is being replaced.
Finally, the trigger MAY contain a URL for the DSKPP client to use Finally, the trigger MAY contain a URL for the DSKPP client to use
when contacting the DSKPP server. when contacting the DSKPP server.
DSKPP Client DSKPP Server DSKPP Client DSKPP Server
------------ ------------ ------------ ------------
SAL, [R_TRIGGER], SAL, [R_TRIGGER],
[DeviceID], [KeyID] ---> [DeviceID], [KeyID] --->
The DSKPP client sends a <KeyProvClientHello> message to the DSKPP The DSKPP client sends a <KeyProvClientHello> message to the DSKPP
skipping to change at page 20, line 33 skipping to change at page 23, line 45
will use the SC to select the DSKPP version and variation (e.g., will use the SC to select the DSKPP version and variation (e.g.,
four-pass), type of key to generate, and cryptographic algorithms four-pass), type of key to generate, and cryptographic algorithms
that it will use for the remainder of the protocol run. that it will use for the remainder of the protocol run.
<KeyProvServerHello> MUST also include the server's random nonce, <KeyProvServerHello> MUST also include the server's random nonce,
R_S, whose length may depend on the selected key type. In addition, R_S, whose length may depend on the selected key type. In addition,
the <KeyProvServerHello> message MAY provide K, which represents its the <KeyProvServerHello> message MAY provide K, which represents its
own public key (K_SERVER) or information about a shared secret key own public key (K_SERVER) or information about a shared secret key
(K_SHARED) to use for encrypting the cryptographic module's random (K_SHARED) to use for encrypting the cryptographic module's random
nonce (see description of <KeyProvClientNonce> below). Optionally, nonce (see description of <KeyProvClientNonce> below). Optionally,
<KeyProvServerHello> MAY include a MAC that the DSKPP client can use <KeyProvServerHello> MAY include a MAC that the DSKPP client can use
for server authentication in the case of key renewal (Section 3.1.4.1 for server authentication in the case of key renewal (Section 3.4.4.1
describes how to calculate the MAC). describes how to calculate the MAC).
DSKPP Client DSKPP Server DSKPP Client DSKPP Server
------------ ------------ ------------ ------------
E(K,R_C), [AD] ---> E(K,R_C), [AD] --->
Based on the Security Context (SC) provided in the Based on the Security Context (SC) provided in the
<KeyProvServerHello> message, the cryptographic module generates a <KeyProvServerHello> message, the cryptographic module generates a
random nonce, R_C. The length of the nonce R_C will depend on the random nonce, R_C. The length of the nonce R_C will depend on the
selected key type. The cryptographic module encrypts R_C using the selected key type. The cryptographic module encrypts R_C using the
selected encryption algorithm and with a key, K, that is either the selected encryption algorithm and with a key, K, that is either the
DSKPP server's public key, K_SERVER, or a shared secret key, DSKPP server's public key, K_SERVER, or a shared secret key,
K_SHARED, as indicated by the DSKPP server. K_SHARED, as indicated by the DSKPP server.
Note: If K is equivalent to K_SERVER, then the cryptographic module Note: If K is equivalent to K_SERVER, then the cryptographic module
SHOULD verify the server's certificate before using it to encrypt R_C SHOULD verify the server's certificate before using it to encrypt R_C
in accordance with [RFC3280]. in accordance with [RFC5280].
Note: If successful execution of the protocol will result in the Note: If successful execution of the protocol will result in the
replacement of an existing key with a newly generated one, the DSKPP replacement of an existing key with a newly generated one, the DSKPP
client MUST verify the MAC provided in the <KeyProvServerHello> client MUST verify the MAC provided in the <KeyProvServerHello>
message. The DSKPP client MUST terminate the DSKPP session if the message. The DSKPP client MUST terminate the DSKPP session if the
MAC does not verify, and MUST delete any nonces, keys, and/or secrets MAC does not verify, and MUST delete any nonces, keys, and/or secrets
associated with the failed run. associated with the failed run.
The DSKPP client MUST send the encrypted random nonce to the DSKPP The DSKPP client MUST send the encrypted random nonce to the DSKPP
server in a <KeyProvClientNonce> message, and MAY include client server in a <KeyProvClientNonce> message, and MAY include client
Authentication Data (AD), such as a MAC derived from an Authentication Data (AD), such as a MAC derived from an
authentication code and R_C (refer to Section 3.4.1). Finally, the authentication code and R_C (refer to Section 3.7.1). Finally, the
cryptographic module calculates and stores a symmetric key, K_TOKEN, cryptographic module calculates and stores a symmetric key, K_TOKEN,
of the key type specified in the SC received in <KeyProvServerHello> of the key type specified in the SC received in <KeyProvServerHello>
(refer to Section 3.1.2.2.<KeyProvServerFinished> for a description (refer to Section 3.4.2.2.<KeyProvServerFinished> for a description
of how K_TOKEN is generated). of how K_TOKEN is generated).
DSKPP Client DSKPP Server DSKPP Client DSKPP Server
------------ ------------ ------------ ------------
<--- KP, MAC <--- KP, MAC
If Authentication Data (AD) was received in the <KeyProvClientNonce> If Authentication Data (AD) was received in the <KeyProvClientNonce>
message, then the DSKPP server MUST authenticate the user in message, then the DSKPP server MUST authenticate the user in
accordance with Section 3.4.1. If authentication fails, then DSKPP accordance with Section 3.7.1. If authentication fails, then DSKPP
server MUST abort. Otherwise, the DSKPP server decrypts R_C, server MUST abort. Otherwise, the DSKPP server decrypts R_C,
calculates K_TOKEN from the combination of the two random nonces R_S calculates K_TOKEN from the combination of the two random nonces R_S
and R_C, the encryption key K, and possibly some other data (refer to and R_C, the encryption key K, and possibly some other data (refer to
Section 3.1.2.2 for a description of how K_TOKEN is generated). The Section 3.4.2.2 for a description of how K_TOKEN is generated). The
server then associates K_TOKEN with the cryptographic module in a server then associates K_TOKEN with the cryptographic module in a
server-side data store. The intent is that the data store later on server-side data store. The intent is that the data store later on
will be used by some service that needs to verify or decrypt data will be used by some service that needs to verify or decrypt data
produced by the cryptographic module and the key. produced by the cryptographic module and the key.
Once the association has been made, the DSKPP server sends a Once the association has been made, the DSKPP server sends a
confirmation message to the DSKPP client called confirmation message to the DSKPP client called
<KeyProvServerFinished>. The confirmation message MUST include a Key <KeyProvServerFinished>. The confirmation message MUST include a Key
Package (KP) that holds an identifier for the generated key (but not Package (KP) that holds an identifier for the generated key (but not
the key itself) and additional configuration information, e.g., the the key itself) and additional configuration information, e.g., the
identity of the DSKPP server. The default symmetric key package identity of the DSKPP server. The default symmetric key package
format is based on the Portable Symmetric Key Container (PSKC) format is based on the Portable Symmetric Key Container (PSKC)
defined in [PSKC]. Alternative formats MAY include [SKPC-ASN.1], defined in [PSKC]. Alternative formats MAY include [SKPC-ASN.1],
PKCS#12 [PKCS-12], or PKCS#5 XML [PKCS-5-XML] format. In addition to PKCS#12 [PKCS-12], or PKCS#5 XML [PKCS-5-XML] format. In addition to
a Key Package, <KeyProvServerFinished> MUST also include a MAC that a Key Package, <KeyProvServerFinished> MUST also include a MAC that
the DSKPP client will use to authenticate the message before the DSKPP client will use to authenticate the message before
committing K_TOKEN. committing K_TOKEN
After receiving a <KeyProvServerFinished> message with Status = After receiving a <KeyProvServerFinished> message with Status =
"Success", the DSKPP client MUST verify the MAC. The DSKPP client "Success", the DSKPP client MUST verify the MAC. 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 MUST, in this case, also delete any nonces, keys, and/or secrets
associated with the failed run of the protocol. If associated with the failed run of the protocol. If
<KeyProvServerFinished> has Status = "Success" and the MAC was <KeyProvServerFinished> has Status = "Success" and the MAC was
verified, then the DSKPP client MUST associate the provided key verified, then the DSKPP client MUST associate the provided key
package with the generated key K_TOKEN, and store this data package with the generated key K_TOKEN, and store this data
permanently. After this operation, it MUST NOT be possible to permanently. After this operation, it MUST NOT be possible to
overwrite the key unless knowledge of an authorizing key is proven overwrite the key unless knowledge of an authorizing key is proven
through a MAC on a later <KeyProvServerHello> (and through a MAC on a later <KeyProvServerHello> (and
<KeyProvServerFinished>) message. <KeyProvServerFinished>) message.
3.1.2. Generation of Symmetric Keys for Cryptographic Modules 3.4.2. Generation of Symmetric Keys for Cryptographic Modules
With 4-pass DSKPP, the symmetric key that is the target of With 4-pass DSKPP, the symmetric key that is the target of
provisioning, is generated on-the-fly without being transferred provisioning, is generated on-the-fly without being transferred
between the DSKPP client and DSKPP server. A sample data flow between the DSKPP client and DSKPP server. A sample data flow
depicting how this works followed by computational information are depicting how this works followed by computational information are
provided in the subsections below. provided in the subsections below.
3.1.2.1. Data Flow 3.4.2.1. Data Flow
A sample data flow showing key generation during the 4-pass protocol A sample data flow showing key generation during the 4-pass protocol
is shown in Figure 3. is shown in Figure 6.
+----------------------+ +-------+ +----------------------+ +----------------------+ +-------+ +----------------------+
| +------------+ | | | | | | +------------+ | | | | |
| | Server key | | | | | | | | Server key | | | | | |
| +<-| Public |------>------------->-------------+---------+ | | +<-| Public |------>------------->-------------+---------+ |
| | | Private | | | | | | | | | | | Private | | | | | | | |
| | +------------+ | | | | | | | | | +------------+ | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| V V | | | | V V | | V V | | | | V V |
| | +---------+ | | | | +---------+ | | | | +---------+ | | | | +---------+ | |
skipping to change at page 23, line 39 skipping to change at page 26, line 39
| +-------+ | | | | +-------+ | | +-------+ | | | | +-------+ |
| | Key | | | | | | Key | | | | Key | | | | | | Key | |
| +-------+ | | | | +-------+ | | +-------+ | | | | +-------+ |
| +-------+ | | | | +-------+ | | +-------+ | | | | +-------+ |
| |Key Id |-------->------------->------|Key Id | | | |Key Id |-------->------------->------|Key Id | |
| +-------+ | | | | +-------+ | | +-------+ | | | | +-------+ |
+----------------------+ +-------+ +----------------------+ +----------------------+ +-------+ +----------------------+
DSKPP Server DSKPP Client DSKPP Client DSKPP Server DSKPP Client DSKPP Client
(PC Host) (cryptographic module) (PC Host) (cryptographic module)
Figure 3: Principal data flow for DSKPP key generation - Figure 6: Principal data flow for DSKPP key generation -
using public server key using public server key
Note: Conceptually, although R_C is one pseudorandom string, it may Note: Conceptually, although R_C is one pseudorandom string, it may
be viewed as consisting of two components, R_C1 and R_C2, where R_C1 be viewed as consisting of two components, R_C1 and R_C2, where R_C1
is generated during the protocol run, and R_C2 can be pre-generated is generated during the protocol run, and R_C2 can be pre-generated
and loaded on the cryptographic module before the device is issued to and loaded on the cryptographic module before the device is issued to
the user. In that case, the latter string, R_C2, SHOULD be unique the user. In that case, the latter string, R_C2, SHOULD be unique
for each cryptographic module. for each cryptographic module.
The inclusion of the two random nonces R_S and R_C in the key The inclusion of the two random nonces R_S and R_C in the key
skipping to change at page 24, line 25 skipping to change at page 27, line 25
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 independent
from the one used for the key generation). from the one used for the key generation).
3.1.2.2. Computing the Symmetric Key 3.4.2.2. Computing the Symmetric Key
In DSKPP, K_TOKEN and K_MAC are generated using the DSKPP-PRF In DSKPP, K_TOKEN and K_MAC are derived from provisioning key,
function defined in Section 3.5, a secret random value R_C chosen by K_PROV, which is generated using the DSKPP-PRF function as follows
the DSKPP client, a random value R_S chosen by the DSKPP server, and (refer to Section 3.3.1):
the key K used to encrypt R_C. The input parameter s of DSKPP-PRF is
set to the concatenation of the (ASCII) string "Key generation", K,
and R_S. The input parameter dsLen is set to the desired length of
the key, K_PROV, whose first half constitutes K_MAC and second half
constitutes K_TOKEN. The combined length is determined by the type
of K_TOKEN and K_MAC:
dsLen = (desired length of K_PROV, i.e., the combined length of K_PROV = DSKPP-PRF(k,s,dsLen), where
K_TOKEN and K_MAC)
K_PROV = DSKPP-PRF (R_C, "Key generation" || K || R_S, dsLen) k = R_C (i.e., the secret random value chosen by the DSKPP
client)
s = "Key generation" || K || R_S (where K is the key used to
encrypt R_C and R_S is the random value chosen by the DSKPP
server)
dsLen = (desired length of K_PROV whose first half constitutes
K_MAC and second half constitutes K_TOKEN)
Then K_TOKEN and K_MAC derived from K_PROV, where Then K_TOKEN and K_MAC derived from K_PROV, where
K_PROV = K_MAC || K_TOKEN K_PROV = K_MAC || K_TOKEN
When computing K_PROV, the derived keys, K_MAC and K_TOKEN, MAY be When computing K_PROV, the derived keys, K_MAC and K_TOKEN, MAY be
subject to an algorithm-dependent transform before being adopted as a subject to an algorithm-dependent transform before being adopted as a
key of the selected type. One example of this is the need for parity key of the selected type. One example of this is the need for parity
in DES keys. in DES keys.
3.1.3. Encryption of Pseudorandom Nonces Sent from the DSKPP Client 3.4.3. Encryption of Pseudorandom Nonces Sent from the DSKPP Client
DSKPP client random nonce(s) are either encrypted with the public key DSKPP client random nonce(s) are either encrypted with the public key
provided by the DSKPP server or by a shared secret key. For example, provided by the DSKPP server or by a shared secret key. For example,
in the case of a public RSA key, an RSA encryption scheme from PKCS in the case of a public RSA key, an RSA encryption scheme from PKCS
#1 [PKCS-1] MAY be used. #1 [PKCS-1] MAY be used.
In the case of a shared secret key, to avoid dependence on other In the case of a shared secret key, to avoid dependence on other
algorithms, the DSKPP client MAY use the DSKPP-PRF function described algorithms, the DSKPP client MAY use the DSKPP-PRF function described
herein with the shared secret key K_SHARED as input parameter K (in herein with the shared secret key K_SHARED as input parameter k (in
this case, K_SHARED SHOULD be used solely for this purpose), the this case, K_SHARED SHOULD be used solely for this purpose), the
concatenation of the (ASCII) string "Encryption" and the server's concatenation of the (ASCII) string "Encryption" and the server's
nonce R_S as input parameter s, and dsLen set to the length of R_C: nonce R_S as input parameter s, and dsLen set to the length of R_C:
dsLen = len(R_C) dsLen = len(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.
Encryption of R_C MAY then be achieved by XOR-ing DS with R_C: Encryption of R_C MAY then be achieved by XOR-ing DS with R_C:
E(DS, R_C) = DS ^ R_C E(DS, R_C) = DS ^ R_C
The DSKPP server will then perform the reverse operation to extract The DSKPP server will then perform the reverse operation to extract
R_C from E(DS, R_C). R_C from E(DS, R_C).
3.1.4. MAC Calculations 3.4.4. MAC Calculations
3.1.4.1. Server Authentication in the Case of Key Renewal 3.4.4.1. Server Authentication in the Case of Key Renewal
A MAC MUST be present in the <KeyProvServerHello> message if the A MAC MUST be present in the <KeyProvServerHello> message if the
DSKPP run will result in the replacement of an existing key with a DSKPP run will result in the replacement of an existing key with a
new one, as proof that the DSKPP server is authenticated to perform new one, as proof that the DSKPP server is authenticated to perform
the action. When the MAC value is used for server authentication, the action. When the MAC value is used for server authentication,
the value MAY be computed by using the DSKPP-PRF function of the value MAY be computed by using the DSKPP-PRF function of
Section 3.5, in which case the input parameter s MUST be set to the Section 3.3.1, in which case the input parameter k MUST be set to the
existing MAC key K_MAC' (i.e., the value of the MAC key that existed
before this protocol run); and input parameter s MUST be set to the
concatenation of the (ASCII) string "MAC 1 computation", R (if sent concatenation of the (ASCII) string "MAC 1 computation", R (if sent
by the client), and R_S, and K MUST be set to the existing MAC key by the client), and R_S. Note that the implementation MAY specify
K_MAC' (i.e., the value of the MAC key that existed before this K_MAC' to be the value of the K_TOKEN that is being replaced, or a
protocol run). Note that the implementation may specify K_MAC' to be version of K_MAC from the previous protocol run.
the value of the K_TOKEN that is being replaced, or a version of
K_MAC from the previous protocol run.
The input parameter dsLen MUST be set to the length of R_S: The input parameter dsLen MUST be set to the length of R_S:
dsLen = len(R_S) dsLen = len(R_S)
MAC = DSKPP-PRF (K_MAC', "MAC 1 computation" || [R ||] R_S, dsLen) MAC = DSKPP-PRF (K_MAC', "MAC 1 computation" || [R ||] R_S, dsLen)
The MAC algorithm MUST be the same as the algorithm used for key The MAC algorithm MUST be the same as the algorithm used for key
confirmation purposes. confirmation purposes.
3.1.4.2. Key Confirmation 3.4.4.2. Key Confirmation
To avoid a false "Commit" message causing the cryptographic module to To avoid a false "Commit" message causing the cryptographic module to
end up in an initialized state in which the server does not recognize end up in an initialized state in which the server does not recognize
the stored key, <KeyProvServerFinished> messages MUST be the stored key, <KeyProvServerFinished> messages MUST be
authenticated with a MAC, calculated as follows: authenticated with a MAC, calculated as follows:
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 2 computation" || msg_hash, dsLen) MAC = DSKPP-PRF (K_MAC, "MAC 2 computation" || msg_hash, dsLen)
where where
MAC The MAC MUST be calculated using the already established MAC The MAC MUST be calculated using the already established
MAC algorithm and MUST be computed on the (ASCII) string MAC algorithm and MUST be computed on the (ASCII) string
"MAC 2 computation" and msg_hash using the existing the "MAC 2 computation" and msg_hash using the existing the
MAC key K_MAC. MAC key K_MAC.
K_MAC The key derived from K_PROV, as described in K_MAC The key derived from K_PROV, as described in
Section 3.1.2.2. Section 3.4.2.2.
msg_hash The message hash, defined below, of messages msg_1, ..., msg_hash The message hash, defined below, of messages msg_1, ...,
msg_n. msg_n.
If DSKPP-PRF (defined in Section 3.5) is used as the MAC algorithm, If DSKPP-PRF (defined in Section 3.3.1) is used as the MAC algorithm,
then the input parameter s MUST consist of the concatenation of the then the input parameter s MUST consist of the concatenation of the
(ASCII) string "MAC 2 computation" and msg_hash, and the parameter (ASCII) string "MAC 2 computation" and msg_hash, and the parameter
dsLen MUST be set to the length of msg_hash. dsLen MUST be set to the length of msg_hash.
3.1.4.3. Message Hash Algorithm 3.4.4.3. Message Hash Algorithm
To compute a message hash for a MAC, given a sequence of DSKPP To compute a message hash for a MAC, given a sequence of DSKPP
messages msg_1, ..., msg_n, the following operations MUST be carried messages msg_1, ..., msg_n, the following operations MUST be carried
out: out:
a. The sequence of messages contains all DSKPP Request and Response a. The sequence of messages contains all DSKPP Request and Response
messages up to but not including this message. messages up to but not including this message.
b. Re-transmitted messages are removed from the sequence of b. Re-transmitted messages are removed from the sequence of
messages. messages.
Note: The resulting sequence of messages MUST be an alternating Note: The resulting sequence of messages MUST be an alternating
sequence of DSKPP Request and DSKPP Response messages sequence of DSKPP Request and DSKPP Response messages
c. The contents of each message is concatenated together. c. The contents of each message is concatenated together.
d. The resulting string is hashed using SHA-256 in accordance with d. The resulting string is hashed using SHA-256 in accordance with
[FIPS180-SHA]. [FIPS180-SHA].
3.2. Two-Pass Protocol Usage 3.5. Two-Pass Protocol Usage
This section describes the message flow and methods that comprise the This section describes the message flow and methods that comprise the
two-pass protocol variant. Two-pass DSKPP is essentially a transport two-pass protocol variant. Two-pass DSKPP is essentially a transport
of keying material from the DSKPP server to the DSKPP client. The of keying material from the DSKPP server to the DSKPP client. The
keying material is contained in a package that is formatted in such a keying material is contained in a package that is formatted in such a
way that ensures that the symmetric key that is being established, way that ensures that the symmetric key that is being established,
K_TOKEN, is not exposed to any other entity than the DSKPP server and K_TOKEN, is not exposed to any other entity than the DSKPP server and
the cryptographic module itself. To ensure the keying material is the cryptographic module itself. To ensure the keying material is
adequately protected for all two-pass usage scenarios, the key adequately protected for all two-pass usage scenarios, the key
package format MUST support the following key protection methods, as package format MUST support the following key protection methods, as
defined in Section 3.2.2: defined in Section 3.5.2:
Key Transport This profile is intended for PKI-capable Key Transport This profile is intended for PKI-capable
devices. Key transport is carried out devices. Key transport is carried out
using the public key of the DSKPP client, using the public key of the DSKPP client,
whose private key part resides in the whose private key part resides in the
cryptographic module as the key transport cryptographic module as the key transport
key. key.
Key Wrap This profile is ideal for pre-keyed Key Wrap This profile is ideal for pre-keyed
devices, e.g., SIM cards. Key wrap is devices, e.g., SIM cards. Key wrap is
carried out using a key wrapping key, carried out using a key wrapping key,
skipping to change at page 27, line 41 skipping to change at page 30, line 41
cryptographic module and the DSKPP cryptographic module and the DSKPP
server. server.
Passphrase-Based Key Wrap This profile is a variation of the Key Passphrase-Based Key Wrap This profile is a variation of the Key
Wrap Profile. It is applicable to Wrap Profile. It is applicable to
constrained devices with keypads, e.g., constrained devices with keypads, e.g.,
mobile phones. Key wrap is carried out mobile phones. Key wrap is carried out
using a passphrase-derived key wrapping using a passphrase-derived key wrapping
key, known in advance by both the key, known in advance by both the
cryptographic module and DSKPP server. cryptographic module and DSKPP server.
Key package formats that satisfy this criteria are [PSKC] and Key package formats that satisfy this criteria are [PSKC],
[SKPC-ASN.1]. [SKPC-ASN.1], PKCS#12 [PKCS-12], and PKCS#5 XML [PKCS-5-XML].
3.2.1. Message Flow 3.5.1. 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>
The client's initial <KeyProvClientHello> message is directly The client's initial <KeyProvClientHello> message is directly
followed by a <KeyProvServerFinished> message (unlike the four-pass followed by a <KeyProvServerFinished> message (unlike the four-pass
variant, there is no exchange of the <KeyProvServerHello> and variant, there is no exchange of the <KeyProvServerHello> and
<KeyProvClientNonce> messages). However, as the two-pass variation <KeyProvClientNonce> messages). However, as the two-pass variation
of DSKPP consists of one round trip to the server, the client is of DSKPP consists of one round trip to the server, the client is
still able to include its random nonce, R_C, algorithm preferences still able to include its random nonce, R_C, algorithm preferences
and supported key types in the <KeyProvClientHello> message. Note and supported key types in the <KeyProvClientHello> message. Note
that by including R_C in <KeyProvClientHello>, the DSKPP client is that by including R_C in <KeyProvClientHello>, the DSKPP client is
able to ensure the server is alive before "committing" the key. able to ensure the server is alive before "committing" the key.
The DSKPP server MUST ensure that a generated key is associated with The DSKPP server MUST ensure that a generated key is associated with
the correct cryptographic module, and if applicable, the correct the correct cryptographic module, and if applicable, the correct
user. To ensure that the key K_TOKEN ends up associated with the user. To ensure that the key K_TOKEN ends up associated with the
correct cryptographic module and user, the DSKPP server MAY couple an correct cryptographic module and user, the DSKPP server MAY couple an
initial user authentication to the DSKPP execution as described in initial user authentication to the DSKPP execution as described in
Section 3.4. Section 3.7.
The purpose and content of each message are described below, The purpose and content of each message are described below,
including the optional <KeyProvTrigger>. including the optional <KeyProvTrigger>.
DSKPP Client DSKPP Server DSKPP Client DSKPP Server
------------ ------------ ------------ ------------
[<---] R_TRIGGER, [DeviceID], [<---] R_TRIGGER, [DeviceID],
[KeyID], [URL_S] [KeyID], [URL_S]
The DSKPP server optionally sends a <KeyProvTrigger> message to the The DSKPP server optionally sends a <KeyProvTrigger> message to the
DSKPP client. The trigger message MUST contain a nonce, R_TRIGGER, DSKPP client. The trigger message MUST contain a nonce, R_TRIGGER,
to allow the server to couple the trigger with a later to allow the server to couple the trigger with a later
<KeyProvClientHello> request. <KeyProvTrigger> MAY include a DeviceID <KeyProvClientHello> request. <KeyProvTrigger> MAY include a DeviceID
to allow the client to select the device with which it will to allow the client to select the device with which it will
communicate (for more information about device identification, refer communicate (for more information about device identification, refer
to Section 3.3). In the case of key renewal, <KeyProvTrigger> SHOULD to Section 3.6). In the case of key renewal, <KeyProvTrigger> SHOULD
include the identifier for the key, KeyID, that is being replaced. include the identifier for the key, KeyID, that is being replaced.
Finally, the trigger MAY contain a URL for the DSKPP client to use Finally, the trigger MAY contain a URL for the DSKPP client to use
when contacting the DSKPP server. when contacting the DSKPP server.
DSKPP Client DSKPP Server DSKPP Client DSKPP Server
------------ ------------ ------------ ------------
R_C, SAL, KPML, [AD], R_C, SAL, KPML, [AD],
[R_TRIGGER], [R_TRIGGER],
[DeviceID], [KeyID] ---> [DeviceID], [KeyID] --->
The DSKPP client sends a <KeyProvClientHello> message to the DSKPP The DSKPP client sends a <KeyProvClientHello> message to the DSKPP
server. <KeyProvClientHello> MUST include client nonce, R_C, and a server. <KeyProvClientHello> MUST include client nonce, R_C, and a
Security Attribute List (SAL), identifying which DSKPP versions, Security Attribute List (SAL), identifying which DSKPP versions,
protocol variations (in this case "two-pass"), key package formats, protocol variations (in this case "two-pass"), key package formats,
key types, encryption and MAC algorithms that the client supports. key types, encryption and MAC algorithms that the client supports.
Unlike 4-pass DSKPP, the 2-pass DSKPP client uses the Unlike 4-pass DSKPP, the 2-pass DSKPP client uses the
<KeyProvClientHello> message to declare the list of Key Protection <KeyProvClientHello> message to declare the list of Key Protection
Methods (KPML) it supports, providing required payload information in Method List (KPML) it supports, providing required payload
accordance with Section 3.2.2. Optionally, the message MAY include information in accordance with Section 3.5.2. Optionally, the
client Authentication Data (AD), such as a MAC derived from an message MAY include client Authentication Data (AD), such as a MAC
authentication code and R_C (refer to Section 3.4.1). In addition, derived from an authentication code and R_C (refer to Section 3.7.1).
if a trigger message preceded <KeyProvClientHello>, then it passes In addition, if a trigger message preceded <KeyProvClientHello>, then
the parameters received in <KeyProvTrigger> back to the DSKPP Server. it passes the parameters received in <KeyProvTrigger> back to the
In particular, it MUST include R_TRIGGER so that the DSKPP server can DSKPP Server. In particular, it MUST include R_TRIGGER so that the
associate the client with the trigger message, and SHOULD include DSKPP server can associate the client with the trigger message, and
DeviceID and KeyID. SHOULD include DeviceID and KeyID.
DSKPP Client DSKPP Server DSKPP Client DSKPP Server
------------ ------------ ------------ ------------
<--- KPH, KP, E(K,K_PROV), <--- KPH, KP, E(K,K_PROV),
MAC, AD MAC, AD
If Authentication Data (AD) was received, then the DSKPP server MUST If Authentication Data (AD) was received, then the DSKPP server MUST
authenticate the user in accordance with Section 3.4.1. If authenticate the user in accordance with Section 3.7.1. If
authentication fails, then DSKPP server MUST abort. Otherwise, the authentication fails, then DSKPP server MUST abort. Otherwise, the
DSKPP server generates a key K_PROV from which two keys, K_TOKEN and DSKPP server generates a key K_PROV from which two keys, K_TOKEN and
K_MAC, are derived. (Alternatively, the key K_PROV may have been K_MAC, are derived. (Alternatively, the key K_PROV may have been
pre-generated as described in Section 1.1.1. The DSKPP server pre-generated as described in Section 1.1.1.) The DSKPP server
selects a Key Protection Method (KPM) and applies it to K_PROV in selects a Key Protection Method (KPM) and applies it to K_PROV in
accordance with Section 3.2.2. The server then associates K_TOKEN accordance with Section 3.5.2. The server then associates K_TOKEN
with the cryptographic module in a server-side data store. The with the cryptographic module in a server-side data store. The
intent is that the data store later will be used by some service that intent is that the data store later will be used by some service that
needs to verify or decrypt data produced by the cryptographic module needs to verify or decrypt data produced by the cryptographic module
and the key. and the key.
Once the association has been made, the DSKPP server sends a Once the association has been made, the DSKPP server sends a
confirmation message to the DSKPP client called confirmation message to the DSKPP client called
<KeyProvServerFinished>. For two-pass DSKPP, the confirmation <KeyProvServerFinished>. For two-pass DSKPP, the confirmation
message MUST include a Key Package Header (KPH) that contains the message MUST include a Key Package Header (KPH) that contains the
DSKPP Server's ID and KPM. The ServerID is used for authentication DSKPP Server's ID and KPM. The ServerID is used for authentication
skipping to change at page 30, line 4 skipping to change at page 33, line 4
confirmation message MUST include the Key Package (KP) that holds the confirmation message MUST include the Key Package (KP) that holds the
KeyID, K_PROV from which K_TOKEN and K_MAC are derived, and KeyID, K_PROV from which K_TOKEN and K_MAC are derived, and
additional configuration information. The default symmetric key additional configuration information. The default symmetric key
package format is based on the Portable Symmetric Key Container package format is based on the Portable Symmetric Key Container
(PSKC) defined in [PSKC]. Alternative formats MAY include (PSKC) defined in [PSKC]. Alternative formats MAY include
[SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 XML [PKCS-5-XML]. [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 XML [PKCS-5-XML].
Finally, <KeyProvServerFinished> MUST include two MACs (MAC and AD) Finally, <KeyProvServerFinished> MUST include two MACs (MAC and AD)
whose values are calculated with contribution from the client nonce, whose values are calculated with contribution from the client nonce,
R_C, provided in the <ClientHello> message. The MAC values will R_C, provided in the <ClientHello> message. The MAC values will
allow the cryptographic module to perform key confirmation and server allow the cryptographic module to perform key confirmation and server
authentication before "committing" the key (see Section 3.2.3 for authentication before "committing" the key (see Section 3.5.3 for
more information). more information).
After receiving a <KeyProvServerFinished> message with Status = After receiving a <KeyProvServerFinished> message with Status =
"Success", the DSKPP client MUST verify both MAC values (MAC and AD). "Success", the DSKPP client MUST verify both MAC values (MAC and AD).
The DSKPP client MUST terminate the DSKPP session if either MAC does The DSKPP client MUST terminate the DSKPP protocol run if either MAC
not verify, and MUST, in this case, also delete any nonces, keys, does not verify, and MUST, in this case, also delete any nonces,
and/or secrets associated with the failed run of the protocol. If keys, and/or secrets associated with the failed run of the protocol.
<KeyProvServerFinished> has Status = "Success" and the MACs were If <KeyProvServerFinished> has Status = "Success" and the MACs were
verified, then the DSKPP client MUST extract the key data from the verified, then the DSKPP client MUST extract the key data from the
provided key package, and store data locally. After this operation, provided key package, and store data locally. After this operation,
it MUST NOT be possible to overwrite the key unless knowledge of an it MUST 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.
3.2.2. Key Protection Profiles 3.5.2. Key Protection Profiles
This section introduces three profiles of two-pass DSKPP for key This section introduces three profiles of two-pass DSKPP for key
protection. Further profiles MAY be defined by external entities or protection. Further profiles MAY be defined by external entities or
through the IETF process. through the IETF process.
3.2.2.1. Key Transport Profile 3.5.2.1. Key Transport Profile
This profile establishes a symmetric key, K_TOKEN, in the This profile establishes a symmetric key, K_TOKEN, in the
cryptographic module using key transport and key derivation. Key cryptographic module using key transport and key derivation. Key
transport is carried out using a public key whose private key part transport is carried out using a public key whose private key part
resides in the cryptographic module as the key transport key. A resides in the cryptographic module as the key transport key. A
provisioning master key, K_PROV, MUST be transported from the DSKPP provisioning master key, K_PROV, MUST be transported from the DSKPP
server to the client. From K_PROV, two keys are derived: the server to the client. From K_PROV, two keys are derived: the
symmetric key to be established, K_TOKEN, and a key used to compute symmetric key to be established, K_TOKEN, and a key used to compute
MACs, K_MAC. MACs, K_MAC.
This profile MUST be identified with the following URN: This profile MUST be identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp#transport urn:ietf:params:xml:schema:keyprov:dskpp#transport
In the two-pass version of DSKPP, the client MUST send a payload In the two-pass version of DSKPP, the client MUST send a payload with
associated with this key protection method. This payload MUST be of the Key Transport Profile. This payload MUST be of type <ds:
type <ds:KeyInfoType> ([XMLDSIG]), and only those choices of <ds: KeyInfoType> ([XMLDSIG]), and only those choices of <ds:KeyInfoType>
KeyInfoType> that identify a public key are allowed (i.e., <ds: that identify a public key are allowed (i.e., <ds:KeyName>, <ds:
KeyName>, <ds:KeyValue>, <ds:X509Data>, or <ds:PGPData>). The <ds: KeyValue>, <ds:X509Data>, or <ds:PGPData>). The <ds:X509Certificate>
X509Certificate> option of the <ds:X509Data> alternative is option of the <ds:X509Data> alternative is RECOMMENDED when the
RECOMMENDED when the public key corresponding to the private key on public key corresponding to the private key on the cryptographic
the cryptographic module has been certified. module has been certified.
The server payload associated with this key protection method MUST be The server payload associated with this key protection method MUST be
of type xenc:EncryptedKeyType ([XMLENC]), and only those encryption of type <xenc:EncryptedKeyType> ([XMLENC]), and only those encryption
methods utilizing a public key that are supported by the DSKPP client methods utilizing a public key that are supported by the DSKPP client
(as indicated in the <SupportedEncryptionAlgorithms> element of the (as indicated in the <SupportedEncryptionAlgorithms> element of the
<KeyProvClientHello> message in the case of 2-pass DSKPP) are allowed <KeyProvClientHello> message in the case of 2-pass DSKPP) are allowed
as values for the <xenc:EncryptionMethod>. Further, in the case of as values for the <xenc:EncryptionMethod>. Further, in the case of
2-pass DSKPP, <ds:KeyInfo> MUST contain the same value (i.e. identify 2-pass DSKPP, <ds:KeyInfo> MUST contain the same value (i.e. identify
the same public key) as the <Payload> of the corresponding supported the same public key) as the <Payload> of the corresponding supported
key protection method in the <KeyProvClientHello> message that key protection method in the <KeyProvClientHello> message that
triggered the response. <xenc:CarriedKeyName> MAY be present, but triggered the response. <xenc:CarriedKeyName> MAY be present, but
MUST, when present, contain the same value as the <KeyID> element of MUST, when present, contain the same value as the <KeyID> element of
the <KeyProvServerFinished> message. The Type attribute of the xenc: the <KeyProvServerFinished> message. The Type attribute of the
EncryptedKeyType MUST be present and MUST identify the type of the <xenc:EncryptedKeyType> MUST be present and MUST identify the type of
wrapped key. The type MUST be one of the types supported by the the wrapped key. The type MUST be one of the types supported by the
DSKPP client (as reported in the <SupportedKeyTypes> of the preceding DSKPP client (as reported in the <SupportedKeyTypes> of the preceding
<KeyProvClientHello> message in the case of 2-pass DSKPP). The <KeyProvClientHello> message in the case of 2-pass DSKPP). The
transported key, K_PROV, MUST consist of two parts of equal length. transported key, K_PROV, MUST consist of two parts of equal length.
The first half constitutes K_MAC and the second half constitutes The first half constitutes K_MAC and the second half constitutes
K_TOKEN. The length of K_TOKEN (and hence also the length of K_MAC) K_TOKEN. The length of K_TOKEN (and hence also the length of K_MAC)
is determined by the type of K_TOKEN. is determined by the type of K_TOKEN.
DSKPP servers and cryptographic modules supporting this profile MUST DSKPP servers and cryptographic modules supporting this profile MUST
support the http://www.w3.org/2001/04/xmlenc#rsa-1_5 key wrapping support the http://www.w3.org/2001/04/xmlenc#rsa-1_5 key wrapping
mechanism defined in [XMLENC]. mechanism defined in [XMLENC].
When this profile is used, the MacAlgorithm attribute of the <Mac> When this profile is used, the MacAlgorithm attribute of the <Mac>
element of the <KeyProvServerFinished> message MUST be present and element of the <KeyProvServerFinished> message MUST be present and
MUST identify the selected MAC algorithm. The selected MAC algorithm MUST identify the selected MAC algorithm. The selected MAC algorithm
MUST be one of the MAC algorithms supported by the DSKPP client (as MUST be one of the MAC algorithms supported by the DSKPP client (as
indicated in the <SupportedMacAlgorithms> element of the indicated in the <SupportedMacAlgorithms> element of the
<KeyProvClientHello> message in the case of 2-pass DSKPP). The MAC <KeyProvClientHello> message in the case of 2-pass DSKPP). The MAC
MUST be calculated as described in Section 3.2.3 for two-pass DSKPP. MUST be calculated as described in Section 3.5.3 for two-pass DSKPP.
In addition, DSKPP servers MUST include the AuthenticationDataType In addition, DSKPP servers MUST include the AuthenticationDataType
element in their <KeyProvServerFinished> messages whenever a element in their <KeyProvServerFinished> messages whenever a
successful protocol run will result in an existing K_TOKEN being successful protocol run will result in an existing K_TOKEN being
replaced. replaced.
3.2.2.2. Key Wrap Profile 3.5.2.2. Key Wrap Profile
This profile establishes a symmetric key, K_TOKEN, in the This profile establishes a symmetric key, K_TOKEN, in the
cryptographic module through key wrap and key derivation. Key wrap cryptographic module through key wrap and key derivation. Key wrap
is carried out using a symmetric key wrapping key, known in advance is carried out using a symmetric key wrapping key, known in advance
by both the cryptographic module and the DSKPP server. A by both the cryptographic module and the DSKPP server. A
provisioning master key, K_PROV, MUST be transported from the DSKPP provisioning master key, K_PROV, MUST be transported from the DSKPP
server to the client. From K_PROV, two keys are derived: the server to the client. From K_PROV, two keys are derived: the
symmetric key to be established, K_TOKEN, and a key used to compute symmetric key to be established, K_TOKEN, and a key used to compute
MACs, K_MAC. MACs, K_MAC.
This profile MUST be identified with the following URI: This profile MUST be identified with the following URI:
urn:ietf:params:xml:schema:keyprov:dskpp#wrap urn:ietf:params:xml:schema:keyprov:dskpp#wrap
In the 2-pass version of DSKPP, the client MUST send a payload In the 2-pass version of DSKPP, the client MUST send a payload with
associated with this key protection method. This payload MUST be of the Key Wrap Profile. This payload MUST be of type <ds:KeyInfoType>
type <ds:KeyInfoType> ([XMLDSIG]), and only those choices of <ds: ([XMLDSIG]), and only those choices of <ds:KeyInfoType> that identify
KeyInfoType> that identify a symmetric key are allowed (i.e., <ds: a symmetric key are allowed (i.e., <ds:KeyName> and <ds:KeyValue>).
KeyName> and <ds:KeyValue>). The <ds:KeyName> alternative is The <ds:KeyName> alternative is RECOMMENDED.
RECOMMENDED.
The server payload associated with this key protection method MUST be The server payload associated with this key protection method MUST be
of type xenc:EncryptedKeyType ([XMLENC]), and only those encryption of type <xenc:EncryptedKeyType> ([XMLENC]), and only those encryption
methods utilizing a symmetric key that are supported by the DSKPP methods utilizing a symmetric key that are supported by the DSKPP
client (as indicated in the <SupportedEncryptionAlgorithms> element client (as indicated in the <SupportedEncryptionAlgorithms> element
of the <KeyProvClientHello> message in the case of 2-pass DSKPP) are of the <KeyProvClientHello> message in the case of 2-pass DSKPP) are
allowed as values for the <xenc:EncryptionMethod>. Further, in the allowed as values for the <xenc:EncryptionMethod>. Further, in the
case of 2-pass DSKPP, <ds:KeyInfo> MUST contain the same value (i.e. case of 2-pass DSKPP, <ds:KeyInfo> MUST contain the same value (i.e.
identify the same symmetric key) as the <Payload> of the identify the same symmetric key) as the <Payload> of the
corresponding supported key protection method in the corresponding supported key protection method in the
<KeyProvClientHello> message that triggered the response. <xenc: <KeyProvClientHello> message that triggered the response. <xenc:
CarriedKeyName> MAY be present, and MUST, when present, contain the CarriedKeyName> MAY be present, and MUST, when present, contain the
same value as the <KeyID> element of the <KeyProvServerFinished> same value as the <KeyID> element of the <KeyProvServerFinished>
message. The Type attribute of the xenc:EncryptedKeyType MUST be message. The Type attribute of the <xenc:EncryptedKeyType> MUST be
present and MUST identify the type of the wrapped key. The type MUST present and MUST identify the type of the wrapped key. The type MUST
be one of the types supported by the DSKPP client (as reported in the be one of the types supported by the DSKPP client (as reported in the
<SupportedKeyTypes> of the preceding <KeyProvClientHello> message in <SupportedKeyTypes> of the preceding <KeyProvClientHello> message in
the case of 2-pass DSKPP). The wrapped key, K_PROV, MUST consist of the case of 2-pass DSKPP). The wrapped key, K_PROV, MUST consist of
two parts of equal length. The first half constitutes K_MAC and the two parts of equal length. The first half constitutes K_MAC and the
second half constitutes K_TOKEN. The length of K_TOKEN (and hence second half constitutes K_TOKEN. The length of K_TOKEN (and hence
also the length of K_MAC) is determined by the type of K_TOKEN. also the length of K_MAC) is determined by the type of K_TOKEN.
DSKPP servers and cryptographic modules supporting this profile MUST DSKPP servers and cryptographic modules supporting this profile MUST
support the http://www.w3.org/2001/04/xmlenc#kw-aes128 key wrapping support the http://www.w3.org/2001/04/xmlenc#kw-aes128 key wrapping
mechanism defined in [XMLENC]. mechanism defined in [XMLENC].
When this profile is used, the MacAlgorithm attribute of the <Mac> When this profile is used, the MacAlgorithm attribute of the <Mac>
element of the <KeyProvServerFinished> message MUST be present and element of the <KeyProvServerFinished> message MUST be present and
MUST identify the selected MAC algorithm. The selected MAC algorithm MUST identify the selected MAC algorithm. The selected MAC algorithm
MUST be one of the MAC algorithms supported by the DSKPP client (as MUST be one of the MAC algorithms supported by the DSKPP client (as
indicated in the <SupportedMacAlgorithms> element of the indicated in the <SupportedMacAlgorithms> element of the
<KeyProvClientHello> message in the case of 2-pass DSKPP). The MAC <KeyProvClientHello> message in the case of 2-pass DSKPP). The MAC
MUST be calculated as described in Section 3.2.3. MUST be calculated as described in Section 3.5.3.
In addition, DSKPP servers MUST include the AuthenticationDataType In addition, DSKPP servers MUST include the AuthenticationDataType
element in their <KeyProvServerFinished> messages whenever a element in their <KeyProvServerFinished> messages whenever a
successful protocol run will result in an existing K_TOKEN being successful protocol run will result in an existing K_TOKEN being
replaced. replaced.
3.2.2.3. Passphrase-Based Key Wrap Profile 3.5.2.3. Passphrase-Based Key Wrap Profile
This profile is a variation of the key wrap profile. It establishes This profile is a variation of the key wrap profile. It establishes
a symmetric key, K_TOKEN, in the cryptographic module through key a symmetric key, K_TOKEN, in the cryptographic module through key
wrap and key derivation. Key wrap is carried out using a passphrase- wrap and key derivation. Key wrap is carried out using a passphrase-
derived key wrapping key. The passphrase is known in advance by both derived key wrapping key. The passphrase is known in advance by both
the user of the device and the DSKPP server. To preserve the the user of the device and the DSKPP server. To preserve the
property of not exposing K_TOKEN to any other entity than the DSKPP property of not exposing K_TOKEN to any other entity than the DSKPP
server and the cryptographic module itself, the method SHOULD be server and the cryptographic module itself, the method SHOULD be
employed only when the device contains facilities (e.g. a keypad) for employed only when the device contains facilities (e.g. a keypad) for
direct entry of the passphrase. A provisioning master key, K_PROV, direct entry of the passphrase. A provisioning master key, K_PROV,
MUST be transported from the DSKPP server to the client. From MUST be transported from the DSKPP server to the client. From
K_PROV, two keys are derived: the symmetric key to be established, K_PROV, two keys are derived: the symmetric key to be established,
K_TOKEN, and a key used to compute MACs, K_MAC. K_TOKEN, and a key used to compute MACs, K_MAC.
This profile MUST be identified with the following URI: This profile MUST be identified with the following URI:
urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap
In the 2-pass version of DSKPP, the client MUST send a payload In the 2-pass version of DSKPP, the client MUST send a payload with
associated with this key protection method. This payload MUST be of the Passphrase-Based Key Wrap Profile. This payload MUST be of type
type <ds:KeyInfoType> ([XMLDSIG]). The <ds:KeyName> option MUST be <ds:KeyInfoType> ([XMLDSIG]). The <ds:KeyName> option MUST be used
used and the key name MUST identify the passphrase that will be used and the key name MUST identify the passphrase that will be used by
by the server to generate the key wrapping key. As an example, the the server to generate the key wrapping key. As an example, the
identifier could be a user identifier or a registration identifier identifier could be a user identifier or a registration identifier
issued by the server to the user during a session preceding the DSKPP issued by the server to the user during a session preceding the DSKPP
protocol run. protocol run.
The server payload associated with this key protection method MUST be The server payload associated with this key protection method MUST be
of type xenc:EncryptedKeyType ([XMLENC]), and only those encryption of type <xenc:EncryptedKeyType> ([XMLENC]), and only those encryption
methods utilizing a passphrase to derive the key wrapping key that methods utilizing a passphrase to derive the key wrapping key that
are supported by the DSKPP client (as indicated in the are supported by the DSKPP client (as indicated in the
<SupportedEncryptionAlgorithms> element of the <KeyProvClientHello> <SupportedEncryptionAlgorithms> element of the <KeyProvClientHello>
message in the case of 2-pass DSKPP) are allowed as values for the message in the case of 2-pass DSKPP) are allowed as values for the
<xenc:EncryptionMethod>. Further, in the case of 2-pass DSKPP, <ds: <xenc:EncryptionMethod>. Further, in the case of 2-pass DSKPP, <ds:
KeyInfo> MUST contain the same value (i.e. identify the same KeyInfo> MUST contain the same value (i.e. identify the same
passphrase) as the <Payload> of the corresponding supported key passphrase) as the <Payload> of the corresponding supported key
protection method in the <KeyProvClientHello> message that triggered protection method in the <KeyProvClientHello> message that triggered
the response. <xenc:CarriedKeyName> MAY be present, and MUST, when the response. <xenc:CarriedKeyName> MAY be present, and MUST, when
present, contain the same value as the <KeyID> element of the present, contain the same value as the <KeyID> element of the
<KeyProvServerFinished> message. The Type attribute of the xenc: <KeyProvServerFinished> message. The Type attribute of the <xenc:
EncryptedKeyType MUST be present and MUST identify the type of the EncryptedKeyType> MUST be present and MUST identify the type of the
wrapped key. The type MUST be one of the types supported by the wrapped key. The type MUST be one of the types supported by the
DSKPP client (as reported in the <SupportedKeyTypes> of the preceding DSKPP client (as reported in the <SupportedKeyTypes> of the preceding
<KeyProvClientHello> message in the case of 2-pass DSKPP). The <KeyProvClientHello> message in the case of 2-pass DSKPP). The
wrapped key, K_PROV, MUST consist of two parts of equal length. The wrapped key, K_PROV, MUST consist of two parts of equal length. The
first half constitutes K_MAC and the second half constitutes K_TOKEN. first half constitutes K_MAC and the second half constitutes 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. determined by the type of K_TOKEN.
DSKPP servers and cryptographic modules supporting this profile MUST DSKPP servers and cryptographic modules supporting this profile MUST
support the PBES2 password based encryption scheme defined in support the PBES2 password based encryption scheme defined in
skipping to change at page 34, line 21 skipping to change at page 37, line 17
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 in http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 in
[PKCS-5-XML]), and the http://www.w3.org/2001/04/xmlenc#kw-aes128 key [PKCS-5-XML]), and the http://www.w3.org/2001/04/xmlenc#kw-aes128 key
wrapping mechanism defined in [XMLENC]. wrapping mechanism defined in [XMLENC].
When this profile is used, the MacAlgorithm attribute of the <Mac> When this profile is used, the MacAlgorithm attribute of the <Mac>
element of the <KeyProvServerFinished> message MUST be present and element of the <KeyProvServerFinished> message MUST be present and
MUST identify the selected MAC algorithm. The selected MAC algorithm MUST identify the selected MAC algorithm. The selected MAC algorithm
MUST be one of the MAC algorithms supported by the DSKPP client (as MUST be one of the MAC algorithms supported by the DSKPP client (as
indicated in the <SupportedMacAlgorithms> element of the indicated in the <SupportedMacAlgorithms> element of the
<KeyProvClientHello> message in the case of 2-pass DSKPP). The MAC <KeyProvClientHello> message in the case of 2-pass DSKPP). The MAC
MUST be calculated as described in Section 3.2.3. MUST be calculated as described in Section 3.5.3.
In addition, DSKPP servers MUST include the AuthenticationDataType In addition, DSKPP servers MUST include the AuthenticationDataType
element in their <KeyProvServerFinished> messages whenever a element in their <KeyProvServerFinished> messages whenever a
successful protocol run will result in an existing K_TOKEN being successful protocol run will result in an existing K_TOKEN being
replaced. replaced.
3.2.3. MAC Calculations 3.5.3. MAC Calculations
3.2.3.1. Key Confirmation 3.5.3.1. Key Confirmation
The MAC value in the <KeyProvServerFinished> message MUST be The MAC value in the <KeyProvServerFinished> message MUST be
calculated as follows: calculated as follows:
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 || ServerID, MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash || ServerID,
dsLen) dsLen)
skipping to change at page 35, line 9 skipping to change at page 38, line 5
MAC The MAC MUST be calculated using the already established MAC The MAC MUST be calculated using the already established
MAC algorithm and MUST be computed on the (ASCII) string MAC algorithm and MUST be computed on the (ASCII) string
"MAC 1 computation", msg_hash, and ServerID using the "MAC 1 computation", msg_hash, and ServerID using the
existing the MAC key K_MAC. existing the MAC key K_MAC.
K_MAC The key, along with K_TOKEN, that is derived from K_PROV K_MAC The key, along with K_TOKEN, that is derived from K_PROV
which the DSKPP server MUST provide to the cryptographic which the DSKPP server MUST provide to the cryptographic
module. module.
msg_hash The message hash, defined in Section 3.1.4.3, of messages msg_hash The message hash, defined in Section 3.4.4.3, of messages
msg_1, ..., msg_n. msg_1, ..., msg_n.
ServerID The identifier that the DSKPP server MUST include in the ServerID The identifier that the DSKPP server MUST include in the
<KeyPackage> element of <KeyProvServerFinished>. <KeyPackage> element of <KeyProvServerFinished>.
If DSKPP-PRF (defined in Section 3.5) is used as the MAC algorithm, If DSKPP-PRF (defined in Section 3.3.1) is used as the MAC algorithm,
then the input parameter s MUST consist of the concatenation of the then the input parameter s MUST consist of the concatenation of the
(ASCII) string "MAC 1 computation", msg_hash, and ServerID, and the (ASCII) string "MAC 1 computation", msg_hash, and ServerID, and the
parameter dsLen MUST be set to the length of msg_hash. parameter dsLen MUST be set to the length of msg_hash.
3.2.3.2. Server Authentication in the Case of Key Renewal 3.5.3.2. Server Authentication in the Case of Key Renewal
A second MAC MUST be present in the <KeyProvServerFinished> message A second MAC MUST be present in the <KeyProvServerFinished> message
as proof that the DSKPP server is authorized to replace a key on the as proof that the DSKPP server is authorized to replace a key on the
cryptographic module. In 2-pass DSKPP, servers provide the second cryptographic module. In 2-pass DSKPP, servers provide the second
MAC in the AuthenticationDataType element of <KeyProvServerFinished>. MAC in the AuthenticationDataType element of <KeyProvServerFinished>.
The MAC value in the AuthenticationDataType element MUST be computed The MAC value in the AuthenticationDataType element MUST be computed
on the (ASCII) string "MAC 2 computation", the server identifier on the (ASCII) string "MAC 2 computation", the server identifier
ServerID, and R, using a pre-existing MAC key K_MAC' (the MAC key ServerID, and R, using a pre-existing MAC key K_MAC' (the MAC key
that existed before this protocol run). Note that the implementation that existed before this protocol run). Note that the implementation
may specify K_MAC' to be the value of the K_TOKEN that is being may specify K_MAC' to be the value of the K_TOKEN that is being
skipping to change at page 35, line 45 skipping to change at page 38, line 41
computation" ServerID, and R. The parameter dsLen MUST be set to at computation" ServerID, and R. The parameter dsLen MUST be set to at
least 16 (i.e. the length of the MAC MUST be at least 16 octets): least 16 (i.e. the length of the MAC MUST be at least 16 octets):
dsLen >= 16 dsLen >= 16
MAC = DSKPP-PRF (K_MAC', "MAC 2 computation" || ServerID || R, dsLen) MAC = DSKPP-PRF (K_MAC', "MAC 2 computation" || ServerID || R, dsLen)
The MAC algorithm MUST be the same as the algorithm used for key The MAC algorithm MUST be the same as the algorithm used for key
confirmation purposes. confirmation purposes.
3.3. Device Identification 3.6. Device Identification
The DSKPP server MAY be pre-configured with a unique device The DSKPP server MAY be pre-configured with a unique device
identifier corresponding to a particular cryptographic module. The identifier corresponding to a particular cryptographic module. The
DSKPP server MAY then include this identifier in the DSKPP DSKPP server MAY then include this identifier in the DSKPP
initialization trigger, in which case the DSKPP client MUST include initialization trigger, in which case the DSKPP client MUST include
it in its message(s) to the DSKPP server for authentication. Note it in its message(s) to the DSKPP server for authentication. Note
that it is also legitimate for a DSKPP client to initiate the DSKPP that it is also legitimate for a DSKPP client to initiate the DSKPP
protocol run without having received an initialization message from a protocol run without having received an initialization message from a
server, but in this case any provided device identifier MUST NOT be server, but in this case any provided device identifier MUST NOT be
accepted by the DSKPP server unless the server has access to a unique accepted by the DSKPP server unless the server has access to a unique
key for the identified device and that key will be used in the key for the identified device and that key will be used in the
protocol. protocol.
3.4. User Authentication 3.7. User Authentication
The DSKPP server MUST ensure that a generated key is associated with The DSKPP server MUST ensure that a generated key is associated with
the correct cryptographic module, and if applicable, the correct the correct cryptographic module, and if applicable, the correct
user. If the user has not been authenticated by some out-of-band user. If the user has not been authenticated by some out-of-band
means, then the user SHOULD be authenticated within the DSKPP. When means, then the user SHOULD be authenticated within the DSKPP. When
relying on DSKPP for user authentication, the DSKPP server SHOULD relying on DSKPP for user authentication, the DSKPP server SHOULD
explicitly rely on client-provided Authentication Data (AD) to verify explicitly rely on client-provided Authentication Data (AD) to verify
that a legitimate user is behind the wheel. For a further discussion that a legitimate user is behind the wheel. For a further discussion
of this, and threats related to man-in-the-middle attacks in this of this, and threats related to man-in-the-middle attacks in this
context, see Section 9.6.4. context, see Section 9.6.4.
3.4.1. Authentication Data 3.7.1. Authentication Data
As described in the message flows above (see Section 3.1.1 and As described in the message flows above (see Section 3.4.1 and
Section 3.2.1), the DSKPP client MAY include Authentication Data (AD) Section 3.5.1), the DSKPP client MAY include Authentication Data (AD)
in its request(s). Note that AD MAY be omitted if client certificate in its request(s). Note that AD MAY be omitted if client certificate
authentication has been provided by the transport channel such as authentication has been provided by the transport channel such as
TLS. Nonetheless, when AD is provided, the DSKPP server MUST verify TLS. Nonetheless, when AD is provided, the DSKPP server MUST verify
the data before continuing with the protocol run. the data before continuing with the protocol run.
The data element that holds AD MUST include a Client ID and a value The data element that holds AD MUST include a Client ID and a value
derived from an Authentication Code (AC). The Client ID represents a derived from an Authentication Code (AC). The Client ID represents a
key request made by the user to the Provisioning Server. AC is a key request made by the user to the Provisioning Server. AC is a
one-time use value that is a (potentially low entropy) shared secret one-time use value that is a (potentially low entropy) shared secret
between a user and the Provisioning Server. This secret is made between a user and the Provisioning Server. This secret is made
skipping to change at page 37, line 4 skipping to change at page 39, line 47
hosted on their device. For example, a user runs an application hosted on their device. For example, a user runs an application
that is resident on their device, e.g., a mobile phone. The that is resident on their device, e.g., a mobile phone. The
application cannot proceed without a new symmetric key. The user application cannot proceed without a new symmetric key. The user
is redirected to an issuer's Web site from where the user is redirected to an issuer's Web site from where the user
requests a key. The issuer's Web application processes the requests a key. The issuer's Web application processes the
request, and returns an AC, which then appears on the user's request, and returns an AC, which then appears on the user's
display. The user then invokes a symmetric key-based application display. The user then invokes a symmetric key-based application
hosted on the device, which asks the user to input the AC using a hosted on the device, which asks the user to input the AC using a
keypad. The application invokes the DSKPP client, providing it keypad. The application invokes the DSKPP client, providing it
with the AC. with the AC.
b. The provisioning server may send a trigger message, b. The provisioning server may send a trigger message,
<KeyProvTrigger>, to the DSKPP client, which sets the value of <KeyProvTrigger>, to the DSKPP client, which sets the value of
the trigger nonce, R_TRIGGER, to AC. When this method is used, a the trigger nonce, R_TRIGGER, to AC. When this method is used, a
transport providing privacy and integrity MUST be used to deliver transport providing confidentiality and integrity MUST be used to
the DSKPP initialization trigger from the DSKPP server to the deliver the DSKPP initialization trigger from the DSKPP server to
DSKPP client, e.g., HTTPS. the DSKPP client, e.g., HTTPS.
A description of the AC and how it is used to derive AD is contained A description of the AC and how it is used to derive AD is contained
in the sub-sections below. in the sub-sections below.
3.4.2. Authentication Code Format 3.7.2. 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. See Figure 4 for TLV field layout. depending on implementation. See Figure 7 for TLV field layout.
A 1 byte type field identifies the specific TLV, and a 1 byte length, 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 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 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. 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. These pad bytes are not counted in the length field of the TLV.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value[0] | ...Value[Length-1] | Type | Length | Value[0] | ...Value[Length-1]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TLV Format Figure 7: TLV Format
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 byte) The integer value identifying the type of
information contained in the value field. information contained in the value field.
Length (1 byte) The length, in hexadecimal, of the value Length (1 byte) The length, in hexadecimal, of the value
field to follow. field to follow.
Value (variable length) A variable-length hexadecimal value Value (variable length) A variable-length hexadecimal value
containing the instance-specific containing the instance-specific
information for this TLV. information for this TLV.
Figure 5 summarizes the TLVs defined in this document. Optional TLVs Figure 8 summarizes the TLVs defined in this document. Optional TLVs
are allowed for vendor-specific extensions with the constraint that are allowed for vendor-specific extensions with the constraint that
the high bit MUST be set to indicate a vendor-specific type. Other the high bit MUST be set to indicate a vendor-specific type. Other
TLVs are left for later revisions of this protocol. TLVs are left for later revisions of this 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 | { "3582" } |
+------+------------+-------------+-----------------------------+ +------+------------+-------------+-----------------------------+
| 3 | Checksum | Optional | { 0x5F8D } | | 3 | Checksum | Optional | { 0x5F8D } |
+------+------------+-------------+-----------------------------+ +------+------------+-------------+-----------------------------+
Figure 5: TLV Summary Figure 8: TLV Summary
3.4.2.1. Client ID (MANDATORY) 3.7.2.1. Client ID (MANDATORY)
The Client ID is a mandatory TLV that represents the user's key The Client ID is a mandatory TLV that represents the user's key
request. A summary of the Client ID TLV format is given in Figure 6. request. A summary of the Client ID TLV format is given in Figure 9.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 | Length | clientID ... | | Type = 0x1 | Length | clientID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ClientID TLV Format Figure 9: ClientID TLV Format
clientID is an ASCII string that identifies the key request. The clientID is an ASCII string that identifies the key request. The
clientID MUST be HEX encoded. clientID MUST be HEX encoded.
For example, suppose clientID is set to "AC00000A", the hexadecimal For example, suppose clientID is set to "AC00000A", the hexadecimal
equivalent is 0x4143303030303041, resulting in a TLV of {0x1, 0x8, equivalent is 0x4143303030303041, resulting in a TLV of {0x1, 0x8,
0x4143303030303041}. 0x4143303030303041}.
3.4.2.2. Password (MANDATORY) 3.7.2.2. Password (MANDATORY)
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. A summary of secret known by the user and the Provisioning Server. A summary of
the Password TLV format is given in Figure 7. The fields are the Password TLV format is given in Figure 10. The fields are
transmitted from left to right. transmitted from left to right.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x2 | Length | password ... | | Type = 0x2 | Length | password ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Password TLV Format Figure 10: Password TLV Format
Password is a unique value that SHOULD be a random string to make AC Password is a unique value that SHOULD be a random string to make AC
more difficult to guess. The string MUST be UTF-8 encoded in more difficult to guess. The string MUST be UTF-8 encoded in
accordance with [RFC3629]. accordance with [RFC3629].
For example, suppose password is set to "3582", then the TLV would be For example, suppose password is set to "3582", then the TLV would be
{0x2, 0x4, UTF-8("3582")}. {0x2, 0x4, UTF-8("3582")}.
3.4.2.3. Checksum (OPTIONAL) 3.7.2.3. Checksum (OPTIONAL)
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. A summary of the server and sent to the user as part of the AC. A summary of the
Checksum TLV format is given in Figure 8. The fields are transmitted Checksum TLV format is given in Figure 11. The fields are
from left to right. transmitted from left to right.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 | Length | checksum | | Type = 0x3 | Length | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Checksum TLV Format Figure 11: Checksum TLV Format
If included, the checksum MUST be computed using the CRC16 algorithm If included, the checksum MUST be computed using the CRC16 algorithm
[ISO3309]. When the user enters the AC, the typed password is [ISO3309]. When the user enters the AC, the typed password is
verified with the checksum to ensure it is correctly entered by the verified with the checksum to ensure it is correctly entered by the
user. user.
For example, suppose the Password is set to "3582", then the CRC16 For example, suppose the Password is set to "3582", then the CRC16
calculation would generate a checksum of 0x5F8D, resulting in TLV calculation would generate a checksum of 0x5F8D, resulting in TLV
{0x3, 0x2, 0x5F8D}. {0x3, 0x2, 0x5F8D}.
3.4.3. Authentication Data Calculation 3.7.3. 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.5 for a description of DSKPP-PRF in general and Appendix C Section 3.3.1 for a description of DSKPP-PRF in general and
for a description of DSKPP-PRF-AES): Appendix C 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)
In four-pass DSKPP, the cryptographic module uses R_C, R_S, and URL_S In four-pass DSKPP, the cryptographic module uses R_C, R_S, and URL_S
to calculate the MAC, where URL_S is the URL the DSKPP client uses to calculate the MAC, where URL_S is the URL the DSKPP client uses
when contacting the DSKPP server. In two-pass DSKPP, the when contacting the DSKPP server. In two-pass DSKPP, the
cryptographic module does not have access to R_S, therefore only R_C cryptographic module does not have access to R_S, therefore only R_C
is used in combination with URL_S to produce the MAC. In either is used in combination with URL_S to produce the MAC. In either
case, K_AC MUST be derived from AC>password as follows [PKCS-5]: case, K_AC MUST be derived from AC>password as follows [PKCS-5]:
K_AC = PBKDF2(AC->password, R_C || [K], iter_count, 16) K_AC = PBKDF2(AC->password, R_C || K, iter_count, 16)
K is OPTIONAL only in four-pass where no K_SHARED is used. In all One of the following values for K MUST be used:
other cases one of the following values for K MUST be used:
a. The public key of the DSKPP client, or the public key of the a. In four-pass:
* The public key of the DSKPP server (K_SERVER), or (in the pre-
shared key variant) the pre-shared key between the client and
the server (K_SHARED)
b. In two-pass:
* The public key of the DSKPP client, or the public key of the
device when a device certificate is available device when a device certificate is available
b. The pre-shared key between the client and the server * The pre-shared key between the client and the server
c. A passphrase-derived key (K_SHARED)
* A passphrase-derived key
The iteration count, iter_count, MUST be set to at least 100,000 The iteration count, iter_count, MUST be set to at least 100,000
except for case (b) and (c), above, in which case it MUST be set to except for case (b) and (c), above, in which case it MUST be set to
1. 1.
3.5. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF
3.5.1. Introduction
All of the protocol variations depend on DSKPP-PRF. The general
requirements on DSKPP-PRF are the same as on keyed hash functions: It
MUST take an arbitrary length input, and be one-way and collision-
free (for a definition of these terms, see, e.g., [FAQ]). Further,
the DSKPP-PRF function MUST be capable of generating a variable-
length output, and its output MUST be unpredictable even if other
outputs for the same key are known.
It is assumed that any realization of DSKPP-PRF takes three input
parameters: A secret key k, some combination of variable data, and
the desired length of the output. The combination of variable data
can, without loss of generalization, be considered as a salt value
(see PKCS#5 Version 2.0 [PKCS-5], Section 4), and this
characterization of DSKPP-PRF SHOULD fit all actual PRF algorithms
implemented by cryptographic modules. From the point of view of this
specification, DSKPP-PRF is a "black-box" function that, given the
inputs, generates a pseudorandom value.
Separate specifications MAY define the implementation of DSKPP-PRF
for various types of cryptographic modules. Appendix C contains two
example realizations of DSKPP-PRF.
3.5.2. Declaration
DSKPP-PRF (k, s, dsLen)
Input:
k secret key in octet string format
s octet string of varying length consisting of variable data
distinguishing the particular string being derived
dsLen desired length of the output
Output:
DS pseudorandom string, dsLen-octets long
For the purposes of this document, the secret key k MUST be at least
16 octets long.
4. DSKPP Message Formats 4. DSKPP Message Formats
The message formats from the DSKPP XML schema, found in Section 7, The message formats from the DSKPP XML schema, found in Section 7,
are explained in this section. Examples can be found in Appendix A. are explained in this section. Examples can be found in Appendix A.
The XML format for DSKPP messages has been designed to be extensible. The XML format for DSKPP messages has been designed to be extensible.
However, it is possible that the use of extensions will harm However, it is possible that the use of extensions will harm
interoperability; therefore, any use of extensions SHOULD be interoperability; therefore, any use of extensions SHOULD be
carefully considered. For example, if a particular implementation carefully considered. For example, if a particular implementation
relies on the presence of a proprietary extension, then it may not be relies on the presence of a proprietary extension, then it may not be
able to interoperate with independent implementations that have no able to interoperate with independent implementations that have no
skipping to change at page 44, line 46 skipping to change at page 46, line 46
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
The components of this message have the following meaning: The components of this message have the following meaning:
o Version: (attribute inherited from the AbstractRequestType type) o Version: (attribute inherited from the AbstractRequestType type)
The highest version of this protocol the client supports. Only The highest version of this protocol the client supports. Only
version one ("1.0") is currently specified. version one ("1.0") is currently specified.
o <DeviceIdentifierData>: An identifier for the cryptographic module o <DeviceIdentifierData>: An identifier for the cryptographic module
as defined in Section 3.4 above. The identifier MUST only be as defined in Section 3.7 above. The identifier MUST only be
present if such shared secrets exist or if the identifier was present if such shared secrets exist or if the identifier was
provided by the server in a <KeyProvTrigger> element (see provided by the server in a <KeyProvTrigger> element (see
Section 6.2.7). In the latter case, it MUST have the same value Section 6.2.7). In the latter case, it MUST have the same value
as the identifier provided in that element. as the identifier provided in that element.
o <KeyID>: An identifier for the key that will be overwritten if the o <KeyID>: An identifier for the key that will be overwritten if the
protocol run is successful. The identifier MUST only be present protocol run is successful. The identifier MUST only be present
if the key exists or if the identifier was provided by the server if the key exists or if the identifier was provided by the server
in a <KeyProvTrigger> element, in which case, it MUST have the in a <KeyProvTrigger> element, in which case, it MUST have the
same value as the identifier provided in that element (see a same value as the identifier provided in that element (see a
skipping to change at page 45, line 36 skipping to change at page 47, line 36
o <SupportedEncryptionAlgorithms>: A sequence of container elements o <SupportedEncryptionAlgorithms>: A sequence of container elements
that in turn contain URLs indicating the encryption algorithms that in turn contain URLs indicating the encryption algorithms
supported by the cryptographic module for the purposes of DSKPP. supported by the cryptographic module for the purposes of DSKPP.
The DSKPP client MAY indicate the same algorithm both as a The DSKPP client MAY indicate the same algorithm both as a
supported key type and as an encryption algorithm. supported key type and as an encryption algorithm.
o <SupportedMacAlgorithms>: A sequence of container elements that in o <SupportedMacAlgorithms>: A sequence of container elements that in
turn contain URLs indicating the MAC algorithms supported by the turn contain URLs indicating the MAC algorithms supported by the
cryptographic module for the purposes of DSKPP. The DSKPP client cryptographic module for the purposes of DSKPP. The DSKPP client
MAY indicate the same algorithm both as an encryption algorithm MAY indicate the same algorithm both as an encryption algorithm
and as a MAC algorithm (e.g., and as a MAC algorithm (e.g.,
http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes, which is defined http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128, which is
in Appendix C). defined in Appendix C).
o <SupportedProtocolVariants>: This OPTIONAL element is used by the o <SupportedProtocolVariants>: This OPTIONAL element is used by the
DSKPP client to indicate support for four-pass or two-pass DSKPP. DSKPP client to indicate support for four-pass or two-pass DSKPP.
If two-pass support is specified, then <KeyProvClientNonce> MUST If two-pass support is specified, then <KeyProvClientNonce> MUST
be set to nonce R in the <KeyProvClientHello> message unless be set to nonce R in the <KeyProvClientHello> message unless
<TriggerNonce> is already present. <TriggerNonce> is already present.
o <SupportedKeyPackages>: This OPTIONAL element is a sequence of o <SupportedKeyPackages>: This OPTIONAL element is a sequence of
container elements that in turn contain URLs indicating the key container elements that in turn contain URLs indicating the key
package formats supported by the DSKPP client. If this element is package formats supported by the DSKPP client. If this element is
not provided, then the DSKPP server MUST proceed with not provided, then the DSKPP server MUST proceed with
"http://www.ietf.org/keyprov/pskc#KeyContainer" (see [PSKC]). "http://www.ietf.org/keyprov/pskc#KeyContainer" (see [PSKC]).
o <AuthenticationData>: This OPTIONAL element contains data that the o <AuthenticationData>: This OPTIONAL element contains data that the
DSKPP client uses to authenticate the user or device to the DSKPP DSKPP client uses to authenticate the user or device to the DSKPP
server. The element is set as specified in Section 3.4. server. The element is set as specified in Section 3.7.
o <Extensions>: A sequence of extensions. One extension is defined o <Extensions>: A sequence of OPTIONAL extensions. One extension is
for this message in this version of DSKPP: the ClientInfoType (see defined for this message in this version of DSKPP: the
Section 5). ClientInfoType (see Section 5).
Some of the core elements of the message are described below. Some of the core elements of the message are described below.
4.3.1. The DeviceIdentifierDataType Type 4.3.1. The DeviceIdentifierDataType Type
The DeviceIdentifierDataType type is used to uniquely identify the The DeviceIdentifierDataType type is used to uniquely identify the
device that houses the cryptographic module, e.g., a mobile phone. device that houses the cryptographic module, e.g., a mobile phone.
The device identifier allows the DSKPP server to find, e.g., a pre- The device identifier allows the DSKPP server to find, e.g., a pre-
shared key transport key for 2-pass DSKPP and/or the correct shared shared key transport key for 2-pass DSKPP and/or the correct shared
secret for MAC'ing purposes. The default DeviceIdentifierDataType is secret for MAC'ing purposes. The default DeviceIdentifierDataType is
skipping to change at page 46, line 36 skipping to change at page 48, line 36
4.3.2. The ProtocolVariantsType Type 4.3.2. The ProtocolVariantsType Type
The ProtocolVariantsType is a complex type that is a sequence of The ProtocolVariantsType is a complex type that is a sequence of
elements, each describing a DSKPP protocol variant. The DSKPP client elements, each describing a DSKPP protocol variant. The DSKPP client
MAY use the ProtocolVariantsType to identify which protocol variants MAY use the ProtocolVariantsType to identify which protocol variants
it supports, i.e., by providing <SupportProtocolVariants> within a it supports, i.e., by providing <SupportProtocolVariants> within a
<KeyProvClientHello> message. <KeyProvClientHello> message.
Selecting the <FourPass> element signals client support for 4-pass Selecting the <FourPass> element signals client support for 4-pass
DSKPP as described in Section 3.1.1. DSKPP as described in Section 3.4.1.
Selecting the <TwoPass> element signals client support for the 2-pass Selecting the <TwoPass> element signals client support for the 2-pass
version of DSKPP as described in Section 3.2.1. The <TwoPass> version of DSKPP as described in Section 3.5.1. The <TwoPass>
element is of type KeyProtectionDataType, which carries information element is of type KeyProtectionDataType, which carries information
that informs the server of supported two-pass key protection methods that informs the server of supported two-pass key protection methods
as described in Section 3.2.2, and provides OPTIONAL payload data to as described in Section 3.5.2, and provides OPTIONAL payload data to
the DSKPP server. The payload is sent in an opportunistic fashion, the DSKPP server. The payload is sent in an opportunistic fashion,
and MAY be discarded by the DSKPP server if the server does not and MAY be discarded by the DSKPP server if the server does not
support the key protection method with which the payload is support the key protection method with which the payload is
associated. associated.
If the DSKPP client does not include <SupportedProtocolVariants> in If the DSKPP client does not include <SupportedProtocolVariants> in
the <KeyProvClientHello> message, then the DSKPP server MUST proceed the <KeyProvClientHello> message, then the DSKPP server MUST proceed
by using the 4-pass DSKPP variant. If the DSKPP server does not by using the 4-pass DSKPP variant. If the DSKPP server does not
support 4-pass DSKPP, then the server MUST use the two-pass protocol support 4-pass DSKPP, then the server MUST use the two-pass protocol
variant. If it cannot support the two-pass protocol variant, then variant. If it cannot support the two-pass protocol variant, then
skipping to change at page 48, line 20 skipping to change at page 50, line 20
</xs:complexType> </xs:complexType>
<xs:simpleType name="KeyPackageFormatType"> <xs:simpleType name="KeyPackageFormatType">
<xs:restriction base="xs:anyURI" /> <xs:restriction base="xs:anyURI" />
</xs:simpleType> </xs:simpleType>
4.3.4. The AuthenticationDataType Type 4.3.4. The AuthenticationDataType Type
The OPTIONAL AuthenticationDataType type is used by DSKPP clients to The OPTIONAL AuthenticationDataType type is used by DSKPP clients to
carry authentication values in DSKPP messages as described in carry authentication values in DSKPP messages as described in
Section 3.4. Section 3.7.
<xs:complexType name="AuthenticationDataType"> <xs:complexType name="AuthenticationDataType">
<xs:sequence> <xs:sequence>
<xs:element name="ClientID" <xs:element name="ClientID"
type="dskpp:IdentifierType" /> type="dskpp:IdentifierType" />
<xs:element name="AuthenticationCodeMac" <xs:element name="AuthenticationCodeMac"
type="dskpp:AuthenticationMacType" /> type="dskpp:AuthenticationMacType" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
skipping to change at page 48, line 47 skipping to change at page 50, line 47
</xs:complexType> </xs:complexType>
The elements of the AuthenticationDataType type have the following The elements of the AuthenticationDataType type have the following
meaning: meaning:
o <ClientID>: A requester's identifier of maximum length 128. The o <ClientID>: A requester's identifier of maximum length 128. The
value MAY be a user ID, a device ID, or a keyID associated with value MAY be a user ID, a device ID, or a keyID associated with
the requester's authentication value. the requester's authentication value.
o <AuthenticationCodeMac>: An authentication MAC and additional o <AuthenticationCodeMac>: An authentication MAC and additional
information (e.g., MAC algorithm), derived as described in information (e.g., MAC algorithm), derived as described in
Section 3.4.3. Section 3.7.3.
4.4. Components of the <KeyProvServerHello> Response (Used Only in 4.4. Components of the <KeyProvServerHello> Response (Used Only in
Four-Pass DSKPP) Four-Pass DSKPP)
In a four-pass exchange, this message is the first message sent from In a four-pass exchange, this message is the first message sent from
the DSKPP server to the DSKPP client (assuming a trigger message has the DSKPP server to the DSKPP client (assuming a trigger message has
not been sent to initiate the protocol, in which case, this message not been sent to initiate the protocol, in which case, this message
is the second message sent from the DSKPP server to the DSKPP is the second message sent from the DSKPP server to the DSKPP
client). It is sent upon reception of a <KeyProvClientHello> client). It is sent upon reception of a <KeyProvClientHello>
message. message.
skipping to change at page 50, line 30 skipping to change at page 52, line 30
replacement of an existing symmetric key with a new one (i.e., if replacement of an existing symmetric key with a new one (i.e., if
the <KeyID> element was present in the <ClientHello message). In the <KeyID> element was present in the <ClientHello message). In
this case, the DSKPP server MUST prove to the cryptographic module this case, the DSKPP server MUST prove to the cryptographic module
that it is authorized to replace it. that it is authorized to replace it.
4.5. Components of a <KeyProvClientNonce> Request (Used Only in Four- 4.5. Components of a <KeyProvClientNonce> Request (Used Only in Four-
Pass DSKPP) Pass DSKPP)
In a four-pass DSKPP exchange, this message contains the nonce R_C In a four-pass DSKPP exchange, this message contains the nonce R_C
that was chosen by the cryptographic module, and encrypted by the that was chosen by the cryptographic module, and encrypted by the
negotiated encryption key and encryption algorithm negotiated encryption key and encryption algorithm.
<xs:element name="KeyProvClientNonce" <xs:element name="KeyProvClientNonce"
type="dskpp:KeyProvClientNoncePDU"> type="dskpp:KeyProvClientNoncePDU">
</xs:element> </xs:element>
<xs:complexType name="KeyProvClientNoncePDU"> <xs:complexType name="KeyProvClientNoncePDU">
<xs:complexContent mixed="false"> <xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractRequestType"> <xs:extension base="dskpp:AbstractRequestType">
<xs:sequence> <xs:sequence>
<xs:element name="EncryptedNonce" type="xs:base64Binary" /> <xs:element name="EncryptedNonce" type="xs:base64Binary" />
<xs:element minOccurs="0" name="AuthenticationData" <xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationDataType" /> type="dskpp:AuthenticationDataType" />
skipping to change at page 51, line 34 skipping to change at page 53, line 35
o Version: (inherited from the AbstractRequestType type) MUST be the o Version: (inherited from the AbstractRequestType type) MUST be the
same version as in the <KeyProvServerHello> message. same version as in the <KeyProvServerHello> message.
o <SessionID>: (attribute inherited from the AbstractResponseType o <SessionID>: (attribute inherited from the AbstractResponseType
type) MUST have the same value as the SessionID attribute in the type) MUST have the same value as the SessionID attribute in the
received <KeyProvServerHello> message. SessionID has maximum received <KeyProvServerHello> message. SessionID has maximum
length of 128. length of 128.
o <EncryptedNonce>: The nonce generated and encrypted by the o <EncryptedNonce>: The nonce generated and encrypted by the
cryptographic module. The encryption MUST be made using the cryptographic module. The encryption MUST be made using the
selected encryption algorithm and identified key, and as specified selected encryption algorithm and identified key, and as specified
in Section 3.5. in Section 3.3.1.
o <AuthenticationData>: IThe authentication data value MUST be set o <AuthenticationData>: The authentication data value MUST be set as
as specified in Section 3.4 and Section 4.3.4. specified in Section 3.7 and Section 4.3.4.
o <Extensions>: A list of extensions. Two extensions are defined o <Extensions>: A list of OPTIONAL extensions. Two extensions are
for this message in this version of DSKPP: the ClientInfoType and defined for this message in this version of DSKPP: the
the ServerInfoType (see Section 5) ClientInfoType and the ServerInfoType (see Section 5).
4.6. Components of a <KeyProvServerFinished> Response 4.6. Components of a <KeyProvServerFinished> Response
This message is the last message of the DSKPP protocol run. In a This message is the last message of the DSKPP protocol run. In a
4-pass exchange, the DSKPP server sends this message in response to a 4-pass exchange, the DSKPP server sends this message in response to a
<KeyProvClientNonce> message, whereas in a 2-pass exchange, the DSKPP <KeyProvClientNonce> message, whereas in a 2-pass exchange, the DSKPP
server sends this message in response to a <KeyProvClientHello> server sends this message in response to a <KeyProvClientHello>
message. message.
<xs:element name="KeyProvServerFinished" <xs:element name="KeyProvServerFinished"
skipping to change at page 52, line 41 skipping to change at page 54, line 41
o Status: (inherited from the AbstractResponseType type) Return code o Status: (inherited from the AbstractResponseType type) Return code
for the <KeyProvServerFinished> message. If Status is not for the <KeyProvServerFinished> message. If Status is not
"Success", only the Status, SessionID, and Version attributes will "Success", only the Status, SessionID, and Version attributes will
be present (the presence of the SessionID attribute is dependent be present (the presence of the SessionID attribute is dependent
on the type of reported error); otherwise, all the other elements on the type of reported error); otherwise, all the other elements
MUST be present as well. In this latter case, the MUST be present as well. In this latter case, the
<KeyProvServerFinished> message can be seen as a "Commit" message, <KeyProvServerFinished> message can be seen as a "Commit" message,
instructing the cryptographic module to store the generated key instructing the cryptographic module to store the generated key
and associate the given key identifier with this key. and associate the given key identifier with this key.
o <KeyPackage>: The key package containing keying material in o <KeyPackage>: The key package containing keying material in
accordance with four- and two-pass DSKPP usage (see Section 3.1 accordance with four- and two-pass DSKPP usage (see Section 3.4
and Section 3.2). The default package format is based on the and Section 3.5). The default package format is based on the
KeyContainerType type from PSKC, as defined in [PSKC]. KeyContainerType type from PSKC, as defined in [PSKC].
o <Extensions>: A list of extensions chosen by the DSKPP server. o <Extensions>: A list of extensions chosen by the DSKPP server.
For this message, this version of DSKPP defines one extension, the For this message, this version of DSKPP defines one extension, the
ClientInfoType (see Section 5). ClientInfoType (see Section 5).
o <Mac>: To avoid a false "Commit" message causing the cryptographic o <Mac>: To avoid a false "Commit" message causing the cryptographic
module to end up in an initialized state for which the server does module to end up in an initialized state for which the server does
not know the stored key, <KeyProvServerFinished> messages MUST not know the stored key, <KeyProvServerFinished> messages MUST
always be authenticated with a MAC. The MAC MUST be made using always be authenticated with a MAC. The MAC MUST be made using
the already established MAC algorithm. the already established MAC algorithm.
o <AuthenticationData>: This OPTIONAL element contains a MAC value o <AuthenticationData>: This OPTIONAL element contains a MAC value
that the DSKPP server provides in a two-pass message exchange as that the DSKPP server provides in a two-pass message exchange as
proof that the server is authorized to replace a key on the proof that the server is authorized to replace a key on the
cryptographic module. The MAC MUST be calculated as specified in cryptographic module. The MAC MUST be calculated as specified in
Section 3.2.3.2. Section 3.5.3.2.
4.7. The StatusCode Type 4.7. The StatusCode Type
The StatusCode type enumerates all possible return codes: The StatusCode type enumerates all possible return codes:
<xs:simpleType name="StatusCode"> <xs:simpleType name="StatusCode">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="Continue" /> <xs:enumeration value="Continue" />
<xs:enumeration value="Success" /> <xs:enumeration value="Success" />
<xs:enumeration value="Abort" /> <xs:enumeration value="Abort" />
skipping to change at page 53, line 40 skipping to change at page 55, line 40
<xs:enumeration value="AuthenticationDataMissing" /> <xs:enumeration value="AuthenticationDataMissing" />
<xs:enumeration value="AuthenticationDataInvalid" /> <xs:enumeration value="AuthenticationDataInvalid" />
<xs:enumeration value="InitializationFailed" /> <xs:enumeration value="InitializationFailed" />
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
Upon transmission or receipt of a message for which the Status Upon transmission or receipt of a message for which the Status
attribute's value is not "Success" or "Continue", the default attribute's value is not "Success" or "Continue", the default
behavior, unless explicitly stated otherwise below, is that both the behavior, unless explicitly stated otherwise below, is that both the
DSKPP server and the DSKPP client MUST immediately terminate the DSKPP server and the DSKPP client MUST immediately terminate the
DSKPP session. DSKPP servers and DSKPP clients MUST delete any DSKPP protocol run. DSKPP servers and DSKPP clients MUST delete any
secret values generated as a result of failed runs of the DSKPP secret values generated as a result of failed runs of the DSKPP
protocol. Session identifiers MAY be retained from successful or protocol. Session identifiers MAY be retained from successful or
failed protocol runs for replay detection purposes, but such retained failed protocol runs for replay detection purposes, but such retained
identifiers MUST NOT be reused for subsequent runs of the protocol. identifiers MUST NOT be reused for subsequent runs of the protocol.
When possible, the DSKPP client SHOULD present an appropriate error When possible, the DSKPP client SHOULD present an appropriate error
message to the user. message to the user.
These status codes are valid in all DSKPP Response messages unless These status codes are valid in all DSKPP Response messages unless
explicitly stated otherwise: explicitly stated otherwise:
skipping to change at page 61, line 50 skipping to change at page 63, line 50
<xs:complexType name="AuthenticationDataType"> <xs:complexType name="AuthenticationDataType">
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
Authentication data contains a MAC. Authentication data contains a MAC.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:sequence> <xs:sequence>
<xs:element name="ClientID" <xs:element name="ClientID"
type="dskpp:IdentifierType" /> type="dskpp:IdentifierType" />
<xs:choice>
<xs:element name="AuthenticationCodeMac" <xs:element name="AuthenticationCodeMac"
type="dskpp:AuthenticationMacType" /> type="dskpp:AuthenticationMacType"
<xs:any namespace="##other" processContents="strict" />
</xs:choice>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="AuthenticationMacType"> <xs:complexType name="AuthenticationMacType">
<xs:sequence> <xs:sequence>
<xs:element minOccurs="0" name="Nonce" type="dskpp:NonceType" /> <xs:element minOccurs="0" name="Nonce" type="dskpp:NonceType" />
<xs:element minOccurs="0" name="IterationCount" type="xs:int" /> <xs:element minOccurs="0" name="IterationCount" type="xs:int" />
<xs:element name="Mac" type="dskpp:MacType" /> <xs:element name="Mac" type="dskpp:MacType" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
skipping to change at page 67, line 6 skipping to change at page 69, line 11
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
8. Conformance Requirements 8. 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 3.1) (Section 3.4)
b. MUST implement the two-pass variation of the protocol b. MUST implement the two-pass variation of the protocol
(Section 3.2) (Section 3.5)
c. MUST support user authentication (Section 3.4) c. MUST support user authentication (Section 3.7)
d. MUST support the following Key Derivation Functions: d. MUST support the following Key Derivation Functions:
* DSKPP-PRF-AES DSKPP-PRF realization (Appendix C) * DSKPP-PRF-AES DSKPP-PRF realization (Appendix C)
* DSKPP-PRF-SHA256 DSKPP-PRF realization (Appendix C) * DSKPP-PRF-SHA256 DSKPP-PRF realization (Appendix C)
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 3.1.3 * Mechanism described in Section 3.4.3
f. MUST support the following Encryption algorithms for symmetric f. MUST support the following Encryption algorithms for symmetric
key operations, e.g., key wrap: key operations, e.g., key wrap:
* AES-CBC-128 [FIPS197-AES] * AES-CBC-128 [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:
* HMAC-SHA256 [FIPS180-SHA] * HMAC-SHA256 [FIPS180-SHA]
* AES-CMAC-128 [FIPS197-AES] * AES-CMAC-128 [FIPS197-AES]
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 profiles (Key Transport, Key Wrap, and Passphrase- protection profiles (Key Transport, Key Wrap, and Passphrase-
Based Key Wrap) MUST be implemented Based 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 need to 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).
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.
skipping to change at page 68, line 19 skipping to change at page 70, line 20
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 SHOULD, therefore, be run
over a transport providing privacy and integrity, such as HTTP over over a transport providing confidentiality and integrity, such as
Transport Layer Security (TLS) with a suitable ciphersuite, when such HTTP over Transport Layer Security (TLS) with a suitable ciphersuite,
threats are a concern. Note that TLS ciphersuites with anonymous key when such threats are a concern. Note that TLS ciphersuites with
exchanges are not suitable in those situations. anonymous key exchanges are not suitable in those situations.
9.2. Active Attacks 9.2. Active Attacks
9.2.1. Introduction 9.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
reorder messages for a variety of purposes including service denial reorder messages for a variety of purposes including service denial
and compromise of generated keying material. Section 9.2.2 through and compromise of generated keying material. Section 9.2.2 through
Section 9.2.7. Section 9.2.7.
9.2.2. Message Modifications 9.2.2. Message Modifications
Modifications to a <DSKPPTrigger> message will either cause denial- Modifications to a <KeyProvTrigger> message will either cause denial-
of-service (modifications of any of the identifiers or the nonce) or of-service (modifications of any of the identifiers or the nonce) or
will cause the DSKPP client to contact the wrong DSKPP server. The will cause the DSKPP client to contact the wrong DSKPP server. The
latter is in effect a man-in-the-middle attack and is discussed latter is in effect a man-in-the-middle attack and is discussed
further in Section 9.2.7. further in Section 9.2.7.
An attacker may modify a <KeyProvClientHello> message. This means An attacker may modify a <KeyProvClientHello> message. This means
that the attacker could indicate a different key or device than the that the attacker could indicate a different key or device than the
one intended by the DSKPP client, and could also suggest other one intended by the DSKPP client, and could also suggest other
cryptographic algorithms than the ones preferred by the DSKPP client, cryptographic algorithms than the ones preferred by the DSKPP client,
e.g., cryptographically weaker ones. The attacker could also suggest e.g., cryptographically weaker ones. The attacker could also suggest
skipping to change at page 70, line 7 skipping to change at page 72, line 10
this could constitute a security problem. For a further discussion this could constitute a security problem. For a further discussion
about this threat, and a possible countermeasure, see Section 9.5 about this threat, and a possible countermeasure, see Section 9.5
below. Note that use of TLS does not protect against this attack if below. Note that use of TLS does not protect against this attack if
the attacker has access to the DSKPP client (e.g., through malicious the attacker has access to the DSKPP client (e.g., through malicious
software, "Trojans"). software, "Trojans").
Finally, attackers may also modify the <KeyProvServerFinished> Finally, attackers may also modify the <KeyProvServerFinished>
message. Replacing the <Mac> element will only result in denial-of- message. Replacing the <Mac> element will only result in denial-of-
service. Replacement of any other element may cause the DSKPP client service. Replacement of any other element may cause the DSKPP client
to associate, e.g., the wrong service with the generated key. DSKPP to associate, e.g., the wrong service with the generated key. DSKPP
SHOULD be run over a transport providing privacy and integrity when SHOULD be run over a transport providing confidentiality and
this is a concern. integrity when this is a concern.
9.2.3. Message Deletion 9.2.3. Message Deletion
Message deletion will not cause any other harm than denial-of- Message deletion will not cause any other harm than denial-of-
service, since a cryptographic module MUST NOT change its state service, since a cryptographic module MUST NOT change its state
(i.e., "commit" to a generated key) until it receives the final (i.e., "commit" to a generated key) until it receives the final
message from the DSKPP server and successfully has processed that message from the DSKPP server and successfully has processed that
message, including validation of its MAC. A deleted message, including validation of its MAC. A deleted
<KeyProvServerFinished> message will not cause the server to end up <KeyProvServerFinished> message will not cause the server to end up
in an inconsistent state vis-a-vis the cryptographic module if the in an inconsistent state vis-a-vis the cryptographic module if the
skipping to change at page 70, line 34 skipping to change at page 72, line 37
any device identifier. DSKPP server implementations MAY receive some any device identifier. DSKPP server implementations MAY receive some
protection against inadvertently initializing a key or inadvertently protection against inadvertently initializing a key or inadvertently
replacing an existing key or assigning a key to a cryptographic replacing an existing key or assigning a key to a cryptographic
module by initializing the DSKPP run by use of the <KeyProvTrigger>. module by initializing the DSKPP run by use of the <KeyProvTrigger>.
The <TriggerNonce> element allows the server to associate a DSKPP The <TriggerNonce> element allows the server to associate a DSKPP
protocol run with, e.g., an earlier user-authenticated session. The protocol run with, e.g., an earlier user-authenticated session. The
security of this method, therefore, depends on the ability to protect security of this method, therefore, depends on the ability to protect
the <TriggerNonce> element in the DSKPP initialization message. If the <TriggerNonce> element in the DSKPP initialization message. If
an eavesdropper is able to capture this message, he may race the an eavesdropper is able to capture this message, he may race the
legitimate user for a key initialization. DSKPP over a transport legitimate user for a key initialization. DSKPP over a transport
providing privacy and integrity, coupled with the recommendations in providing confidentiality and integrity, coupled with the
Section 9.5, is RECOMMENDED when this is a concern. recommendations in Section 9.5, is RECOMMENDED when this is a
concern.
Insertion of other messages into an existing protocol run is seen as Insertion of other messages into an existing protocol run is seen as
equivalent to modification of legitimately sent messages. equivalent to modification of legitimately sent messages.
9.2.5. Message Replay 9.2.5. Message Replay
During 4-pass DSKPP, attempts to replay a previously recorded DSKPP During 4-pass DSKPP, attempts to replay a previously recorded DSKPP
message will be detected, as the use of nonces ensures that both message will be detected, as the use of nonces ensures that both
parties are live. For example, a DSKPP client knows that a server it parties are live. For example, a DSKPP client knows that a server it
is communicating with is "live" since the server MUST create a MAC on is communicating with is "live" since the server MUST create a MAC on
skipping to change at page 71, line 17 skipping to change at page 73, line 21
An attacker may attempt to re-order 4-pass DSKPP messages but this An attacker may attempt to re-order 4-pass DSKPP messages but this
will be detected, as each message is of a unique type. Note: Message will be detected, as each message is of a unique type. Note: Message
re-ordering attacks cannot occur in 2-pass DSKPP since each party re-ordering attacks cannot occur in 2-pass DSKPP since each party
sends at most one message each. sends at most one message each.
9.2.7. Man-in-the-Middle 9.2.7. Man-in-the-Middle
In addition to other active attacks, an attacker posing as a man in In addition to other active attacks, an attacker posing as a man in
the middle may be able to provide his own public key to the DSKPP the middle may be able to provide his own public key to the DSKPP
client. This threat and countermeasures to it are discussed in client. This threat and countermeasures to it are discussed in
Section 3.1.2.1. An attacker posing as a man-in-the-middle may also Section 3.4.2.1. An attacker posing as a man-in-the-middle may also
be acting as a proxy and, hence, may not interfere with DSKPP runs be acting as a proxy and, hence, may not interfere with DSKPP runs
but still learn valuable information; see Section 9.3. but still learn valuable information; see Section 9.3.
9.3. Passive Attacks 9.3. Passive Attacks
Passive attackers may eavesdrop on DSKPP runs to learn information Passive attackers may eavesdrop on DSKPP runs to learn information
that later on may be used to impersonate users, mount active attacks, that later on may be used to impersonate users, mount active attacks,
etc. etc.
If DSKPP is not run over a transport providing privacy, a passive If DSKPP is not run over a transport providing confidentiality, a
attacker may learn: passive attacker may learn:
o What cryptographic modules a particular user is in possession of; o What cryptographic modules a particular user is in possession of;
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; and 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; and
o Any value present in an <extension> that is part of
<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 privacy. If man-in-the-middle attacks for the purposes providing confidentiality. If man-in-the-middle attacks for the
described above are a concern, the transport SHOULD also offer purposes described above are a concern, the transport SHOULD also
server-side authentication. offer server-side authentication.
9.4. Cryptographic Attacks 9.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 3.1.3 later on may be used to impersonate the DSKPP server. Section 3.4.3
and Section 3 contain discussions of this threat and steps and Section 3 contain discussions of this threat and steps
RECOMMENDED to protect against it. RECOMMENDED to protect against it.
Implementers SHOULD also be aware that cryptographic algorithms
become weaker with time. As new cryptographic techniques are
developed and computing performance improves, the work factor to
break a particular cryptographic algorithm will reduce. Therefore,
cryptographic algorithm implementations SHOULD be modular allowing
new algorithms to be readily inserted. That is, implementers SHOULD
be prepared to regularly update the algorithms in their
implementations.
9.5. Attacks on the Interaction between DSKPP and User Authentication 9.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
given cryptographic module until the user simultaneously has proven given cryptographic module until the user simultaneously has proven
skipping to change at page 73, line 20 skipping to change at page 75, line 33
including R, using K_MAC. including R, using K_MAC.
9.6.3. Server Authentication 9.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 3.2 for two-pass DSKPP. Section 3.5 for two-pass DSKPP.
9.6.4. User Authentication 9.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. The Authentication Code and nonce value specified in Section 3.7. The Authentication Code and nonce value
MUST be strong enough to prevent offline brute-force recovery of MUST be strong enough to prevent offline brute-force recovery of
the Authentication Code from the HMAC data. Given that the nonce the Authentication Code from the HMAC data. Given that the nonce
value is sent in plaintext format over a non-secure transport, the value is sent in plaintext format over a non-secure transport, the
cryptographic strength of the AuthenticationData depends more on cryptographic strength of the AuthenticationData depends more on
the quality of the AuthenticationCode. the quality of the AuthenticationCode.
o When the AuthenticationCode is sent from the DSKPP server to the o When the AuthenticationCode is sent from the DSKPP server to the
device in a DSKPP initialization trigger message, an eavesdropper device in a DSKPP initialization trigger message, an eavesdropper
may be able to capture this message and race the legitimate user may be able to capture this message and race the legitimate user
for a key initialization. To prevent this, the transport layer for a key initialization. To prevent this, the transport layer
used to send the DSKPP trigger MUST provide privacy and integrity used to send the DSKPP trigger MUST provide confidentiality and
e.g. secure browser session. integrity e.g. secure browser session.
9.6.5. Key Protection in Two-Pass DSKPP 9.6.5. Key Protection in Two-Pass DSKPP
Three key protection profiles are defined for the different usages of Three key protection profiles are defined for the different usages of
2-pass DSKPP, which MUST be supported by a key package format, such 2-pass DSKPP, which MUST be supported by a key package format, such
as [PSKC] and [SKPC-ASN.1]. Therefore, key protection in the two- as [PSKC] and [SKPC-ASN.1]. Therefore, key protection in the two-
pass DSKPP is dependent upon the security of the key package format pass DSKPP is dependent upon the security of the key package format
selected for a protocol run. Some considerations for the Passphrase selected for a protocol run. Some considerations for the Passphrase
profile follow. profile follow.
skipping to change at page 78, line 14 skipping to change at page 80, line 44
14. Acknowledgements 14. Acknowledgements
We would like to thank the following for review of previous DSKPP We would like to thank the following for review of previous DSKPP
document versions: document versions:
o Dr. Ulrike Meyer (Review June 2007) o Dr. Ulrike Meyer (Review June 2007)
o Niklas Neumann (Review June 2007) o Niklas Neumann (Review June 2007)
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 (Review August 2007) 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 November 2008)
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)
Finally, we would like to thank Robert Griffin for opening Finally, we would like to thank Robert Griffin for opening
communication channels for us with the IEEE P1619.3 Key Management communication channels for us with the IEEE P1619.3 Key Management
Group, and facilitating our groups in staying informed of potential Group, and facilitating our groups in staying informed of potential
areas (esp. key provisioning and global key identifiers of areas (esp. key provisioning and global key identifiers of
collaboration) of collaboration. collaboration) of collaboration.
15. References 15. References
15.1. Normative references 15.1. Normative references
[FIPS180-SHA]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-2, February 2004, <http://
csrc.nist.gov/publications/fips/fips180-2/
fips180-2withchangenotice.pdf>.
[FIPS197-AES]
National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001, <http://csrc.nist.gov/
publications/fips/fips197/fips-197.pdf>.
[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/
internet-drafts/
draft-hoyer-keyprov-portable-symmetric-key-container-
03.txt>.
[RFC2104] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
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>.
[RFC3629] "UTF-8, a transformation format of ISO10646", STD 63, [RFC3629] "UTF-8, a transformation format of ISO10646", STD 63,
RFC 3629, November 2003, RFC 3629, November 2003,
<http://www.ietf.org/rfc/rfc3629.txt>. <http://www.ietf.org/rfc/rfc3629.txt>.
[UNICODE] Davis, M. and M. Duerst, "Unicode Normalization Forms", [UNICODE] Davis, M. and M. Duerst, "Unicode Normalization Forms",
March 2001, March 2001,
skipping to change at page 79, line 37 skipping to change at page 82, line 46
[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.
[FIPS180-SHA]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-2, February 2004, <http://
csrc.nist.gov/publications/fips/fips180-2/
fips180-2withchangenotice.pdf>.
[FIPS197-AES]
National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001, <http://csrc.nist.gov/
publications/fips/fips197/fips-197.pdf>.
[ISO3309] "ISO Information Processing Systems - Data Communication - [ISO3309] "ISO Information Processing Systems - Data Communication -
High-Level Data Link Control Procedure - Frame Structure", High-Level Data Link Control Procedure - Frame Structure",
IS 3309, 3rd Edition, October 1984. 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]
skipping to change at page 80, line 33 skipping to change at page 83, line 29
[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>.
[PSKC] "Portable Symmetric Key Container", 2008, <http://
www.ietf.org/internet-drafts/
draft-hoyer-keyprov-portable-symmetric-key-container-
03.txt>.
[RFC2104] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997, <http://www.ietf.org/rfc/rfc2104.txt>.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998, <http://www.ietf.org/rfc/rfc2396.txt>. August 1998, <http://www.ietf.org/rfc/rfc2396.txt>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999, Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
<http://www.ietf.org/rfc/rfc2616.txt>. <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>.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002, <http://www.ietf.org/rfc/rfc3280.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 [RFC4758] RSA, The Security Division of EMC, "Cryptographic Token
Key Initialization Protocol (CT-KIP)", November 2006, Key Initialization Protocol (CT-KIP)", November 2006,
<http://www.ietf.org/rfc/rfc4758.txt>. <http://www.ietf.org/rfc/rfc4758.txt>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(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/1999/REC-xml-names-19990114 >.
Appendix A. Examples Appendix A. Examples
skipping to change at page 83, line 28 skipping to change at page 86, line 28
</dskpp:DeviceIdentifierData> </dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes> <dskpp:SupportedKeyTypes>
<dskpp:Algorithm>http://www.ietf.org/keyprov/pskc#hotp <dskpp:Algorithm>http://www.ietf.org/keyprov/pskc#hotp
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/ <dskpp:Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-AES</dskpp:Algorithm> otps-wst#SecurID-AES</dskpp:Algorithm>
</dskpp:SupportedKeyTypes> </dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5 <dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms> </dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants><dskpp:FourPass/> <dskpp:SupportedProtocolVariants><dskpp:FourPass/>
</dskpp:SupportedProtocolVariants> </dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages> <dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
http://www.ietf.org/keyprov/pskc#KeyContainer http://www.ietf.org/keyprov/pskc#KeyContainer
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages> </dskpp:SupportedKeyPackages>
</dskpp:KeyProvClientHello> </dskpp:KeyProvClientHello>
skipping to change at page 84, line 29 skipping to change at page 87, line 29
<dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID> <dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID>
<dskpp:TriggerNonce>112dsdfwf312asder394jw==</dskpp:TriggerNonce> <dskpp:TriggerNonce>112dsdfwf312asder394jw==</dskpp:TriggerNonce>
<dskpp:SupportedKeyTypes> <dskpp:SupportedKeyTypes>
<dskpp:Algorithm>http://www.ietf.org/keyprov/pskc#hotp</dskpp:Algorithm> <dskpp:Algorithm>http://www.ietf.org/keyprov/pskc#hotp</dskpp:Algorithm>
<dskpp:Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/ <dskpp:Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-AES</dskpp:Algorithm> otps-wst#SecurID-AES</dskpp:Algorithm>
</dskpp:SupportedKeyTypes> </dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5 <dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms> </dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants><dskpp:FourPass/> <dskpp:SupportedProtocolVariants><dskpp:FourPass/>
</dskpp:SupportedProtocolVariants> </dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages> <dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
http://www.ietf.org/keyprov/pskc#KeyContainer http://www.ietf.org/keyprov/pskc#KeyContainer
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages> </dskpp:SupportedKeyPackages>
</dskpp:KeyProvClientHello> </dskpp:KeyProvClientHello>
skipping to change at page 85, line 16 skipping to change at page 88, line 16
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvServerHello Version="1.0" SessionID="4114" Status="Continue" <dskpp:KeyProvServerHello Version="1.0" SessionID="4114" Status="Continue"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<dskpp:KeyType> <dskpp:KeyType>
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:KeyType> </dskpp:KeyType>
<dskpp:EncryptionAlgorithm> <dskpp:EncryptionAlgorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:EncryptionAlgorithm> </dskpp:EncryptionAlgorithm>
<dskpp:MacAlgorithm> <dskpp:MacAlgorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:MacAlgorithm> </dskpp:MacAlgorithm>
<dskpp:EncryptionKey> <dskpp:EncryptionKey>
<ds:KeyName>KEY-1</ds:KeyName> <ds:KeyName>KEY-1</ds:KeyName>
</dskpp:EncryptionKey> </dskpp:EncryptionKey>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
http://www.ietf.org/keyprov/pskc#KeyContainer http://www.ietf.org/keyprov/pskc#KeyContainer
</dskpp:KeyPackageFormat> </dskpp:KeyPackageFormat>
<dskpp:Payload> <dskpp:Payload>
<dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce> <dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce>
</dskpp:Payload> </dskpp:Payload>
skipping to change at page 86, line 17 skipping to change at page 89, line 17
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvServerHello Version="1.0" SessionID="4114" <dskpp:KeyProvServerHello Version="1.0" SessionID="4114"
Status="Continue" Status="Continue"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<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.ietf.org/keyprov/dskpp#dskpp-prf-aes http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:EncryptionAlgorithm> </dskpp:EncryptionAlgorithm>
<dskpp:MacAlgorithm> <dskpp:MacAlgorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:MacAlgorithm> </dskpp:MacAlgorithm>
<dskpp:EncryptionKey> <dskpp:EncryptionKey>
<ds:KeyName>KEY-1</ds:KeyName> <ds:KeyName>KEY-1</ds:KeyName>
</dskpp:EncryptionKey> </dskpp:EncryptionKey>
<dskpp:KeyPackageFormat> <dskpp:KeyPackageFormat>
http://www.ietf.org/keyprov/pskc#KeyContainer http://www.ietf.org/keyprov/pskc#KeyContainer
</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"> MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
cXcycmFuZG9tMzEyYXNkZXIzOTRqdw== cXcycmFuZG9tMzEyYXNkZXIzOTRqdw==
</dskpp:Mac> </dskpp:Mac>
</dskpp:KeyProvServerHello> </dskpp:KeyProvServerHello>
A.2.5. <KeyProvClientNonce> Using Default Encryption A.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.
skipping to change at page 88, line 36 skipping to change at page 91, line 36
<pskc:Time> <pskc:Time>
<pskc:PlainValue>0</pskc:PlainValue> <pskc:PlainValue>0</pskc:PlainValue>
</pskc:Time> </pskc:Time>
</pskc:Data> </pskc:Data>
<pskc:ExpiryDate>2012-12-31T00:00:00</pskc:ExpiryDate> <pskc:ExpiryDate>2012-12-31T00:00:00</pskc:ExpiryDate>
</pskc:Key> </pskc:Key>
</pskc:Device> </pskc:Device>
</dskpp:KeyPackage> </dskpp:KeyPackage>
</dskpp:KeyPackage> </dskpp:KeyPackage>
<dskpp:Mac <dskpp:Mac
MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes"> MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
miidfasde312asder394jw== miidfasde312asder394jw==
</dskpp:Mac> </dskpp:Mac>
</dskpp:KeyProvServerFinished> </dskpp:KeyProvServerFinished>
A.3. Two-Pass Protocol A.3. Two-Pass Protocol
A.3.1. Example Using the Key Transport Profile A.3.1. Example Using the Key Transport Profile
The client indicates support all the Key Transport, Key Wrap, and The client indicates support all the Key Transport, Key Wrap, and
Passphrase-Based Key Wrap profiles: Passphrase-Based Key Wrap profiles:
skipping to change at page 89, line 24 skipping to change at page 92, line 24
</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>http://www.w3.org/2001/05/xmlenc#rsa_1_5 <dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128 <dskpp:Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</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 xsi:type="ds:KeyInfoType"> <ds:KeyInfo xsi:type="ds:KeyInfoType">
<ds:KeyName>Key_001</ds:KeyName> <ds:KeyName>Key_001</ds:KeyName>
skipping to change at page 91, line 26 skipping to change at page 94, line 26
</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:Key> </pskc:Key>
</pskc:Device> </pskc:Device>
</dskpp:KeyPackage> </dskpp:KeyPackage>
</dskpp:KeyPackage> </dskpp:KeyPackage>
<dskpp:Mac <dskpp:Mac
MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes"> MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
miidfasde312asder394jw== miidfasde312asder394jw==
</dskpp:Mac> </dskpp:Mac>
<dskpp:AuthenticationData> <dskpp:AuthenticationData>
<dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac> <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
</dskpp:AuthenticationData> </dskpp:AuthenticationData>
</dskpp:KeyProvServerFinished> </dskpp:KeyProvServerFinished>
A.3.2. Example Using the Key Wrap Profile A.3.2. Example Using the Key Wrap Profile
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
skipping to change at page 92, line 21 skipping to change at page 95, line 21
<dskpp:Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/ <dskpp:Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-AES</dskpp:Algorithm> otps-wst#SecurID-AES</dskpp:Algorithm>
</dskpp:SupportedKeyTypes> </dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5 <dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128 <dskpp:Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm>http://www.rsasecurity.com/rsalabs/pkcs/schemas/ <dskpp:Algorithm>http://www.rsasecurity.com/rsalabs/pkcs/schemas/
pkcs-5#pbes2</dskpp:Algorithm> pkcs-5#pbes2</dskpp:Algorithm>
<dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes <dskpp:Algorithm>http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</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 xsi:type="ds:KeyInfoType"> <ds:KeyInfo xsi:type="ds:KeyInfoType">
<ds:KeyName>Key_001</ds:KeyName> <ds:KeyName>Key_001</ds:KeyName>
skipping to change at page 94, line 11 skipping to change at page 97, line 11
<pskc:Counter> <pskc:Counter>
<pskc:PlainValue>1/pskc:PlainValue> <pskc:PlainValue>1/pskc:PlainValue>
</pskc:Counter> </pskc:Counter>
</pskc:Data> </pskc:Data>
<pskc:ExpiryDate>2012-12-31T00:00:00</pskc:ExpiryDate> <pskc:ExpiryDate>2012-12-31T00:00:00</pskc:ExpiryDate>
</pskc:Key> </pskc:Key>
</pskc:Device> </pskc:Device>
</dskpp:KeyPackage> </dskpp:KeyPackage>
</dskpp:KeyPackage> </dskpp:KeyPackage>
<dskpp:Mac <dskpp:Mac
MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes"> MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128">
miidfasde312asder394jw== miidfasde312asder394jw==
</dskpp:Mac> </dskpp:Mac>
<dskpp:AuthenticationData> <dskpp:AuthenticationData>
<dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac> <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
</dskpp:AuthenticationData> </dskpp:AuthenticationData>
</dskpp:KeyProvServerFinished> </dskpp:KeyProvServerFinished>
A.3.3. Example Using the Passphrase-Based Key Wrap Profile A.3.3. Example Using the Passphrase-Based Key Wrap Profile
The client sends a request similar to that in Appendix A.3.1 with The client sends a request similar to that in Appendix A.3.1 with
skipping to change at page 95, line 10 skipping to change at page 98, line 10
</dskpp:SupportedKeyTypes> </dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms> <dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5 <dskpp:Algorithm>http://www.w3.org/2001/05/xmlenc#rsa_1_5
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128 <dskpp:Algorithm>http://www.w3.org/2001/04/xmlenc#kw-aes128
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2
</dskpp:Algorithm> </dskpp:Algorithm>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</dskpp:Algorithm> </dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms> </dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms> <dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm> <dskpp:Algorithm>
http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
</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 xsi:type="ds:KeyInfoType"> <ds:KeyInfo xsi:type="ds:KeyInfoType">
<ds:KeyName>Key_001</ds:KeyName> <ds:KeyName>Key_001</ds:KeyName>
skipping to change at page 95, line 50 skipping to change at page 98, line 50
<dskpp:AuthenticationCodeMac> <dskpp:AuthenticationCodeMac>
<dskpp:IterationCount>512</dskpp:IterationCount> <dskpp:IterationCount>512</dskpp:IterationCount>
<dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac> <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
</dskpp:AuthenticationCodeMac> </dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData> </dskpp:AuthenticationData>
</dskpp:KeyProvClientHello> </dskpp:KeyProvClientHello>
In this example, the server responds to the previous request using In this example, the server responds to the previous request using
the Passphrase-Based Key Wrap Profile. the Passphrase-Based Key Wrap Profile.
(preamble)
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dskpp:KeyProvServerFinished Version="1.0"
SessionID="4114" Status="Success" <dskpp:KeyProvServerFinished Version="1.0" SessionID="4114" Status="Success" xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns:pkcs-5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:dskpp:1.0 keyprov-dskpp-1.0-local.xsd http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0# pkcs-5v2-0a1.xsd">
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp:1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:pkcs-5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<dskpp:KeyPackage> <dskpp:KeyPackage>
<dskpp:ServerID>https://www.somedskppservice.com/</dskpp:ServerID> <dskpp:ServerID>https://www.somedskppservice.com/</dskpp:ServerID>
<dskpp:KeyProtectionMethod> <dskpp:KeyProtectionMethod>
urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap urn:ietf:params:xml:schema:keyprov:protocol#passphrase-wrap
</dskpp:KeyProtectionMethod> </dskpp:KeyProtectionMethod>
<dskpp:KeyPackage Version="1.0"> <dskpp:KeyPackage Version="1.0">
<pskc:EncryptionKey> <pskc:EncryptionKey>
<pskc:DerivedKey Id="#Passphrase1"> <pskc:DerivedKey>
<pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName> <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
<pskc:KeyDerivationMethod <pskc:KeyDerivationMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
Algorithm= <pkcs-5:PBKDF2-params>
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
<pkcs-5:Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
<Salt> <Salt>
<Specified>Df3dRAhjGh8=</Specified> <Specified>P1ciQdGbrI0=</Specified>
</Salt> </Salt>
<IterationCount>2000</IterationCount> <IterationCount>2000</IterationCount>
<KeyLength>16</KeyLength> <KeyLength>16</KeyLength>
<PRF/> <PRF/>
</pkcs-5:Parameters> </pkcs-5:PBKDF2-params>
</pskc:KeyDerivationMethod> </pskc:KeyDerivationMethod>
<xenc:ReferenceList> <xenc:ReferenceList>
<xenc:DataReference URI="#ED"/> <xenc:DataReference URI="#ED"/>
</xenc:ReferenceList> </xenc:ReferenceList>
</pskc:DerivedKey> </pskc:DerivedKey>
</pskc:EncryptionKey> </pskc:EncryptionKey>
<pskc:Device> <pskc:Device>
<pskc:DeviceInfo> <pskc:DeviceInfo>
<pskc:Manufacturer>Manufacturer</pskc:Manufacturer> <pskc:Manufacturer>Manufacturer</pskc:Manufacturer>
<pskc:SerialNo>0755225266</pskc:SerialNo> <pskc:SerialNo>0755225266</pskc:SerialNo>
</pskc:DeviceInfo> </pskc:DeviceInfo>
<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="0755225266">
KeyId="0755225266">
<pskc:Issuer>AnIssuer</pskc:Issuer> <pskc:Issuer>AnIssuer</pskc:Issuer>
<pskc:Usage OTP="true"> <pskc:Usage OTP="true">
<pskc:ResponseFormat Length="6" Format="DECIMAL"/> <pskc:ResponseFormat Length="6" Format="DECIMAL"/>
</pskc:Usage> </pskc:Usage>
<pskc:Data> <pskc:Data>
<pskc:Secret> <pskc:Secret>
<pskc:EncryptedValue Id="ED"> <pskc:EncryptedValue>
<xenc:EncryptionMethod <xenc:EncryptionMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">
Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/> <pskc:EncryptionScheme Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
</xenc:EncryptionMethod>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk= <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
</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:Key> </pskc:Key>
</pskc:Device> </pskc:Device>
</dskpp:KeyPackage> </dskpp:KeyPackage>
</dskpp:KeyPackage> </dskpp:KeyPackage>
<dskpp:Mac <dskpp:Mac MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes">
MacAlgorithm="http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes">
miidfasde312asder394jw== miidfasde312asder394jw==
</dskpp:Mac> </dskpp:Mac>
<dskpp:AuthenticationData> <dskpp:AuthenticationData>
<dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac> <dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
</dskpp:AuthenticationData> </dskpp:AuthenticationData>
</dskpp:KeyProvServerFinished> </dskpp:KeyProvServerFinished>
(postamble)
Appendix B. Integration with PKCS #11 Appendix B. 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. [PKCS-11] as a programming interface.
B.1. The 4-pass Variant B.1. The 4-pass Variant
When performing 4-pass DSKPP with a cryptographic module using the When performing 4-pass DSKPP with a cryptographic module using the
skipping to change at page 100, line 33 skipping to change at page 103, line 24
C.2. DSKPP-PRF-AES C.2. DSKPP-PRF-AES
C.2.1. Identification C.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 URL MAY be used to identify this algorithm in DSKPP:
http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128 http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
When this URL is used to identify the encryption algorithm to use, When this URL is used to identify the encryption algorithm, the
the method for encryption of R_C values described in Section 3.1.3 method for encryption of R_C values described in Section 3.4.3 MUST
MUST be used. be used.
C.2.2. Definition C.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
s Octet string consisting of randomizing material. The s Octet string consisting of randomizing material. The
length of the string s is sLen. length of the string s is sLen.
skipping to change at page 102, line 18 skipping to change at page 105, line 13
C.3. DSKPP-PRF-SHA256 C.3. DSKPP-PRF-SHA256
C.3.1. Identification C.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 URL MAY be used to identify this algorithm in DSKPP:
http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256
When this URL is used to identify the encryption algorithm to use, When this URL is used to identify the encryption algorithm to use,
the method for encryption of R_C values described in Section 3.1.3 the method for encryption of R_C values described in Section 3.4.3
MUST be used. MUST be used.
C.3.2. Definition C.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
s Octet string consisting of randomizing material. The s Octet string consisting of randomizing material. The
 End of changes. 198 change blocks. 
521 lines changed or deleted 645 lines changed or added

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